gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

OffTopic > Would 1 frame behind input make a difference?

#34399 - DiscoStew - Wed Jan 19, 2005 12:31 am

This is a question I had on my mind for quite some time. In a general sense, I would see no actual gameplay problem with it, but maybe other people have a different opinion.

When I first started programming for the GBA, my first impression was to do every single calculation in the VBlank (including input from the user), so that the results can be displayed in the frame to be drawn. This ofcourse would exclude HBlank effects, as those need to be set on each scanline. As I got farther into programming, I noticed that the VBlank just couldn't handle everthing. So I set up my code to start taking input and do calculation on the VBlank, and then once all the calculations were done, I would store the results into buffers, that will be set into the registers once the VBlank occurs again, which woudl display the result on the frame after that.

Perhaps I'm just summarizing the correct way to program games, which will result in me getting a stupid answer for my stupid question. But many times I here people starting their frame calculations at the start of the first HBlank, not at the VBlank, which is why I decided to ask this question. so...

Whether it be 1 frame behind, or 1 frame and 68 scanlines behind, would it make a difference to the user? This is in reference that a game is running at 60fps FYI. Expand on this topic if you want.
_________________
DS - It's all about DiscoStew

#34405 - DekuTree64 - Wed Jan 19, 2005 1:29 am

Generally, yes, your input will be one frame behind. The overall flow should be something like:
Code:
GetInput();
UpdateGame();
WaitForVBlank();
SwapBuffers();


So, you grab the input to see what the user wants you to do, and update all your sprite positions and map scrolling/etc based on that input, storing things in offscreen buffers and such. When VBlank happens, you dump all your calculations to the screen as quickly as possible while the user can't see it.

Then go back to the start, and read the input again. You're probably still in VBlank, so the user hasn't seen anything yet. That's ok, it just gives you a little more time to finish THIS frame's game updating, and you're not writing anything to the screen anyway so who cares wether you're in VBlank or not.
As soon as that VBlank finishes, the user finally sees all that calculating you did the first time, while you're still busy working your tail off trying to get everything ready for next frame :)

Your input timing may vary a bit frame to frame unless you wait for the start of VDraw, but you should try to keep your VBlank time pretty much full anyway, coincidentally keeping the input update near scanline 0. If you have time to get something done in VBlank, you may as well do it so you don't waste any more time and/or memory on double buffering.

At lower framerates, double buffering everything is pretty much the only way to go, unless it's some non-visible calculations (like physics or AI) that are slowing you down.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#34411 - sgeos - Wed Jan 19, 2005 3:37 am

