Page 1 of 1

Please help me with some VRAM updating problems...

Posted: Tue Mar 06, 2012 2:15 pm
by HarukaKaminari
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: Select all

...

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...

Re: Please help me with some VRAM updating problems...

Posted: Wed Mar 14, 2012 8:14 pm
by Dwedit
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.

Re: Please help me with some VRAM updating problems...

Posted: Thu Mar 15, 2012 6:28 am
by HarukaKaminari
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.

Re: Please help me with some VRAM updating problems...

Posted: Thu Mar 15, 2012 1:54 pm
by elhobbs
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.

Re: Please help me with some VRAM updating problems...

Posted: Thu Mar 15, 2012 2:57 pm
by WinterMute
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.

Re: Please help me with some VRAM updating problems...

Posted: Mon Mar 26, 2012 4:28 am
by HarukaKaminari
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.