devkitPro

elhobbs wrote:I think this may be related to how GFX_FLUSH works on the DS - it does not take effect (geometry buffers are swapped) until the next vblank starts on scan line 192. so, I think if you are in vblank when GFX_FLUSH is set then I think it will not take effect until the following vblank.gbatek SWAP_BUFFERS

This is correct. I always perform glFlush(0) directly before swiWaitForVBlank();

I actually thought that was the problem at first but after calling swiWaitForVBlank before I call glFlush, I found that it didn't have any effect at all and the flickering persisted. I am thinking it's how I am storing the texture data. I may need to create two separate buffers for VRAM_A/B and VRAM_C/D instead of one as well as separate gfx_tex_param arrays that I alternate to between frames. I'll need to give that a try later today and see what happens.

you were clearing gfx_tex_params and gfx_spr_params in FlushTextures, but that is commented out now in the svn - so I think they would be wrong half of the time or at least inaccessible by the hardware. instead of having a whole second buffer you could just store the values in gfx_*params using the offset from the start of the buffer and then just add/or in the base vram address when you set GFX_TEX_FORMAT.

Kaiser wrote:I actually thought that was the problem at first but after calling swiWaitForVBlank before I call glFlush, I found that it didn't have any effect at all and the flickering persisted. I am thinking it's how I am storing the texture data. I may need to create two separate buffers for VRAM_A/B and VRAM_C/D instead of one as well as separate gfx_tex_param arrays that I alternate to between frames. I'll need to give that a try later today and see what happens.

I did play around with this yesterday and there were situations where GFX_FLUSH was being set twice in the same "DS" frame - running faster then 60fps - which was causing quite a bit of flickering.

I don't know if you can flush twice in a frame. I thought the CPU stalls until the buffer can be swapped again.

Is GFX_Flush getting set twice because of the main loop code or is it because it's just too fast?
I never really knew that it was possible though. I am assuming that I'll have to do wait for the next VBlank until I should start flushing.

I think I found some bugs:
R_PadTextureDims always returns the original width - I think it should return mask. there may be some buffer overruns in the sprite loading code - maybe R_PadTexture.

elhobbs wrote:I think I found some bugs:
R_PadTextureDims always returns the original width - I think it should return mask. there may be some buffer overruns in the sprite loading code - maybe R_PadTexture.

Just the width? I guess something is wrong with R_PadTextureDim's logic. I'll look into it later today.
Also I've committed another build last night. This fully eliminates vblank issues and performance is almost perfect. I still need to have the sprites broken up into tiles though. The support for it is there in the data format now, but I just need to start implementing it in the engine. This alone will save me a lot of VRAM space once this feature is in.

elhobbs wrote:I think I found some bugs:
R_PadTextureDims always returns the original width - I think it should return mask. there may be some buffer overruns in the sprite loading code - maybe R_PadTexture.

you can skip this - it was late. I am wrong.

Kaiser wrote:I still need to have the sprites broken up into tiles though. The support for it is there in the data format now, but I just need to start implementing it in the engine. This alone will save me a lot of VRAM space once this feature is in.

not sure what you mean. multiple sprites on one large DS texture to skip to power of 2 dimensions? or breaking the sprite into pieces? I guess I will find out when you are done.