View unanswered posts | View active topics It is currently Fri Nov 16, 2018 5:23 pm



Reply to topic  [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 10  Next
 Doom64 DS 
Author Message

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
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();


Mon May 07, 2012 3:30 pm
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Mon May 07, 2012 4:42 pm
Profile

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


Mon May 07, 2012 6:39 pm
Profile

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


Mon May 07, 2012 6:53 pm
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
I don't know if you can flush twice in a frame. I thought the CPU stalls until the buffer can be swapped again.


Mon May 07, 2012 7:05 pm
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Mon May 07, 2012 9:11 pm
Profile

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


Tue May 08, 2012 4:09 am
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Tue May 08, 2012 3:59 pm
Profile

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


Tue May 08, 2012 4:17 pm
Profile

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


Tue May 08, 2012 4:24 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 10  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads