Runner/Progress follow up...

So... a quick reply to a what's been said so far, both here and on the GMC.
(Sorry... another long one)

First and foremost, please remember that while we plan to do great things with GM, it WILL take time. Lots of time. It's not something that will happen overnight, or even over a few months. Some of the "big" improvements may take a year or so to appear. Now this might seem drastic, but let me explain a little... First, YoYo is a reasonably small team, we don't have the 50 developers some games companies have, and that means we have other things to do as well as improve Game Maker itself. If we can get the runner onto lots of platforms we can make more money (for us and the developer), and that lets us hire more folk to do more with Game Maker. So first off we've take a long time to get the runner into a very portable format, and while that meant cutting it back, it also means we can start getting games out on many other platforms.

While doing this, we've obviously noticed many performance issues, some we've fixed, some we've addressed in a small way, and some require extensive rewrites and reorganisation on the code. Let's take the GML interpreter. The original by Mark was a pretty mean beast, functional, but unwieldy. Russell has taken some of the work Mark did and converted it into a virtual machine. This was a massive step, but at the same time a really small one. So instead of having lots of nested C++ code calling code blocks, calling loops, calling functions, calling code blocks and so on, we now have a very simple virtual machine loop. This opens up massive speed ups for the future, but also opens up full script level debugging. Allowing you, for the 1st time to stick a breakpoint on a script line, and then step through the code when the breakpoint is hit. Now... we don't have all the fancy GUI stuff. We have some VERY simple stepping code. Adding the rest into Game Maker will take huge amounts of work. And this is only the beginning of what's needed.

The problem with the current Virtual Machine is that it doesn't really give us the massive speed up we needed. This us because of the way variables and constants are currently handled inside Game Maker. The next monster task for Russell and the VM is to identify the correct "types" and link them with the correct functions. This would stop every Game Maker function having to check to see that the argument it's just been passed is of the right type. Very simple Virtual Machine opcodes like ADD should be a few lines long, but due to the way its arranged just now, it's pretty huge, and every opcode is like that. Over time, this will all be addressed, and GML will sped up massively, way beyond what is currently achieved.

Now, I only explain all this to show just how much work we have to do in the runner to get it up to the speed WE want, never mind the improvements that everyone else wants. Make no mistake, the VM will be huge, but it will take a long time to implement and make the changes to the rest of the runner so that it works the way it should. Now while Russell's doing that, I'll probably be doing other performance stuff, or even just adding functionality back in; as I said, the runner has been stripped bare.

All this means Game Maker won't change overnight. But it will change. Now, none of these things have been prioritised, meaning we may well do some Game Maker stuff well before the huge VM changes, so don't worry too much, but don't expect everything to come at once.

Now as to some of the other issues... Screen Tearing. This is usually done because it allows the game to "flip" screens quicker, it doesn't have to wait for a vertical blank and will present a more even game experience. When you're in a window, you don't really have a lot of say in how flipping is handled, but when you're in full-screen mode you can tell it not to tear. However... if your game drops from 60fps to 59, then you don't get 59, you get 30. It's pretty harsh. Now all this said... We can fix the tearing in future versions; preferably as an option. The ports don't "rip", because we modify each game we tune it to a specific (manageable) frame rate, and then it's tied to that. so 60fps or 30fps. In fact, it's a TRC failure on the PSP to flip outside a Vertical Blank.

Full screen BLUR. This is tricky. Many drivers override whatever you select. But we can see the need so will try.

Win98... sorry, it's dead. I loved Win98 se (MUST be the SE edition!), but then I also loved the Amiga, but both are dead, time to move on. :)

File size... It's not a huge concern in today's broadband world, but we'll always try and reduce when we can. But when most games are hundreds of Mbs in size, GM games are tiny by comparison, so it's not a worry.

OGG. Yes, when we have time to do it, OGG will be built in.

The rendering inside the C++ runner has been updated to DirectX9, not DirectX8. Audio has been totally rewritten, although it needs completed. Many functions no longer work and have to be re-implemented.

Networking has been removed from the C++ runner. It was an old dated monster that was in there (Direct Play). We will get round to doing a totally new networking system, but it's pretty low on the list.

No one asked about this, but it's actually important. point/texel sampling has been unified. The original code added little hacks to every sprite drawn to get correct texel selection. This slowed everything down and was a nightmare across platform. This has all been removed and done properly.

There's two reasons we won't add backwards file saving. First, as a company we want people to buy the new version so we add lots of new features to encourage you to swap. And second, because we've added new features, you can't save as an old version because those features don't exist. Things fall apart pretty quickly from there...

Graphically linking objects...yes could do. Not high on the list... but could do.
Vector collision code. Again, yes... could do. But there's lots of other stuff to "fix", so again, not high on the list.

External DLL's. While I'd love it so you didn't NEED external DLL's, we'd be stupid to assume we knew everything and thought we'd added all you'd ever needed. There's too many "what-ifs". We WILL incorporate some of the features of the most popular ones (one day.... over the rainbow), as that just makes sense... but what if you wanted to make a 3D glasses version for that new toaster that has a screen and windows Windows? Well... we won't be supporting that unless 100million people buy that toaster, until then use an external DLL.

Please stop calling me "Dailly", you're not my old school teacher and I've not been "bad". It's rude. :)

Lastly... remember that Russell and I have only really been part of YoYo for a short time, and as Sandy said at the time we're still a limited resource. We've had other priorities, some of which you know about and some you don't (and we're not about to tell you yet!), We can't do everything overnight. It's getting better, but it'll take time to get everything the way we want it.

Okay...REALLY lastly. We do read the GMC when we can, but there's simply too much there for us to keep track of everything, but when something "big" comes to light we will try and respond if we have time.

Now... as it's almost 10pm. I'm off to have my tea if you don't mind! Don't say we don't work hard here! :)