3 ms·

I love big long articles on the main loop. It's one of those wonderful problems that seems like it ought to be easy but turns out to have lots of subtle (and im

I love big long articles on the main loop. It's one of those wonderful problems that seems like it ought to be easy but turns out to have lots of subtle (and important) complications.

karl_gluck 13y ago
The early GPU Gems books might be of interest to you. They are full of stuff like frame timing subtleties and interesting ways to solve common game loop problems. These days, you can probably get them for less than $50 each, too.
- vilya 13y ago
  GPU Gems is available online for free, courtesy of Nvidia: http://developer.nvidia.com/object/gpu_gems_home.html http://developer.nvidia.com/object/gpu_gems_home.html
deleted 13y ago
[deleted]
tracker1 13y ago
Agreed, the closest I have come to writing a game, was to write a server-side simulation engine that interfaced with a rather limited console web-app for communicating with the simuation (think fire chief on a radio communicating with units and dispatch). One of the biggest flaws when I was brought in, is that each avatar (unit/man/truck/etc) was setup with it's own thread that handled its' own move event timer. The issue was that a few dozen avatars in a simulation combined with dozens of simulations on a server would lead to thousands of threads each causing memory swaps, with the need for locking to avoid race conditions and other contention issues. It wasn't a real-time interface, so a second plus or minus to responses wasn't a huge deal. I refactored the avatars to work of a central loop. The only place with common interaction was a message queue for inbound/outbound messages to the various clients to the engine instances. This cut down on a lot of the cpu contention and similar issues. This would have been less of an issue for something simple on a single computer, but running many such simulations on a single computer, you come into different problems. It was actually fun to work around this.

I love big long articles on the main loop. It's one of those wonderful problems that seems like it ought to be easy but turns out to have lots of subtle (and important) complications.

karl_gluck 13y ago

The early GPU Gems books might be of interest to you. They are full of stuff like frame timing subtleties and interesting ways to solve common game loop problems. These days, you can probably get them for less than $50 each, too.

vilya 13y ago
GPU Gems is available online for free, courtesy of Nvidia: http://developer.nvidia.com/object/gpu_gems_home.html http://developer.nvidia.com/object/gpu_gems_home.html

deleted 13y ago

[deleted]

tracker1 13y ago

Agreed, the closest I have come to writing a game, was to write a server-side simulation engine that interfaced with a rather limited console web-app for communicating with the simuation (think fire chief on a radio communicating with units and dispatch). One of the biggest flaws when I was brought in, is that each avatar (unit/man/truck/etc) was setup with it's own thread that handled its' own move event timer. The issue was that a few dozen avatars in a simulation combined with dozens of simulations on a server would lead to thousands of threads each causing memory swaps, with the need for locking to avoid race conditions and other contention issues. It wasn't a real-time interface, so a second plus or minus to responses wasn't a huge deal. I refactored the avatars to work of a central loop. The only place with common interaction was a message queue for inbound/outbound messages to the various clients to the engine instances. This cut down on a lot of the cpu contention and similar issues. This would have been less of an issue for something simple on a single computer, but running many such simulations on a single computer, you come into different problems. It was actually fun to work around this.