#118592 - melw - Wed Feb 14, 2007 1:53 pm
Currently only way of clearing textures is to use glResetTextures(), which resets all the textures. For changing a single texture this is not very convenient, so how about implementing OpenGL-like glDeleteTextures(int size, int *textures) function in libnds?
I do have already a workaround for this, just wanted to throw in an idea... would make things tad easier.
#118595 - simonjhall - Wed Feb 14, 2007 2:00 pm
Can I vote for this feature too please?
At the moment (for my menus) I snapshot the entire texture state, show the menu, then restore the texture state when the menu is exitted. It's a bit of an arse, and a proper delete function would be so much more convenient...
_________________
Big thanks to everyone who donated for Quake2
#118601 - silent_code - Wed Feb 14, 2007 3:17 pm
you got my vote, too. it's not that great of a task to do yourself, but a consistent, standard implementation into libnds would be nice.
#119028 - FireSlash - Mon Feb 19, 2007 5:01 am
The "correct" way to do this is to load ALL textures into memory, then switch the texture by changing the glBindTexture(); call to match the texture you want.
I see your point. Your method would allow more video memory to be used by freeing items not displayed on the screen at that frame. However, this generates an additional load on the CPU as it now has to re-generate the GL texture every time one of these events occurs... On a FAT device this would be a crippling effect. It may work on flash devices better, but the initial flaw associated with re-generating the texture from it's original format remains, and will probably cause unwanted side effects. I ran into similar issues with my own homebrew when i attempted a similar Load on Demand style of texture management.
HOWEVER
glDeleteTextures IS a OpenGL 1.1 function, and it's implementation may assist in porting.
_________________
FireSlash.net
#119039 - tepples - Mon Feb 19, 2007 6:58 am
| FireSlash wrote: |
| The "correct" way to do this is to load ALL textures into memory, then switch the texture by changing the glBindTexture(); call to match the texture you want. |
But what if one of the textures is a movie, which obviously cannot be completely decoded to VRAM at once?
| Quote: |
| Your method would allow more video memory to be used by freeing items not displayed on the screen at that frame. However, this generates an additional load on the CPU as it now has to re-generate the GL texture every time one of these events occurs |
Except in the case that the textures are stored or generated in the GL format.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119076 - melw - Mon Feb 19, 2007 2:23 pm
| FireSlash wrote: |
The "correct" way to do this is to load ALL textures into memory, then switch the texture by changing the glBindTexture(); call to match the texture you want.
I see your point. Your method would allow more video memory to be used by freeing items not displayed on the screen at that frame. However, this generates an additional load on the CPU as it now has to re-generate the GL texture every time one of these events occurs... |
Well, in a perfect world, if all the textures fit into memory there's no problem at all. But I think it's quite common where you have various scenes using different textures - perhaps some of them are same, some are not. Or you're using some of the banks for post-processing effects, or subscreen - there's lot of ways to run out of texture memory.
To me it seems like a waste of CPU time to call glResetTextures() and load everything again instead of, say calling glDeleteTextures() for one texture we don't need anymore and bind then the needed new texture after that.
#119082 - kusma - Mon Feb 19, 2007 2:42 pm
You can save memory be uploading a NULL-texture (zero width and height). Yes, it's a hack, but it should work. At least on a real GL-implementation, but then again glDeleteTextures() should exist too ;)
#119459 - gabebear - Fri Feb 23, 2007 4:59 am
I'm [<thinking>] about just removing the automatic texture memory allocation stuff (a.k.a. glTextImage2D() ) or moving it into a separate GL compatibility file.
The code is already long and complicated and there isn't a "good" way to delocate texture memory. If you were only loading/unloading textures of the same size it would be easy to write a good glDeleteTextures(), but otherwise glDeleteTextures() needs to deal with memory fragmentation and libnds is never going to defrag texture memory for you.
glTextImage2D is really just there as a crutch to get people by with simple code. Managing your own texture memory is the way to go.
#119599 - silent_code - Sat Feb 24, 2007 4:41 pm
a good way to handle texture "deletion" is to replace (overwrite) unused items with a new one of the same size, so you don't have to free and then reallocate memory. at least that used to be common practice on the pc. there are several algorithms for this purpose.
OFFTOPIC: is it correct, that textures need to be rotated 90? ccw, or is it just my messy code?
#119618 - gabebear - Sat Feb 24, 2007 8:39 pm
Silent_code, that probably is the best solution but memory fragmentation will still probably occur and waste precious video memory. If glDeleteTextures() ever gets implemented it would do something like this, but you still probably shouldn't use it.
About the 90 degree texture rotation, it's not your messy code, it's libnds's. In the stable version of libnds the texture cords are swapped . The swapped coords along with the DS's and OpenGL's coordinate system that starts from the bottom left instead of the top left and it appears that textures are rotated 90 degrees, but really they are getting swapped around their main diagonal and then flipped on the horizontal. If you want correct texture coords grab libnds from CVS, you will also want to grab the latest examples from CVS as some other stuff has changed
#119927 - silent_code - Tue Feb 27, 2007 3:24 pm
yeah, i just saw that somewhere else. obviously the uv coordinates are swapped. silly me, not seeing this. ;^p
though, there's no problem in just swapping uvs on mesh loading to "correct" this. i'm used to the upside down thing, anyway. ;^D
again, we need glDeleteTextures() for full texture memory control and as a standard for all libnds homebrew!
#120282 - Payk - Fri Mar 02, 2007 8:26 am
I more or less agree to that sentence: "Well, in a perfect world, if all the textures fit into memory there's no problem at all"
If you use 8bit textures you got damn many textures.
I guess deleting one out of it has some problems.
First one is that all pointers which are pointing to that vram location need to be set to 0 or coder has to really know about it.
Second one is that it may be neececary to move all textures which were behind it into that gap AND update those pointers too.
Well there was a time when i was playing arround with something like a swap bank. Its a quite silly thing and just was for playing arround.
If you track down the location of you loaded texture and wanna ovveride it, it wont work directly. You need to unlock textureram, refill texture with new content and lock the bank again. But while doing that, the screen gets black. A work arround was a swap system. 2 Banks holding 100% same content and just one is used at once. The other can be changed. If that was done you just need to swap the pointers(like doublebuffering). But that eats much vram and i decided to do it just as it should be used. But maybe there is a way to avoid the screen to get black while lock/unlocking texture banks.
#120302 - tepples - Fri Mar 02, 2007 2:31 pm
There is a way to avoid blanking the screen when replacing textures: try doing it during a time when the screen is already blank, such as the vertical blanking interval.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.