Does glDeleteTextures work?

[azenris]

Have others successfully been using glDeleteTextures? I'm curious as I'm having some problems with my game, just thought I'd ask as I test some things in my code.
It's no doubt me, just thought I'd ask and double check it works with other people

My problem is not the glDeleteTextures call itself, but that it causes the next glTexImage2D to fail.
Not asking for any help just yet though on my code.

Anyway just curious!
TY

[Discostew]

After you using glTexImage2D right after using glDeleteTextures? If so, then it will fail because it is trying to assign a texture to a now null texture name. You would need to call glGenTextures on the texture names you plan to re-use after you use glDeleteTextures on them. If your plan is just to replace the texture name's current texture, then you don't need to use glDeleteTextures, but just call glTexImage2D with the new texture information, as it will clear out the current texture information and fill it with the new information.

If this is not the case, then we're gonna need more information on what you are doing to make it fail. The Paletted_Cube example uses glDeleteTextures, and doesn't have any problems as far as I know.

[zeromus]

discostew, i am confident there is a problem in the vram allocation. i saw it misbehaving. we may be unable to smoke out problems in glDeleteTextures in cases where the textures are small because the allocations arent failing. I'm attaching a test project made by NWDD in #dsdev which demonstrates the problem. the first teximage2d will function normally, and the delete as well, but the next teximage2d will fail to allocate the necessary memory. the allocation code is rather cryptic and i don't have time to debug it...

be sure to use libfat to get to that 1.bg

[Discostew]

Alright, I'll take a look at it. I know the allocation methods aren't really readable, so maybe while I figure out this problem, I can at least put comments in that area to help others understand it. It's basically blocks with 4 pointers, 2 pointers for blocks directly before/after, and 2 pointers for the blocks before/after that are the same type (allocated/unallocated). Other information relates to it's address in the selected memory range, a flag to determine if it an allocated or unallocated block, and the size of the block.

[Discostew]

Alright, I found the problem. It had to do with reassigning which block is the first empty block if the block/texture being deallocated was just before the first empty one. The Palette_Cube wasn't showing this problem because it allocated two blocks in sequence prior to deallocating the very first, leaving an allocated block between the two empty blocks.

I've uploaded the patch to the SourceForge page of devkitPro.