Game Maker runner performance

I’d like to briefly address some of the concerns as to performance and what exactly we’re doing for the future of Game Maker.

First there have been several posts about the current Delphi runner and how bad it is. While this is a little exaggerated there are indeed several problems with it. The first thing any developer has to realise is that a platform will never be fully to his liking, ever. DirectX has lots of things I really hate about it, stuff that slows me down and makes my code ugly, but I don’t just sit back and complain about it, or simply demand Microsoft do something about their “core gaming tech” or I’ll swap to OpenGL, I work with and around the problem to get what I need. All good coders do this because every platform is flawed.

That said… there are some short comings inside Game Maker’s API, some of them I consider fairly nasty. Aragon1029 posted some tests on the GMC so I’m going to start out by looking at these. I’m not completely sure what “some” of them are about, but I’ll address them as best I can.

The fact that .EXE’s are made read-only (I think this is what he means) is something we can look at, but you really shouldn’t be changing the .exe so I’m not sure why this is an issue to anyone, and it’s certainly something you can get round easily for now.

The decompiler. We will look at it in the next version, but anything we do is fundamentally crackable; eventually. We’ll see what we can come up with.

Crashes. We need reproducible tests and bug reports. We have a bug reporting system, if something’s causing problems, use it. Mac users will tell you that there are regular updates for them, and once we get the same system in place for windows, you’ll get that too!

File access. While I’ve no idea why you would want to read/write very large files in GM, I can see that it’s slow. The main reason for this is reading/writing to any file system a byte at a time is ALWAYS slow, no matter what language you’re using. It needs a “block” read/write badly. This will be added in later versions. What we’ll probably do is some sort of very simple memory allocation with peek/poke access, and then let you save “blocks” from this. This would allow fast access to data and allow nice reading/writing of “types” from files, particularly if we allow something like Peek_Float(memory_handle,offset), Peek_String(memory_handle, offset) etc… Oh, and no... the program hasn't crashed when it's "not responding", it's simply not responding because it's taking a long time. Leave it for a while and it will eventually come back. This is what happens if you sit in a large loop without letting windows in.

The Format. Not sure what he means about this one…??? We do want to make some changes to allow it to be source controlled however.

Dragging the window = frozen game “while” dragging the window.. This is a windows issue. It doesn’t give you messages while it’s being dragged. So the timing stops. All windows apps experience this… *shrug*

The “varied” parsing of GML ( a=0 or a:=0 etc..). Okay, this is a feature of GML. It’s primarily a learning language so is very forgiving of these, kinds of things. In some respects I’d love to make it much stricter, in another, we don’t want to hinder beginners by making it hard to get up and running. However it IS possible to have a “PRO” parsing mode, so that when you want strict parsing, you can have it. But this is something we will think long and hard about so that we don’t affect beginners. At the end of the day, a lot of our customers are schools and universities that teach to non-technical students, so we have to be very careful about what we do with this.

C/Delphi string handling. [0] or [1]…. Being a programmer, everything starts at 0 for me. I suspect we’ll standardise this in the future, one way or another. Outside of that should throw an error. It’s hardly a show stopper though….

Font rendering. First the example given isn’t terribly realistic, just printing row upon row of outline text isn’t exactly common in games, and if it was slow, you’d simply do it a different way. That said, font rendering is definitely slow. We have already seriously sped this up inside the C++ runner, and I expect this to get faster in the future when formatting is all done on the fly. However… a full screen of “outlined” text will always be slow, but we might be able to speed it up more by giving dedicated GML commands to actually draw a full outlined font making it faster yet. So there’s several things we can do here, although the main culprit has been changed in the C++ one already. Speaking of fonts, there was actually a very good talk at SigGraph a few years back that allows smooth, crisp font scaling. This means we can reduce the number of fonts you actually have to include in your game, having a single font you simply scale, rather than having 5 different levels. We’ve used this before and the results were superb.

Runtime memory. We have addressed a lot of the memory issues, with some games using a fraction of the previous amount. This was caused by the runner creating every room and every instance at start up. So any game with many rooms had a huge overhead. We simply now create them from the “reduced” source asset when needed. This gave a huge memory boost. We’ll continue to address this as time goes on.

Now, there are plenty of other areas we really need to improve. The Code editor really needs to stay open, even if this means losing the external text editor I think this is a price worth paying. As long as the code editor is good enough, losing the external “text” editor option isn’t really an issue, but it’s one we’ll evaluate closer the time.

We also really need to revamp the room editor and there’s some very cool ideas for this, in fact I’ll probably do a whole post describing what we’re planning for this so everyone can read it in detail; some of the new features will be very cool. To give you a rough idea…. We’re planning on adding zooming, and allowing you to put down sprites/text as well as objects. This means you can decorate your level without creating loads of objects. The new tile system is still under discussion but will likely include multiple playfields with each “whole” playfield being at a single user defined depth, this will speed up the room drawing hugely. More on this later.

On top of all this, there are some internal operations that could just be done better. They work fine, but we can speed many of them up quite a bit. Collision for example, can be sped up a lot by simply being sneakier about how we handle it. Also precise collision is pretty slow, but as that only happens when things actually hit, it’s not the end of the world.

I’ve said this before, you write for the platform as best you can, and you work around issues you have to. All development is about doing that. If not, then I could draw 20,000,000 particles for a candle sitting on a table and not care. It’s about doing as little as you can to achieve the desired effect. Yes, we can and will speed things up in future versions. Yes, the C++ runner is much faster than the Delphi one, and is getting faster and more efficient all the time, and yes, windows/mac versions will get it at some point in the future instead of the Pascal runner. These things take time, a long time.

So there you go. I plan on doing another post to actually discuss the runner. Where it’s at, changes made, and discuss the benefits over the Delphi runner, and why the C++ one will be much quicker overall. So stay tuned.