FunOrb Central: Part 3 - The Rise of FunOrb Graphics
22nd July 2009 � The Rise of FunOrb Graphics
Some of the new technologies we're integrating into FunOrb Central are improvements to the graphics libraries.
At the moment all FunOrb games display graphics using software rendering. This means that the computer's processor is responsible for all the drawing that the game performs, setting each individual pixel one at a time.
This certainly gives FunOrb games a great deal of control over their graphics, and is fast enough for most purposes. It does mean, however, that our games are what's called 'fill-rate limited' because each pixel that we change requires (more or less) one line of Java to execute. Therefore the performance of our games is chiefly limited by how many pixels we need to draw to in each frame.
Among other things, this limits the resolution our games can use. Let's imagine we have a standard FunOrb game, with a 640x480 pixel window (that is, around 300,000 pixels total) and that, on my computer, the game is managing to redraw the game 30 times a second (30fps). Doing the maths, my computer can write (set) around 9 million pixels per second. (As an aside, that's guaranteeing that each pixel is only set once - it's not always reasonable to arrange that.)
Now let's scale things up. The next standard window size we have available is 800x600. Now, to draw our game to the screen, we have to write nearly 500,000 pixels per frame. With my computer's 9 million pixels/sec budget, we're now only managing 19fps - which is getting to be a little on the slow side. At the next size up (1024x768) we get 12 fps, and as we approach cutting-edge gaming resolutions (1680x1050: 5fps) things get unreasonably slow.
Click here to see a larger version of this image.
As part of our plans to extend FunOrb games to these higher resolutions, we need to change our approach. There's a piece of hardware built into modern computers called a Graphics Processing Unit (GPU), which accelerates your computer�s ability to process graphics. It's used by modern games (including RuneScape HD) to run high resolutions at blazing speeds, and we're keen to take advantage of these capabilities with the next generation of FunOrb games running within Central.
The key advantage to using hardware accelerators (such as a GPU) is that they're capable of offloading work from the main processor (CPU). Whereas a FunOrb game currently has to individually copy each pixel from, say, a Kickabout League pitch texture to the screen, it could just request that the GPU perform the copy and the CPU could be used to calculate physics for the ball in the meantime. Also, because the GPU is a specialized piece of hardware, and running without the overhead of an operating system or Java environment, it can do much more work per frame.
One thing we'd like to do, then, is amend some of our existing games to use this to allow higher resolutions, starting at 800x600. We'd also be particularly interested in eventually supporting widescreen modes for FunOrb games.
Click here to see the full-sized image.
As you may have guessed, though, there're reasons we haven't done this already. There are two key problems with using hardware graphics acceleration, even when we're technically capable of it: One is that a lot of GPUs currently around are what's called 'fixed-function' - that is, there's a limited set of operations that they can efficiently perform (unlike the general-purpose CPU, which can be programmed to do just about anything). Some games work perfectly fine with this so Arcanists, for example, only really needs some sprites (images) copied to the screen, which is well within the capabilities of even the most basic accelerators. Other games, though, such as StarCannon, use more advanced effects, such as outlining, blur, glows or ripple distortion. In cases like these, some more effort is needed; we have to decide if the existing effect can be replicated, or, if we need to replace it, what can we use in its place that uses the additional power of the hardware?
The other main issue is that of compatibility. If you've ever visited the Java Options menu in the FunOrb site, you may have noticed there's an option to choose between signed or unsigned applets. Signed applets, assuming you permit them, have a bit more control over your computer - including the ability to access your graphics accelerator, if you have one. For those players that aren't able to run the signed applet (usually in places like offices or libraries, where the security settings on the computer don't allow it) or players who just don't possess suitable hardware, we need to make sure that the software mode of FunOrb games continue to be as good as possible - this can take additional time to design, develop and test.
I think the advantages, though, are worth it. While we're probably not going to be able to launch FunOrb Central and immediately have all of our games run at higher resolutions, the work we're doing on it at the moment is certainly laying the foundations. I'm looking forward to having more screen space to play with, both as a developer and as a player, as well as the possibility of yet higher detail modes. Just as a taster, have a look at the Kickabout League and Shattered Plans images.
Mod Artifice
FunOrb Developer