People see in real time. They take in an image, and then another image, etc, etc. The interesting thing about the human eye is that there is an after image. After you see something, that image remains in your eye for a while. Its sort of like blurring frames together. Its probably something like linear interpolation between "frames" (more than likely in a software-ish layer; I've read that eyes do some information processing before reporting to the brain).

I think the after image lasts about 1/16 of a second, so to fool the eye you need to flash images faster than 16 FPS. Film runs at 24 FPS. Cartoons are typically drawn in 12 FPS to save money, but fast action is always drawn 24 FPS.

If you ran your game at 12 FPS (60 FPS / 5 frames per game tick), it would run at cartoon. Fast action probably would not look all that great, but otherwise it would be fine. You could run most of your animation at 15 FPS, and run fast animation 30 FPS.

Probably more than you needed or even wanted to know. The end result is that running the display one frame behind will not make a difference that any normal human will notice.

-Brendan

#34412 - Abscissa - Wed Jan 19, 2005 3:45 am

Could it make a difference in a rhythm-based game?

#34414 - Abscissa - Wed Jan 19, 2005 3:55 am

sgeos wrote:
I think the after image lasts about 1/16 of a second, so to fool the eye you need to flash images faster than 16 FPS. Film runs at 24 FPS. Cartoons are typically drawn in 12 FPS to save money, but fast action is always drawn 24 FPS.

If you ran your game at 12 FPS (60 FPS / 5 frames per game tick), it would run at cartoon. Fast action probably would not look all that great, but otherwise it would be fine. You could run most of your animation at 15 FPS, and run fast animation 30 FPS.

It's also important to keep in mind that the only reason film is able to look smooth at 24fps is because there is a slight motion blur in the film itself, as well as in the eye's perception of it. Games don't have that built-in motion blur, so in order to look just as smooth as a 24fps film, they have to compensate by running closer to 50-60fps. Usually 60, since most displays don't refresh at 50, so at 50 you'll get one doubled frame every few frames (Which isn't directly noticable, but just won't look as smooth as if the game's refresh rate and the display's rate were in closer sync.)

#34416 - sgeos - Wed Jan 19, 2005 5:10 am

Abscissa wrote:
It's also important to keep in mind that the only reason film is able to look smooth at 24fps is because there is a slight motion blur in the film itself, as well as in the eye's perception of it. Games don't have that built-in motion blur, so in order to look just as smooth as a 24fps film, they have to compensate by running closer to 50-60fps

I did not know that. Now I know why monitors refresh ~60 times a second. I had wondered about that.

Abscissa wrote:
Could it make a difference in a rhythm-based game?

It will make a one frame difference. I think that most people miss rhythms by far more than one frame if they miss at all. In other words, no. You should certainly accept input as "spot on" for more than one frame. Regular people can't respond to visual stimulation at 60Hz. (I also doubt they can respond to audio at that speed.)

-Brendan

#34422 - Abscissa - Wed Jan 19, 2005 7:03 am

sgeos wrote:
Abscissa wrote:
It's also important to keep in mind that the only reason film is able to look smooth at 24fps is because there is a slight motion blur in the film itself, as well as in the eye's perception of it. Games don't have that built-in motion blur, so in order to look just as smooth as a 24fps film, they have to compensate by running closer to 50-60fps

I did not know that. Now I know why monitors refresh ~60 times a second. I had wondered about that.

Back when 3dfx was still around, they had a little bit of difficulty at first pushing their Voodoo 2 cards (which could run existing games at a then-blazing 60fps) because of the common understanding about 24-30fps being the max we can perceive (which, like you said, is entirely true in film). They explained it, but a lot of people were still skeptical so they put together some tech demos that updated the left half of the screen at 30fps and the right half at 60fps (or maybe the other way around...). Side-by-side, the difference was very noticable. Not that it's hard evidence for what I said about 60fps, but an interesting thing that has always stuck out in my mind.

I'm not totally sure if that's why monitors use 60Hz though. I've heard that the reason for that actually has something to do with typical AC power being 50 or 60 Hz. Perhaps it's also because the phosphors fade quicker than on a TV so you'd get too much flicker (But maybe I have that backwards: maybe the phosphors were made to fade quicker because they wanted it to run at 60Hz). Heh, I dunno :)

Last edited by Abscissa on Wed Jan 19, 2005 7:05 am; edited 1 time in total

#34423 - tepples - Wed Jan 19, 2005 7:03 am

Abscissa wrote:
Could it make a difference in a rhythm-based game?

It might, especially given the extremely tight tolerances for "Flashing Great" and "Marvelous" timing in Konami's recent music games, but if you know that input is always going to be exactly 1 frame behind the audio, your judging code can compensate for that, possibly even by timestamping each button press with a VCOUNT value in the key interrupt.

Besides, if Konami were to make a port of four-panel, it'd probably be on the Nintendo DS, not the GBA. Though a 128 Mbit GBA Game Pak can hold roughly 40 GSM-compressed DDR-length songs plus banners and backgrounds, Niиtendo has promised much bigger cartridges for the DS. Besides, the Nintendo DS has the same initials as Dancing Stage, the European version of Dance Dance Revolution, which isn't called DDR because part of Germany used to be called that.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.