VRAM for Textures

[Sylus101]

I'm mulling over http://nocash.emubase.de/gbatek.htm#ds3 ... attributes trying to figure out how the VRAM offsets work.

I'm familiar with the offsets and libnds allocation code that is done with 2D sprite graphics, but this does not appear to work the same way. I'm particularly confused by the Slots... I don't see how those relate to the possible offsets.

Hoping someone can shed some light for me... thanks ahead of time!

[vuurrobin]

I haven't looked at vram and textures ect, so I may be completely wrong, but isn't it the same as with background vram?

with background vram, you map a vram bank to an adress (like 0x06000000 or 0x06020000) and then tell the background which adress you use. I think that it works the same for textures, you map a vram bank to a slot, and then you tell the 3d hardware that you use an offset (where offset 2 would mean that you use slot 2).

I haven't looked at 3d, and my ds skills can be a bit rusty (thanks to school), so I may be completely wrong.

[Sylus101]

I think I'm understanding it a little better, but still not fully... as I'm trying to compare the openGLish libnds code to regular OpenGL to what's in gbatek...

What I THINK, is that when you set the binding... (among other things) you're setting the VRAM offset and each texture coordinate used following will use whatever graphic data is found at the offset.

What I can't understand is how glGenTextures(); could be properly assigning indexes only being told how many textures you want and not their sizes....

Help me DiscoStew and elHobbs... you're my only hope...
On a side note, would it be faster to ask these kinds of questions on gbadev?

[elhobbs]

glGenTextures returns free indexes in an internal array for storing ds texture references. when you call glBindTexture you are setting the current texture - this sets the current ds hardware texture as well as sets the internal library texture as the current one for future operations. when you call glTexture2d it finds a block of VRAM to load the texture into and updates the parameters for the current texture object in the internal library texture array. this allows future calls to glBindTexture to set the hardware texture using only the array index. the index value is used to lookup the ds texture reference (a 32 bit value I think) in the internal library texture array and assign the value to the texture register.

[Sylus101]

Well...





...Crap.

I'm going to have to read that several times... particularly because I haven't had anyone refer to an "internal texture library" yet... and right from the get go... I'm still not getting how can glGenTextures() can assign index offsets to VRAM if you don't know the size of the data that should be starting at a certain offset yet? Or does glTexImage2D() adjust the indexes in the array as gfx are loaded? Whew... sometimes I wish I was more willing to take this stuff for granted...

[elhobbs]

The texture register expects a 32 bit value that contains the address in VRAM the width, height, and texture flags. Libnds maintains an array of these values for you. glBindTexture returns an unused index in this array at this point the 32 bit value is 0. When you call glTexImage2d it updates the 32 bit value that is being store in the array by libnds with the information about the width, height, flags, and the VRAM address where it loaded your texture data. Future calls to bind will lookup the value that libnds is storing for you and write it to the texture register.

The internal texture library that I was referring to is just the array- sorry if that was confusing.

[Sylus101]

Ahhhh... okay. Thanks very much, that is MUCH more clear now.

If you check out the post at gbadev... you can see a quick progress demo on a model I'm working on...