Once upon a time, I was young man in high school where our little computer club got a new PC with a color screen and a floating-point coprocessor. One fun little program I wrote was a simple gravity simulator, where a number of point-size assigned various mass flew around interacting with each other. We used that program and tried to set up initial setting for sizes, speeds, and directions of bodies that would result in some kind of stable system. More often that not, all we managed to create were comets that came in, took a sharp corner around a “star” and disappeared out into the void again. Still, it was great fun. And when I discovered Angry Birds Space it felt like a chance to try that again. Overall, “space” as my son calls it is a great spin on the Angry Birds idea. However, the way it is sold does not make me too happy.
In the INQUIRER article “Intel pushes Raytracing again“, they have an example of an application with almost insatiable appetite for processor cycles and processor cores. Real-time raytracing. With 16 full-size x86 cores, they can match the framerate of a regular mid-range GPU — but with picture quality of raytracing rather than the approximations of rasterizers. So, better quality, using something like 5 to 10 times as many transistors as the GPU would. This application can certainly use almost any amount of hardware, good for Intel 🙂
Over at an online publication called AI Game Dev, there is an elucidating post on how to do multithreading of game AI code (posted in June 2007). Basically, the conclusion is that most of the CPU time in an AI system is spent doing collision detection, path finding, and animation. This focus of time in a few domain-given hot spots turns the problem of parallelizing the AI into one of parallelizing some core supporting algorithms, rather than trying to parallelize the actual decision making itself. The key to achieving this is to make the decision-making part able to work asynchronously with the other algorithms, which is not trivial but still much easier than threading the decision making itself. The threading of the most time-consuming parts turns into classic algorithm parallelization, which is more familiar and easier to do than threading general-purpose large code bases. A good read, basically, that taught me some more about parallelization in the games world.
In my work at Virtutech trying to explain Simics and its simulation philosophy, it is often a struggle to get people to accept that what seems like pretty brutal simplifications of the world actually work quite nicely. Recently, I found a nice analogy in a golf game/simulator. The type where you swing a real club and send a real golf ball through the air.
Continue reading “Golf Games and Computer Simulations”