I'm curious to know why the load counter starts that high instead of starting at 0.
Also, what is the log result on desktop, to compare?
I did notice that. Desktop logs always start at 0. I theorised that perhaps Android was slower to initialise and that textures had already queued.
In the case of this log where the texture count start at 7, perhaps it misses out on some CREATE events, throwing some kind of count out. Just a thought.
On my side, I checked the workflow in synchronous mode, but it was actually fine, I misread it this morning.
I did fix the workflow when a texture decompression fails though, as before the load counter wouldn't be updated.
Now the counter gets updated but no load event will be sent, an empty texture will be created and used in place of the faulty one, with a log explaining what happened. That was just as a FYI as I doubt it was your case anyway.
One other thing to do on Android would be to add logs inside orxTexture.c everytime the load counter gets increased or decreased, as well as the texture name associated with the operation. That should give us all the visibility we need to understand what's going on.
add logs inside orxTexture.c everytime the load counter gets increased or decreased, as well as the texture name associated with the operation. That should give us all the visibility we need to understand what's going on.
We're getting closer but I think we'll need logs inside the Android display plugin now. Mostly in the Decompress and DecompressCallback to see where things get stuck.
Also could you try the latest version of orx, I made a couple of changes that could potentially help with any loading issue?
So I didn't test your issue, but I never had this before...
I've googled for the "GetBufferLock timed out" error and here is what I found.
All the post about this error were reported on Tegra2 GPU (same as your), and they are all related to graphics stuffs (textures etc...)
There may be different reasons for this error, but most probably a poorly designed locking mechanism for GPU memory allocation. Maybe GPU runs out of memory, and fails to unlock something, really hard to tell.
My conclusions:
Your device sucks (sorry. I know because I owned an Asus Transfromer with the same GPU. still works great as a doorstop).
Issue is really low level and Orx probably wont be able to recover from this. ever.
We're getting closer but I think we'll need logs inside the Android display plugin now. Mostly in the Decompress and DecompressCallback to see where things get stuck.
Also could you try the latest version of orx, I made a couple of changes that could potentially help with any loading issue?
Yes will do. Starting shortly. I saw the commits from Lydesik and yourself today so I've been keen to try again.
My conclusions:
Your device sucks (sorry. I know because I owned an Asus Transfromer with the same GPU. still works great as a doorstop).
Issue is really low level and Orx probably wont be able to recover from this. ever.
In a strange sort of way, this gives me some comfort. I just didn't like the idea that all these android devices would try my game and seize up half the time. But if it's down to just one GPU, I guess I can live with it and move on.
Thing is... it doesn't have to be asynchronous loading. I'm happy with synchronous loading of textures, if it were possible.
Anyway, I'll go through the motions with some new logs for the sake of completeness.
Comments
I did notice that. Desktop logs always start at 0. I theorised that perhaps Android was slower to initialise and that textures had already queued.
In the case of this log where the texture count start at 7, perhaps it misses out on some CREATE events, throwing some kind of count out. Just a thought.
I'll get a desktop version of the log.
Won't have access to an android build until this evening to put creation names in, but this should help compare. https://forum.orx-project.org/uploads/legacy/fbfiles/files/texture_desktop.txt
I did fix the workflow when a texture decompression fails though, as before the load counter wouldn't be updated.
Now the counter gets updated but no load event will be sent, an empty texture will be created and used in place of the faulty one, with a log explaining what happened. That was just as a FYI as I doubt it was your case anyway.
One other thing to do on Android would be to add logs inside orxTexture.c everytime the load counter gets increased or decreased, as well as the texture name associated with the operation. That should give us all the visibility we need to understand what's going on.
Yep, all done for desktop. See attached. https://forum.orx-project.org/uploads/legacy/fbfiles/files/desktop_textures_full_logging.txt
We're getting closer but I think we'll need logs inside the Android display plugin now. Mostly in the Decompress and DecompressCallback to see where things get stuck.
Also could you try the latest version of orx, I made a couple of changes that could potentially help with any loading issue?
So I didn't test your issue, but I never had this before...
I've googled for the "GetBufferLock timed out" error and here is what I found.
All the post about this error were reported on Tegra2 GPU (same as your), and they are all related to graphics stuffs (textures etc...)
There may be different reasons for this error, but most probably a poorly designed locking mechanism for GPU memory allocation. Maybe GPU runs out of memory, and fails to unlock something, really hard to tell.
My conclusions:
Your device sucks (sorry. I know because I owned an Asus Transfromer with the same GPU. still works great as a doorstop).
Issue is really low level and Orx probably wont be able to recover from this. ever.
Yes will do. Starting shortly. I saw the commits from Lydesik and yourself today so I've been keen to try again.
In a strange sort of way, this gives me some comfort. I just didn't like the idea that all these android devices would try my game and seize up half the time. But if it's down to just one GPU, I guess I can live with it and move on.
Thing is... it doesn't have to be asynchronous loading. I'm happy with synchronous loading of textures, if it were possible.
Anyway, I'll go through the motions with some new logs for the sake of completeness.
but, my bet is it won't change a thing.
Tried adding logging to the plugin file but nothing logged. Too tired to see why tonight.