devkitPro

What's better on the DS? I'm used to call lists being inferior when using animated meshes on PC OpenGL and because I dont have access to array features on the DS software and I dont entirely understand how the software utilizes call lists I am in favor of using glBegin and glEnd (no drawback for me so far, game runs at a steady playable framerate with no drops with a 510+ triangle scene.

a display list is a DMA of static data. it will run faster than some cpu fiddling about and sending individual geometry commands (which actually consist of nothing more than writing words to memory mapped registers) for many reasons including that display lists can be packed to result in less data transfer. but then, it is considerably more difficult to work with.

zeromus wrote:a display list is a DMA of static data. it will run faster than some cpu fiddling about and sending individual geometry commands (which actually consist of nothing more than writing words to memory mapped registers) for many reasons including that display lists can be packed to result in less data transfer. but then, it is considerably more difficult to work with.

Regardless of them being more difficult, are they modifiable on the fly? I need to be able to modify the vertex normals and co-ordinates for animations... if not I can always render static instances using a display list and dynamic instances using glBegin and glEnd.

its just bytes in memory. you can modify it all you want. but i dont think i would do it that way.

What about having both a display list, and another set of information that holds the data of modifiable vertices that also points to where each vertex, normal, etc information is held in the display list, so that when a vertex is processed, it would then copy into the designated spots the modified version into the list?

I'd consider just how much you're expecting from the DS. It'll take a lot from a fairly slow ARM9 to perform bone like animation (notice in DS games it's primarily a link-up of static meshes) in which case you animate these by having parent-child meshes and a matrix on each child to keep track of its position/location from the parent. This will allow you to animate sub-meshes rather than individual vertices but won't require you to edit your display lists and has no performance hit on the DS.

I have been using linear vertex interpolation for that issue and this
can be done quite fast, for the normals it is different, but if the sample
rate is fast enough also linear interpolation can be used for the normals