31–40 of 58 posts
A rendered frame is just a view on some data. As soon as you couple state updating to rendering you're bound to encounter issues. This is what leads to games like ARMA who's FPS in multiplayer depends heavily on the performance server, which is insane.
Isn't it far better to split these jobs out to different threads? A rendered frame is just a view on some data. As soon as you couple state updating to rendering you're bound to encounter issues. This is what leads to games like ARMA who's FPS in multiplayer depends heavily on the performance server, which is insane.
One example of a problem with variable frame rate physics simulation was Quake 3, which allowed you to make otherwise impossible jumps if your frame rate was 125fps. This value exploited the rounding errors in the jump height calculation to get extra jump height. Some custom maps even assumed you'd be running at 125fps and would be unplayable if your hardware couldn't keep up. Demonstration and explanation here: http…
Space Invaders exploited the render-dependent timing of it's game loop to increase the speed of movement as the kill count increased. https://en.wikipedia.org/wiki/Space_Invaders#cite_ref-RG-3_1...
I find it funny how the thought goes to deep space, yet reaches so close to Earth.
I have a funny story about the deWiTTERS game loop that I wrote a long time ago (referred to in the article above) Back then I was doing mobile game development for PocketPC. After I left that company, some ex-colleague had to do some changes in my code, or port it, I can't remember. So he was looking at that game loop that I implemented, and was thinking "What the hell is he doing here???". So he did a google search…
Isn't it far better to split these jobs out to different threads? A rendered frame is just a view on some data. As soon as you couple state updating to rendering you're bound to encounter issues. This is what leads to games like ARMA who's FPS in multiplayer depends heavily on the performance server, which is insane.
Not necessarily. For games one of the things you're trying to minimize is time from user input to response on screen - that has to go through your input system, your animation system, possibly your physics system, and then all the way through the renderer. You need strict control of ordering and buffering. To allow stuff to be offloaded to another thread adds latency and can make things messy to control.
For simpler games, threads here don't help. They just hurt. Extra complexity, and likely extra latency (if only through mistakes and synchronization).
For more complex games, you can often get away with just going "wide" within the game loop. You have threads, but it's not about splitting off "animation" and "physics" jobs, but instead going wide when updating animation or updating physics. It's more granular and the high level coordination still happens in a traditional game loop.
If you want to get really fancy, your game loop starts updating a graph of systems of system jobs instead of a hardcoded list of system updates. If you strictly specify all inputs, modifications, outputs, etc. you can start making it automatically parallel by walking the graph and dispatching jobs that don't conflict with running jobs.
Even then you still have a game loop, you've just offloaded most of it's work to a fancy job system. Not all - you'll probably still have some API calls that only work on the main thread hardcoded into the game loop (e.g. for pumping OS UI messages using system provided APIs that aren't thread safe).
One example of a problem with variable frame rate physics simulation was Quake 3, which allowed you to make otherwise impossible jumps if your frame rate was 125fps. This value exploited the rounding errors in the jump height calculation to get extra jump height. Some custom maps even assumed you'd be running at 125fps and would be unplayable if your hardware couldn't keep up. Demonstration and explanation here: http…
One effect of linking game and real time was seen in Dark Souls on PC (at least it seems like that's what happened): the game was capped at 30fps. Once people hacked out the frame limiter their character's gear degraded at a higher rate.
While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if y…
What we didn't know was that there was a slab roller sitting next to us all along that the teacher hadn't mentioned during the start of the course.
Through natural progression of working on "advanced" projects, we were then introduced to the slab roller as it cut time to focus on the new techniques we were learning.
The teacher essentially did that for the remainder of the course and the ones that stayed behind to learn a bit more were able to use the shortcuts before the others because they were progressing on their off time.