We have a new home for Red Planet and Firestorm downloads! Check out the Downloads link at the top of this page or just visit http://www.elsewhenstudios.com/downloads. (the site uses the same users and passwords that the forums use, so you won’t be able to see anything until you have a forums user)
We’re a real company now!
We have forums!
Check them out at http://www.elsewhenstudios.com/forums. They’re pretty much just going to be for supporting our products, but we have a general chat area if anyone just wants to shoot the breeze.
To Whom It May Concern
For future reference, I offer the following:
- FileMode.CreateNew – Creates a new file and opens it if it does not exist. Throws if it does exist.
- FileMode.Create – You thought that this did what FileMode.CreateNew does, but it actually does what you thought FileMode.OpenOrCreate did, and so you should probably use this instead.
- FileMode.OpenOrCreate – If you use it to write to a file, robs your house, kicks your dog. If you use it to write XML to a file, also makes out with your wife.
The issue where sometimes pods will stop remembering their installed products will be fixed in a new launcher version distributed with Red Planet 4.11.3. We apologize for the inconvenience.
Moving on
We’ve officially started work on our new game engine, Spark! This is really exciting as this is our first new project in several years (finally we can move on from Red Planet). We decided to roll our own engine for a couple of reasons. First, we hope to design our first game to run on the pods and that brings in some design requirements. Anything that runs on the pods has to (a) support multiple monitors and (b) support the RIO as an input device. Since very few existing engines handle (a) and zero existing engines support (b), (except MUNGA of course, hehe) that pretty much leaves us rolling our own. The second reason is that we really like working close to the hardware when it comes to games and so rolling our own engine will be a really enjoyable endeavor.
So we’ve settled on the following:
- Ogre for the graphics engine
- CEGUI for GUI work (maybe, Slinky hates CEGUI but it’s pretty much the standard for Ogre so we’ll stick with it for now)
- Bullet for the physics (using OgreBullet to bind it to Ogre)
- RakNet for networking
- Google’s V8 JavaScript engine for scripting
- Rolling our own audio using DirectX audio and XACT (Slinky will probably talk more about XACT since he’s really excited about it)
Right now I’ve got a solution together that includes everything in the list except V8 (still working on including that). We’ve also fleshed out the initial design of the input system and Slinky’s been working on the initial draft of the audio system using dynamic devices loaded from DLLs so we can swap systems out later if need be.
Overall, I’m really excited about this new project. I’ve never designed an engine from scratch so this will be a really good experience.
Things never work out the way you think they will
So the culling wound up not working out. I managed to get the draw calls down by about 20% once I had the culling working right but that was without decals and the skybox. As soon as I added those back in the draw calls went up by about 500% and I couldn’t figure out why. Eventually I just gave up since I don’t think anyone is actually having any real frame rate issues other than just a desire to run at 60+ FPS.
We wrapped up the next release of RP: 4.11.3 and will roll it out after some testing up at the site.
In other news, I put together some logo ideas for our (possible) game engine, spark:
I’m a culling enthusiast
Last night I worked on adding frustum culling to Red Planet to see if I couldn’t get some optimization that way. We’ve gotten questions from some sites on why RP can’t run at 60 frames per second since the hardware today is so much better than the Division boards. Well, for one, the Division boards were beasts (the things had full blown Pentium processors on them for crying out loud), so the hardware today isn’t really going to be able to best it necessarily. The other point is that RP used to rely on the Division board to do a lot of work that modern graphics cards don’t do. This means that it has no scene management to speak of. The biggest bottleneck we’re finding is the number of draw calls that we make when rendering a frame. So when people started asking questions Slinky and I started brainstorming how we can get the number of draw calls down. One way would be to start doing some sort of culling so we’re only drawing what’s visible instead of drawing the whole level. Currently, all the static objects (things that don’t ever move) in the level get combined into a single mesh that is then drawn with as few draw calls as possible. The problem is that we still have to do a separate draw call for each material/texture combination which results in a lot of draw calls (101 on Wiseguy’s). By switching back to drawing each object individually and doing culling, I think I can get that number down a ways. The fog helps out a lot too.
So I added the culling last night but I think I got my algorithm wrong somewhere because I wasn’t getting the behavior I expected. I’ll need to take a look at it more but I really do believe that if I can get the math right, I might be able to get a 10% to 20% reduction in draw calls which should speed things up quite a bit.

