Doom64 DS

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Mon May 07, 2012 3:30 pm

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();

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Mon May 07, 2012 4:42 pm

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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Mon May 07, 2012 6:39 pm

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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Mon May 07, 2012 6:53 pm

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.

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Mon May 07, 2012 7:05 pm

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

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Mon May 07, 2012 9:11 pm

Is GFX_Flush getting set twice because of the main loop code or is it because it's just too fast? :P
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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Tue May 08, 2012 4:09 am

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.

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Tue May 08, 2012 3:59 pm

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
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Tue May 08, 2012 4:17 pm

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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Tue May 08, 2012 4:24 pm

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.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 20 guests