gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Deleting textures using libnds videogl functions?

#163480 - 3dfx - Fri Oct 03, 2008 2:22 am

Is there a way to delete a texture with libnds?
I mean glDeleteTextures isn't implemented in libnds.
Texture was created using glGenTextures ... bind ... etc.

#163487 - silent_code - Fri Oct 03, 2008 9:39 am

You have to implement it yourself, but maybe the next libnds release will support better texture management. We'll have to see (or ask the devs). :^)

There are some texture managers floating aroud the forum, though. Do a search.

Good luck. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#163530 - 3dfx - Sat Oct 04, 2008 7:58 am

Interesting.

Quick question, can I manipulate the texture directly, setting individual pixels after I have bound and loaded it?

#163533 - silent_code - Sat Oct 04, 2008 8:53 am

EDIT: It turns out, the VRAM switching timing I was writing about isn'zt true. Please read on, though.

NOTE: I am not entirely sure (in fact, I am quite the opposite), if all of this information is right (regarding VRAM switching time), so you best test it out and see for yourself!


Yes, just make sure you don't want to display the texture (as well as others, as you'll see) for about three frames, as VRAM writing is only supported in LCD mode and switching VRAM bank modes happens only in the next frame. Any textures located in that VRAM bank will not be accessible to the 3D rendering units.
I might not be 100% right, but I guess it's close enough. Look at the following quote:

gbatec wrote:
In Extended Palette and Texture Image/Palette modes, VRAM is not mapped to CPU address space, and can be accessed only by the display controller (so, to initialize or change the memory, it should be temporarily switched to Plain-CPU mode).

Good luck. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.


Last edited by silent_code on Sat Oct 04, 2008 11:51 pm; edited 3 times in total

#163535 - eKid - Sat Oct 04, 2008 10:06 am

Hmm, I thought the bank switching was immediate, and you just have to change the texture within the 'smaller' 3D vblank. (since rendering starts 48 lines before vblank ends)

#163559 - silent_code - Sat Oct 04, 2008 11:33 pm

eKid wrote:
Hmm, I thought the bank switching was immediate, and you just have to change the texture within the 'smaller' 3D vblank. (since rendering starts 48 lines before vblank ends)


You might be right (and you probably are), but I couldn't find the right timing when doing some more involved capturing stuff. Might just be, that I've mixed up some things there. I'm not sure, because it's been a while since I last tinkered with the NDS's VRAM.

Point is, it has to be done right and fast, otherwise it's going to be flickering hell. :^)

Steps include:

- switch desired VRAM bank to LCD mode
- modify texels
- switch VRAM bank back to texture mode
- do it fast
- watch your timing

EDIT:

I just found this:
gbatek wrote:
After setting the Capture Enable bit, capture starts at next line 0, and the capture enable/busy bit is then automatically cleared (in line 192, regardless of the capture size).


So, it's the capturing that is only available in the frame after enabling it and eKid is right. (Btw: Thanks for pointing it out!) :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#163565 - zeruda - Sun Oct 05, 2008 3:26 am

3dfx wrote:
Quick question, can I manipulate the texture directly, setting individual pixels after I have bound and loaded it?


Yes you can. Silent explained it above, here's some code:
Code:
vramSetBankA(VRAM_A_LCD);
VRAM_A[0] = 0;           // VRAM_A is a 16 bit pointer
VRAM_A[1] = 56;         // so this line writes to the 3rd and 4th bytes
...
...
VRAM_A[65535] = 8978;
VRAM_A[65536] = 8978; // Bank A is 128K, so this'll overflow to bank B(meaning a logical flaw)
vramSetBankA(VRAM_A_TEXTURE);