Wii Screen Refresh *RESOLVED*

I have noticed that all the code written for Wii (and maybe I have just not seen an exception) basically creates a look that re-draws the entire screen every frame.

Is this done just for convenience (i.e. so that code like Wiimote data can be refreshed, etc) or is this done because of some hardware issue which requires the screen to be refreshed?

Let me illustrate with a simple example, consider a program which has a title / splash screen. The title screen its to be displayed for, say, 5 seconds before the main menu is displayed. Once the title / splash screen is rendered can one just sleep for 5 seconds or does one actually need to loop trough a 5 second loop constantly re-rendering the same screen? Obviously if the title screen needs changes then this would be a mute point but if it does not, is it possible to render once and then just sleep?

Assuming the screen does not need to be re-renderd each frame then I am surprised that there aren't more program out there that use partial screen re-rendering instead of always re-rendering the whole screen from scratch. Consider a program where the screen is almost totally static except for a few moving objects. For example, a pinball machine game. I would think, instead of re-rendering the entire screen each time it would be faster to store the portion of the screen under the sprite before writing the sprite to the screen and then replacing the sprite with the save screen portion when the sprite needs to be moved. Unless most of the screen is in motion (which is the case for some games such as platform scrolling games) this should be a processing saving because you are writing the small sprite area twice as opposed to the whole screen once.

Or is the choice to re-render the whole screen done because it is simpler to code that way and the Wii processor is still fast to accomplish this in most cases?



Edited 1 time(s). Last edit at 04/27/2010 02:20AM by LordAshes.

If you have a static background you can just render it into a texture and draw it on a full screen quad every frame.

Quote
calvinss4
If you have a static background you can just render it into a texture and draw it on a full screen quad every frame.

I think you might have missed the point of what I was asking. I am asking if it is necessary to re-render the screen every frame. If there is no change, is it necessary to clear the screen and re-render it or can you just sit idle with the last render displayed until something does change?

Double buffering makes is almost a requirement to redraw everything. As you don't have the buffer of the previous frame to draw on, but of the frame before that. (So while you see Buffer 1 on the screen, you draw on Buffer 2, and then you view Buffer 2 and draw on Buffer 1)

So 99% of the time it's easier to do a full redraw.

But you can get away by not drawing anything and then don't flip the buffers. Loading screens for example, draw "LOADING" on the screen, load everything and during the load you don't update the screen.

I didn't miss the point; quite the opposite actually.

Of course you can leave an image on the screen; the VIDEO framework isn't going to refill the screen unless you tell it to. Now, the entire second half of your post talks about drawing a moving object on a static background. Since you're quite a curious felluh, I think it's best you understand how this entire process works:
1. Issue a GX command.
2. The CPU pipes it to the GP (Graphics Processor).
3. The GP renders into the EFB (Embedded Frame Buffer).
4. The EFB is copied to the XFB (External Frame Buffer). The XFB is in main memory (DRAM); as Daid said, the standard is to have two buffers.
4.1 While the copy operation occurs, the EFB color and z-values are simultaneously cleared.
5. The XFB is handed off to the VIDEO framework, which takes the buffer data and fills the screen.

Hence the goal of double buffering -- while the VIDEO framework is reading from XFB1, we can simultaneously copy from the EFB to XFB2.

Do you see the issue with partial screen updating now? To fully optimize this you'd have to disable the clear operation so that the EFB's color values aren't cleared, redraw the section where the sprite used to be, draw the section where the sprite is now, find the bounding rectangle and only copy that section of the EFB to the XFB. Sure it might be possible, but this isn't the bottleneck of your program, so there's no point in optimizing it.

That brings us full circle. If you have a static background composed of complex geometry, render it into the EFB and save it into a texture (this is used for pretty pre-rendered backgrounds as made famous on the PS1); otherwise, just use a PNG.

Cheers,
Cale

"moot" not "mute" :D

yes you can draw your stuff outside a while loop... we usually have it in the loops so that things can change (animation, switches, etc)

but in your scenario, you could have a static background rendered outside the loop, then run your loop for time and then move on.

