next »

[Schoq]

but 30fps doesn't have to feel less responsive than let's say 60fps.
by your logic, making use of lower resolutions than you are technically capable of would be dumb as you can put less stuff on a screen.
or using low poly models over high poly models would be equally dumb since they are less realistic.
or yet another comparison I don't want to type out right now

by your logic it shouldn't be expected that a modern high budget game is able to go above half the resolution of a fucking nintendo entertainment system.

[Sik]

You know, I just got reminded about Battle Fantasy... let's say that game completely breaks any common sense in terms of framerate. Like, every single graphic has its own framerate: each of the players, the shadows, the individual parts of the parallax, etc. That makes it feel really weird since it's nearly impossible to adjust. I mean say whatever you want, but when your character animates at 30FPS, your opponent at 60FPS, parts of the parallax at 30FPS and parts at 20FPS, the shadows at 15FPS... well, you get the idea.

for example: higher fps may be utilized to make a game feel more responsive, smooth and exciting, while lower fps can be effective at making them feel more slow and boring, as if the game is badly programmed or running on insufficient hardware, if that's what you're going for.

Actually, lower FPS can make a game feel faster, as stupid as it sounds. You could be travelling at the same speed per second, but because of the larger distance difference between frames, it actually feels like you're going faster in the lower framerate despite the fact that the speed is actually identical.

[gimymblert]

game that don't need high fps: low frequency of input, low camera panning, low camera movement, no timing requirement, low feedback needed

[quantumpotato]

that happens when game logic is not tied to framerate i think?

Yup, when logic is tied to framerate and heavy computation is performed then you see a framedrop.

Detailed programming how-to of game loop alternatives: http://www.koonsolo.com/news/dewitters-gameloop/


Game in my sig the AI copies what the player does frame by frame. I chose to implement with framerate & game logic tied together into the same loop so I would not have to evaluate change in deltaTime to determine if a new "logic frame" should advance or not.

[Sik]

There's also the alternative to give logic and drawing separate framerate (would probably require multithreading or at least input event timestamps). This would mean game logic can evaluate at 60FPS even if drawing takes too long and requires a framedrop. This could be a good alternative for genres where timing is extremely important.

[J-Snake]

If something like g-sync would be a standard no multithreading would be required to keep consistent logic updates(with enabled v-sync). Hopefully it will get there one day.

[Razz]

as a developer, 60fps is my standard. no exceptions

as a player, constant 30/60 is okay to me. hate inconsistent framerate though.

[Impmaster]

I love 60 FPS. PC Gaming Master Race for Life! (Although I really hate the people who actually believe in that term lol.)

[oahda]

Those* terms/expressions*. "For life" is just as ridiculous in any context.

[Impmaster]

but prinsessa i can totally imagine me on my deathbed, looking up at my children, and saying, "Console peasants get a real gaming platform." What else could I possibly do with my life?

[s0]

the "pc master race" and "console peasants" crap is really taking the system wars """"debate""" to new heights of stupidity.

(i know u were just joking impmaster, i just thought id say that)

[gimymblert]

mobile god laugh while burning whale dollar for fun because they can

[Sik]

If something like g-sync would be a standard no multithreading would be required to keep consistent logic updates(with enabled v-sync). Hopefully it will get there one day.

Yes it would be, to decouple graphics framerate from game logic framerate (since the latter becomes a lot more complex to compute when not using fixed step). It's being tied to specific refresh rates that would not be needed anymore, e.g. 100Hz (exactly 10ms per step) could become a common refresh rate for games. (I still prefer 60Hz for other reasons anyway, 60 has a ton of divisors)

[J-Snake]

Yes it would be, to decouple graphics framerate from game logic framerate

You wouldn't want to do that if you target a logic update rate above 50hz. Above 50 it should look smooth enough.

[Sik]

But you still risk graphics rendering to get too slow and result in a framedrop (especially in the cases of platforms without well-defined hardware specs, like PC or Android). The whole point of the idea is that if the graphics become too slow then game logic framerate wouldn't be affected by it. The problem with frameskipping is that input gets lagged (since it's only processed in the frames that don't get skipped).

[J-Snake]

The whole point of the idea is that if the graphics become too slow then game logic framerate wouldn't be affected by it.

So you fear the rendering can get too slow. Now I see your point. In that case, why not just simply disabling v-sync, that's as good as you will get. By multithreading you will add another synchronisation overhead; the logic thread writes the display data in some sort of cache and the draw-thread has to know when it is allowed to pull it out to display.

The actual point here I am interested in is not performance related. With g-sync fixed updates will be called consistently on a time line in v-sync mode, just as consistent as if you would run it without v-sync. In other words there won't be stuttering.

[Wytchlight]

I think it depends on the game, in a twitch shooter 60fps is great but in a RPG I think I'd rather they spent the extra 16ms making everything look prettier. There is no hard and fast rule here and I believe the demands for 1080p and/or 60fps on consoles are probably doing more damage than good.

[Sik]

So you fear the rendering can get too slow. Now I see your point. In that case, why not just simply disabling v-sync, that's as good as you will get.

And you keep missing the point. What happens if graphics rendering becomes so slow that it becomes much slower than the ideal game logic framestep, especially on low end systems where it may be prone to drop to below half the usual speed? (i.e. it wouldn't be "it barely misses the mark" but rather "it's struggling to keep up") And don't tell me "optimize it" when there are platforms where the system specs are unpredictable and the player may not be able to upgrade the hardware yet.

tl;dr it's about the graphics system not dragging down everything else when it becomes too slow, not about speeding up rendering

[J-Snake]

What happens if graphics rendering becomes so slow that it becomes much slower than the ideal game logic framestep

The visual output and the actual state of your game will be in a mismatch, regardless. If you disable v-sync your game logic will be freed from waiting for gpu. Your fixed timestep will update independently, even when gpu tanks. Note that the actual draw calls on the cpu can take a noticeable time, regardless whether you separate logic from draw calls, since it has to be done anyway. This is not how to use multithreading in games, make clear that the cpu and gpu is already working in parallel by construction, just disable v-sync.

[Sik]

If you disable vsync the game logic won't be freed from waiting for the GPU, it's just freed from waiting for the next frame. Your logic would make sense if the game ran too fast, but here I'm talking about a game that's running too slow and needs to catch up. Separating graphics rendering into separate threads prevents this situation, and while yes the GPU is doing the rasterizing on its own, the CPU still has to wait for the GPU to finish the current commands (not to mention actually building them in the first place, or doing stuff like figuring out which meshes to pass to the GPU to render, etc.).

Something tells me you don't know how vsync works.