View unanswered posts | View active topics It is currently Sat Jul 21, 2018 1:13 am



Reply to topic  [ 6 posts ] 
 Please help me with some VRAM updating problems... 
Author Message

Joined: Tue Mar 06, 2012 1:00 pm
Posts: 4
Hello you guys. I've stucked on a problem for several days. I hope you guys could give me some hints.

I'm using Texture VRAM updating to do some animations. From what I've learned, I should update Texture VRAM during VBlank period to prevent glitches from happening.

However the data amount is so HUGE that it can't be DMAed into Texture VRAM in a single VBlank period.

So I could notice some ugly "black line" glitches flashing on the screen, which made me very angry.

I then decided to drop fps to 30 to gain some extra timing using the following method:

Code:
...

u64 currentTime=getCurrentMicroSecond();
while(TRUE){
   someLogic();
   if(getCurrentMicroSecond()-currentTime<16715)swiWaitForVBlank();
   glFlush();   // I believe that 3D screen is refreshed only after glFlush() is called
   swiWaitForVBlank();
   currentTime=getCurrentMicroSecond();
   someRender();
   updateTextureVRAM();
}


But glitches still existed. I was then totally frustrated.

My dear friends, please tell me what I should do to solve this problem. Any suggestion is much appreciated.

And please forgive me for my bad English. You know, a foreign language is never easier than mother tongue...


Tue Mar 06, 2012 2:15 pm
Profile

Joined: Sun Jan 06, 2008 4:06 am
Posts: 40
The entire 3D screen is rendered every frame. You can't drop down to 30 FPS, unless you are actively using the video capture hardware to save an image of the 3D scene.

Maybe divide your texture updates across 2 frames.


Wed Mar 14, 2012 8:14 pm
Profile

Joined: Tue Mar 06, 2012 1:00 pm
Posts: 4
Dwedit wrote:
The entire 3D screen is rendered every frame. You can't drop down to 30 FPS, unless you are actively using the video capture hardware to save an image of the 3D scene.

I don't agree with your opinion.
I believe that the 3D screen is rendered only after glFlush() is called, which swaps the geometry buffer and render buffer of the 3D hardware.
So the screen stays still even if the Texture VRAM is refreshed, if glFlush() is NOT called. And will be updated immediately after glFlush() is executed.
As for Video Capture Hardware, nothing related to fps.

Dwedit wrote:
Maybe divide your texture updates across 2 frames.

Well, this IS a solution in theory. Currently I'm trying to put theory into practice to rewrite my update procedure using this method. Hope this could work for me.


Thu Mar 15, 2012 6:28 am
Profile

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 352
also of note is that the 3d vblank period is not the same as the 2d vblank period. http://nocash.emubase.de/gbatek.htm#dsvideostuff. there are only 23 v-blank lines for 3d vs 71 for 2d. you also cannot use the h-blank period to sneak in more load time.

so, you have a few options:
1) load only new textures during vblank. you will need to keep track of what is needed in the current frame and the new frame you are building.
2) use different vram for even and odd frames, A/B one from,C/D the next
3) live with the lines

also, if you are not using paletted textures then you will want to make the switch. 8 bit at a minumum, but if you can use the other smaller sizes then all the better.


Thu Mar 15, 2012 1:54 pm
Profile
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1277
Location: UK
HarukaKaminari wrote:
Dwedit wrote:
The entire 3D screen is rendered every frame. You can't drop down to 30 FPS, unless you are actively using the video capture hardware to save an image of the 3D scene.

I don't agree with your opinion.
I believe that the 3D screen is rendered only after glFlush() is called, which swaps the geometry buffer and render buffer of the 3D hardware.
So the screen stays still even if the Texture VRAM is refreshed, if glFlush() is NOT called. And will be updated immediately after glFlush() is executed.
As for Video Capture Hardware, nothing related to fps.


Sadly no, the 3D *is* rendered each frame, glFlush swaps the geometry buffers, as far as we're aware there is no render buffer. If you modify texture VRAM being used by the current scene you will see artifacts as you describe.

Double buffering textures as elhobbs suggests is probably the best way to handle this.

_________________
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog


Thu Mar 15, 2012 2:57 pm
Profile ICQ WWW

Joined: Tue Mar 06, 2012 1:00 pm
Posts: 4
elhobbs wrote:
2) use different vram for even and odd frames, A/B one from,C/D the next.

What if I need huge Texture VRAM that is more than 256K? What if Bank C/D is used for other purpose such as Sub Screen BG/OBJ VRAM?
This is the best solution I believe, but not the right solution I should choose. Anyway, elhobbs, thanks so much.

WinterMute wrote:
If you modify texture VRAM being used by the current scene you will see artifacts as you describe.

That is the very situation I'm facing at. What I'm trying to do is to stop Rendering Engine from working so that the screen will stay still at the last frame that it has just rendered, and trying to make it continue to render after Texture VRAM is completely updated. I then realized this is not possible due to the hardware design when I read GBATEK. So this is a dead end.
You corrected my mistakes on the understandings of 3D hardware. Thank you so much, WinterMute.

I'm trying to do something to keep track on texture management as elhobbs suggested.


Mon Mar 26, 2012 4:28 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 6 posts ] 

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