next »

[J-Snake]

the CPU still has to wait for the GPU to finish the current commands

Examples?

What you are proposing makes only sense if you are facing the following scenario. Let's say you want to update game logic at 60hz but you can only render at 30 because the draw calls are taking that long. In that case you can multithread it, but it is only because of the draw calls, not because of gpu, even when the gpu is slow aswell. But be prepared to face a new realm of problems if you go that route, you will waste ressources aswell.

[Sik]

GPUs don't render every mesh in a single cycle.

And how would disabling vsync solve that? Worse, if you disable vsync in order to get variable framerate, you get an even worse set of problems since working with delta times is extremely easy to screw up for anything but the most basic animations.

In practice frameskip is usually the easiest option and is good enough, but for games that are extremely critical about detecting input at the exact correct moment (e.g. fighting games are usually considered like this) then either do game logic in a separate thread from rendering (so game logic always updates when a frame is supposed to start) or figure out a way to get the timestamps of all input events (so game logic can tell when an input belongs to this frame or not).

[J-Snake]

And how would disabling vsync solve that? Worse, if you disable vsync in order to get variable framerate, you get an even worse set of problems since working with delta times is extremely easy to screw up for anything but the most basic animations.

V-sync is also a way to sync the output of gpu with the cpu, assuming there are no bottlenecks. In your described scenario the gpu is still actively working while the cpu is doing nothing but waiting for the next monitor refresh. You can now disable v-sync and still keep the fixed update to ensure the cpu is ready to work on a constant basis. If you now don't manage to call the draw calls within the next fixed update then you also will not be able to call them with variable framerate in time. In that case, or if the gpu really tanks, you can try to distribute draw calls over several frames but that gets dirty. The games usually just lower the logic update rate aswell or simply don't account for such a scenario. New apis like dx12 try to solve that draw calls problem more natively, you are not bound to one thread anymore.

In practice frameskip is usually the easiest option and is good enough, but for games that are extremely critical about detecting input at the exact correct moment (e.g. fighting games are usually considered like this) then either do game logic in a separate thread from rendering (so game logic always updates when a frame is supposed to start) or figure out a way to get the timestamps of all input events (so game logic can tell when an input belongs to this frame or not).

That's not necessary. Fighters are designed to not face performance problems in the first place. A simple v-synced loop suffices as long as 60hz refresh remains the standard. Tekken4 runs even with different speeds on a 50hz and 60hz monitor, it simply syncs to one of the two.

[Sik]

V-sync is also a way to sync the output of gpu with the cpu, assuming there are no bottlenecks. In your described scenario the gpu is still actively working while the cpu is doing nothing but waiting for the next monitor refresh. You can now disable v-sync and still keep the fixed update to ensure the cpu is ready to work on a constant basis.

This requires being able to know if the GPU is still busy (so you can skip the rendering part when the GPU is too busy). Does Direct3D let you know it? Because I don't recall OpenGL letting you do it.

Fighters are designed to not face performance problems in the first place.

That is not going to work on platforms without well defined specs like the case of PC, by very definition. You simply don't know how weak the hardware can be. This is not a problem in a tournament scenario (the organizers will ensure the systems are up to spec), but this can be a problem for those playing at home or whatever and who can't afford a better system yet. It could also be the case that under normal circumstances it works fine but under certain conditions it slows down (e.g. recording gameplay footage for streaming or whatever). And sometimes people are just nitpicky.

tl;dr if you can't be sure the hardware will be up to spec, you have to account for framerate drops, no exception.

[J-Snake]

V-sync is also a way to sync the output of gpu with the cpu, assuming there are no bottlenecks. In your described scenario the gpu is still actively working while the cpu is doing nothing but waiting for the next monitor refresh. You can now disable v-sync and still keep the fixed update to ensure the cpu is ready to work on a constant basis.

This requires being able to know if the GPU is still busy (so you can skip the rendering part when the GPU is too busy). Does Direct3D let you know it? Because I don't recall OpenGL letting you do it.

You will have to do the dirty work yourself. Have you actually implemented what you suggested?

Fighters are designed to not face performance problems in the first place.

That is not going to work on platforms without well defined specs like the case of PC, by very definition. You simply don't know how weak the hardware can be. This is not a problem in a tournament scenario (the organizers will ensure the systems are up to spec), but this can be a problem for those playing at home or whatever and who can't afford a better system yet. It could also be the case that under normal circumstances it works fine but under certain conditions it slows down (e.g. recording gameplay footage for streaming or whatever). And sometimes people are just nitpicky.

You lower the graphical settings for that. I suspect some feel the obsession to work magic where it makes little to no sense. If the hardware is too weak for the min settings then it is too weak, nothing to be made here. For example if you play Super Street Fighter 4 on a pc, it will run slower than normal if your gpu can't keep up. Besides, in a fighter you also want perfectly synchronized visuals and not guessing a stuttering slide show. It is also a reason why the preferred platform for fighters are consoles and not pc.

[oahda]

Speaking of specs and settings and stuff.

When I look at requirements or specs, it tells me absolutely nothing. I've never had any idea of how to provide requirements for any of my games. I don't know what can be generalised by the fact that it works on the specs of my computer. How do I figure that kind of stuff out? I really need to learn. Or get some nerd to help me eventually.

[J-Snake]

There is nothing to know about it in practice. The games are simply tested on few cards and based on rough empirical guesses that is what you recommend. If you have only your own pc you can take it as the base for rough estimations. Important is only that you know what dx or opengl version you are using so that the user knows his gpu supports that or not.

[oahda]

How common is GL4 support now (4.1 in my case specifically, and v. 150 of GLSL)? Game won't be done for years, but still. I'm assuming it's not very common yet?

[J-Snake]

My first question would be, why do you need higher than 3.2 ? Or, in expectation of many old integrated gpus, why not sticking to 2.1 if you don't need newer feature sets?

[oahda]

It's no weirder than the fact that I'm working on OS X and it went straight from 2.x to 4.x between the last two versions of the operating system or Xcode or whatever it comes with.

I don't think I'm actually using anything specifically 4.x. 3.1+ style pipeline. So I can probably pass other numbers around 3.1+ to the context.

But.

Lower numbers might require lower GLSL versions as far as I've understood it and my GLSL might be kinda modern, so I dunno how many versions below I'd be able to go with that. I'll have to check that out, and whether that's even dependent on the GL version.

I do absolutely need 3.1+ feature sets but probably not 4.x. So I guess the question is about 3.1+ rather than 4.x. And I've just got to figure out what I mentioned about GLSL.

[J-Snake]

Ya, I heard weird mac stories about its relation to opengl. What I can tell you for sure is that there are a lot of cards, especially inside of laptops from few years ago, which only support up to opengl 3.x. One of the likes is a laptop of mine which is 4 years old but it is a decent laptop and will remain a decent laptop in the next 4 years for moderate needs, such as playing 2d games occasionally. We should probably take into account that everything produced post 2010 is for many consumers modern enough to keep for at least one decade. So you very likely would cut off a good bunch of the audience by forcing opengl 4.x., even when you release the game in few years from now.

[oahda]

Yeah, but I think the context will work fine with 3.1. I'm actually passing 3.1 to my context anyway and it reports 4.1, so I guess it's dynamic like that and the important thing is that I pass a number lower than or equal to the one on someone's machine. No need to recompile or make a settings screen or whatever for every single individual version. That's good. All I need to figure out is the lowest GLSL version I can use, then.

[DJFloppyFish]

its pretty crazy how nice certain ps2/xbox games still look because they maintain a consistent 60 fps.