Partial screen updating (like cale mentioned) wouldn't be really worth it.



Edited 1 time(s). Last edit at 04/27/2010 01:14AM by mdbrim.

Quote
Daid
Double buffering makes is almost a requirement to redraw everything. As you don't have the buffer of the previous frame to draw on, but of the frame before that. (So while you see Buffer 1 on the screen, you draw on Buffer 2, and then you view Buffer 2 and draw on Buffer 1)

So 99% of the time it's easier to do a full redraw.

But you can get away by not drawing anything and then don't flip the buffers. Loading screens for example, draw "LOADING" on the screen, load everything and during the load you don't update the screen.

This is what I was looking for. So there is not need to redraw the screen (as long as you don't flip frame buffers if you are using double buffering) if there is no change. Perfect.

Quote
calvinss4
I didn't miss the point; quite the opposite actually.

Of course you can leave an image on the screen; the VIDEO framework isn't going to refill the screen unless you tell it to.

Well this was the main question that I was asking. I wanted to make sure that the Wii hardware does not use some sort of weird volitile video memory (something similar to a capacitor) which requires constant refreshing. It would be a really odd implementation but all the software examples that I have seen constantly re-draw the screen so I was starting to wonder.

Quote
calvinss4
Now, the entire second half of your post talks about drawing a moving object on a static background. Since you're quite a curious felluh, I think it's best you understand how this entire process works:
1. Issue a GX command.
2. The CPU pipes it to the GP (Graphics Processor).
3. The GP renders into the EFB (Embedded Frame Buffer).
4. The EFB is copied to the XFB (External Frame Buffer). The XFB is in main memory (DRAM); as Daid said, the standard is to have two buffers.
4.1 While the copy operation occurs, the EFB color and z-values are simultaneously cleared.
5. The XFB is handed off to the VIDEO framework, which takes the buffer data and fills the screen.

Thanks for the re-cap. I am somewhat familiar with this process but only sort of a cursory familiarity.

Quote
calvinss4
Hence the goal of double buffering -- while the VIDEO framework is reading from XFB1, we can simultaneously copy from the EFB to XFB2.

This concept I understand. I am currently working with simple 2D and using only a single buffer but I remember, from the 3D examples that I played around with, that they were all using double buffering.

Quote
calvinss4
Do you see the issue with partial screen updating now? To fully optimize this you'd have to disable the clear operation so that the EFB's color values aren't cleared, redraw the section where the sprite used to be, draw the section where the sprite is now, find the bounding rectangle and only copy that section of the EFB to the XFB. Sure it might be possible, but this isn't the bottleneck of your program, so there's no point in optimizing it.

Got it. So although your source code may look like you are only re-drawing a part of the screen, down at the frame buffer level it is still re-drawing the whole buffer (because of the clear) and thus your savings it almost non-existant. You may save a tiny bit by the fact that you would probably have less CPU commands to send to the GP...but probably not worth the effort.

Quote
calvinss4
That brings us full circle. If you have a static background composed of complex geometry, render it into the EFB and save it into a texture (this is used for pretty pre-rendered backgrounds as made famous on the PS1); otherwise, just use a PNG.

Okay...now I understand what your first answer ment. Thanks.

Best Regards,

Lord Ashes

Quote
mdbrim
"moot" not "mute" :D

What? You want me to be an engineer AND spell correctly?

Quote
mdbrim

Quote
mdbrim
yes you can draw your stuff outside a while loop... we usually have it in the loops so that things can change (animation, switches, etc)

Thanks. Daid already confirmed this for me.

Quote
mdbrim
Partial screen updating (like cale mentioned) wouldn't be really worth it.

Thanks. Cale explanation was great...now I understand why it is not worth it.

Lord Ashes

Reply Quote

I used to be an engineer (in my younger days) and... wait, you're right, i can't spell either!

Quote

Thanks. Daid already confirmed this for me.

Yeah sorry, his post was too long, i didn't even read all of it :D



Edited 1 time(s). Last edit at 04/27/2010 03:38AM by mdbrim.