The life of a Games Programmer

A game in 2 weeks.

2011-12-25T00:22:00.001Z

So, while at Realtime Worlds, they decided to let everyone have a play and gave them 2 weeks to do a game. We were broken up into several teams, each was supposed to have about 5 folk on them, however some had 7 or so, and out team had 3. Still, our team was awesome, and I wouldn't have had it any other way!
Although we had 2 weeks, we were supposed to spend the 1st week coming up with a few ideas, then the second week actually coding the chosen one. We had to submit the ideas to Dave and a couple of others and they would pick which one we were actually allowed to do in the final. I more or less ignored this, and spent a few days doing some research into imposters (more on this later), which basically allowed me to stack the deck so they'd have to approve the game we wanted to do. With only 3 members of our team, we played the sob story about how little time we'd have compared to the others, and that having done so much work on these imposters we should really be allowed to just carry on. Unlike most of the teams, I wanted to use the time to prove some tech that I wanted to use in MyWorld, not just have fun for a week making a game.

So what are imposter? Imposters are sprites that gave "many" rotations that you can use to "pretend" they are 3D objects - or entire 3D scenes for that matter! You can use them as a single billboard sprite rather than draw a complex 3D model, or even an entire area of a 3D world. They can be very handy. I'd done some work in them before where I had dynamically generated them, along with an Imposter ZBuffer which allowed you to drive "through" a sprite scene. Yeah... it's as odd as it sounds! Each texel in the imposter has a depth value, and that means a 3D model could move between it's pixels, unlike a normal billboard, where you could only move in front of, or behind it. They were pretty neat. But for this test, I was ONLY interested in raw throughput. So I did a bunny test (all good tests use bunnies!), and I tried to draw as many as I could. The scene shown here has around 50,000 bunnies. I have another image (I might upload them all to Flickr) that has around 200,000 at 38fps. These weren't static bunnies either, they followed a 3D terrain, and if you looked around them, they would look like a 3D model - pretty nice.

So, Dave and his gang picked the game we wanted - basically a Zombie tower defence game, and we had one week to make it work. We were given the world model in which it would all take place, but had to write everything else.

The first thing we did was to come up with a funny hovering Zombie type critter. He wasn't very pretty looking, but having no feet to animate meant a lot less imposters! This game was ALL about the massive number of things attacking you - kind of like the original doom, but on a bigger scale.

As a team, we were able to split things really easily. I did all the graphics and effects, Bill Henderson (who did the physics in Wild Metal Country) did the physics and general gameplay, and Sam Phillips did any graphics we needed. That said the art department weren't specifically assigned to a team and just churned out art as needed, so Tahir Rashid did all our 3D models (tanks and the like). This worked really well. While other teams spent ages in discussions about roles, and even changing engines part way through, we had really clear jobs and we all just got on with it. It was the most fun I'd had there in years!

Because of the massive numbers of Zombies the engine could do, I didn't even need to kill of dead Zombies, so corpses littered the field - it was very cool. They would pour out of the burrows hundreds at a time, till there was tens of thousands attacking! I did a very simple route finding system - and the would get stuck, but for the massive numbers, we couldn't do proper route finding for them - it worked pretty well though.

We put in lots of weapons to buy, and added a day/night cycle. During the day you could rebuild, add new weapons, and basically recover from the carnage the night before. At night, all you could do was watch, and keep your fingers crossed. Well... almost. You controlled a tank which you could go out and help defend areas, and basically blow up zombies on mass. Your tank took damage and you could recharge by returning to base, but if you'd left a hole in your defences, the zombies would get in and attack and destroy your base.

Some of the effects turned out really well (especially considering how little time we had). I wrote a small particle engine (that I donated to the other teams if they wanted it), and that let us do some cool effects and weapons. The Flame thrower and lasers were neat, as they'd set zombies on fire, and they'd run around with their head burning! The nuke was awesome! The nuke would explode in a massive BOOM, and fling everything - living or dead into the air, flying all over the place! WHEN you failed, you got to drive around just letting off nukes all over the place, it was very cool.

So, there you go.... You would think, with a game everyone enjoyed, Realtime Worlds might do something with it; but no. They were dead set on doing an amazing 3D world, and using it to play "Farmville". Ah well... It was good while it lasted. Still, the MyWorld tech was bought before RTW sank beneath the waves, so there is a remote chance that at least can still be saved. Of course, they'll have to hurry, I've seen several demos that are very close to what MyWorld might have been. That said.... I doubt they would have had flaming Zombies in them.

Oh... and Merry Christmas!! :)

Browser Share, and WebGL support. Is it worth using?

2011-12-16T20:02:00.001Z

As it's been a while since I last wrote here, I thought I'd ponder some of the things I've been doing lately. At YoYO Games, we have just released an update to GameMaker:HTML5 that contains the first Beta of WebGL. Now, WebGL is pretty cool, and the support inside GameMaker:HTML5 has turned out really nicely. At first, I was going to do a very simple port, getting it "working" and nothing else, but it soon became clear that this would be a crime! That I'd leave SO much on the table, that I should either do it right, or not do it at all.

So I did it right.

The great thing about how we created GameMaker:HTML5 is that it already does a LOT of the hard work required to do good hardware batching, and but making up highly compressed texture pages we were halfway there already! You see, the thing about hardware, is that they don't like to draw a few triangles at a time, they get really upset about it in fact. What they really want, is for you to submit the WHOLE scene in one go, then they can ignore the world and just get on with it! Now batching textures into large texture pages is the first step to doing that, because it allows you to draw many different sprite images, from the same texture page. You see, whenever the CPU has to change something; textures, blend mode, rotation/project matrix, render state, then it has to stop rendering, and when it does this, it just gets in the way. So removing unneeded texture state changes, is one of the big obstacles out the way. Sure you probably can't use a single page, but packing them means there will be minimal changes, and that's exactly what you need. We've had lots of requests to not load pages, but load everything in single images - for a load of reasons, but we've always refused, mainly for download and bandwidth speed, but also because we know graphics, and we know going forward, this is what you want.

So with this step out the way, I could start to collate triangles to draw. But there's a trick here too. So in native code when you use a vertex object, you can't partially fill a buffer, draw using it, then fill it some more as this (usually) causes a stall. You need to fill the whole thing, then you can set it, and then draw whatever you need from it. So we've created a system that builds up whole game frames of data, and then submits it at the end, and what this does, is allows us to completely pack some very large vertex buffers, which in turn, means we don't have to keep setting buffer streams, vertex constants and the like. Again... this is all good.

Lastly, the whole recorded scene is submitted in a tight loop with minimal state changes, and then we're done.

So.... What does this give us exactly? Well, in terms of raw throughout, we have an increase of about 10-15x!! On Chrome using canvas drawing only, we could achieve around 7000 sprites (30fps), where as with WebGL, we can now achieve around 110,000 sprites! That's a little over 15x speed up! Now, at this point we have two choices, first we could decide to use WebGL ONLY, and ignore all IE, Safari (PC) and current Opera users, or we can use WebGL as an upgrade only to help smooth things out - more on this later.

Now, if your like me, you would try and find some stats to help you decide. There are issues with getting stats, in that depending on where you look, you'll get significantly different ones! As a project for the reader, go and google browser share november 2011, and you'll find heaps of different pages all telling you different numbers, and this is because these sites simply record who visited THEM, and what browser they used. Now sites like apple, will mainly be visited by Mac users, while Linux sites may well be visited by Firefox users (just examples, no proof of this). This means each site has its own "view" as to what the share is. But lets take one view... the w3schools.com numbers.

IE:21.2
Firefox 38.1
Chrome: 33.4
Safari: 4.2
Opera: 2.4

I suspect IE is higher and Firefox/Chrome lower, but lets run with these for now. If I were to decide that I couldn't afford to lose the 27.8% of the market for my game, then I'd have to decide to simply use WebGL to smooth things out only, but lets take a closer look at these figures. Of the 21.2%, only 5.1% is actually IE9, and so HTML5 capable!

IE9: 5.1
IE8: 11.5
IE7: 3.4
IE6: 1.2

Now, this puts a different spin on things, because if your doing an HTML5 game, you only really care about users who have capable browsers, and that means IE9, Chrome, Firefox, Safari and Opera.

So, if we remove the IE8,IE7 and IE6 numbers, we get a different picture:

IE9: 6.1
Firefox: 45.7
Chrome: 40.1
Safari: 5.0
Opera: 2.8

Now, this means that WebGL capable browsers have just taken up 85% of the market - that's a lot! But there's more to this story, first is this Safari on Mac or Windows? Who knows, but Safari on the Mac also has WebGL (although it's off by default). Now no one in their right mind uses Safari on the PC as it's pants, but let 1% does. Aside from being mad, that adds another 4% to the WebGL market giving us 89% Lastly, Opera 12 (the next major release) also supports WebGL, and while there's no release date yet, if your planning a future game, it makes sense to include these numbers as it won't be far off, not with the speed browsers are currently being updated! So that's another 2.8%, tipping us over into 92.6%! That's a hell of a large audience for a WebGL only game! If it was reversed, and IE9 had that share, you can be sure folk would ignore the rest and write dedicate IE9 apps. There are also a couple of extra things to help tip the balance. First, most folk wanting to play games like this will happily install a browser that lets them, only real casual "mas market" gamers (Facebook types) will stick with what they have, but as Chrome has a nice plugin (even for IE6 users!) then you could prompt them to install this plugin and get them as well. which would increase your market share again!

So, taking the raw numbers, it would seem that - depending on the game - you could justify doing WebGL only... but first, a realistic view of these numbers.

So... yes, this is taking it to extremes. First, it's a single site that may well have biased viewing that skews the numbers in the first place, and that may lower your overall numbers by (say) 10-20% or more, which is a lot. Second, the Firefox and Chrome numbers ALSO include old versions which don't include WebGL (or they are too buggy or slow to be of any use anyway), although now that Chrome auto updates, most Chrome users are actually on the latest version - which is great news. Firefox is a different story, there are still FF3 users out there, and that sucks.

Lastly... Microsoft is about to change the way it's own browser is updated, meaning that everyone (pretty much that matters) will be upgraded to the latest that their OS can handle. This means Windows XP users will move to IE8, and Vista/Win7 users will move to IE9, and that brings a LOT of new potential customers to your game. Windows7 has (according to Microsoft), finally overtaken WindowsXP as an installed base, but even if its 50/50, that means only half would upgrade to IE9, while the other half would wither be stuck on IE8, or have Chrome/Firefox installed anyway, it's hard to tell.

So while there's lots of reasons to doubt the various figures, if you take what you see at face value (and in the wc3schools link above, you can click on each browser type to see the uptake of each version), then WebGL is now a viable gaming platform. Unless your doing facebook games (in which case your stuck with using WebGL to just smooth things out), you can assume the people coming to play your game WANT to play your game, and that means they either have, or will get the right tools for the job, and that'll be a WebGL compatible browser. Now, I obviously don't mean you should throw everything away and JUST use WebGL, that would be nuts. If the game can easily run in Canvas mode, then switch on WebGL as an option, but get the compatibility as well!

But.... if you have something special, that "works" in WebGL, then you should no longer feel you can't exploit it because IE9 can't do it, it's actually in the minority (no matter WHICH numbers you look at), and you'll still get most of the market being able to play your game - particularly gamers - and not JUST hardcore gamers, but more casual ones that WANT to play games, and aren't just looking.

So finally, a quick word about using WebGL to smooth things out. Well, if you are doing a facebook game, then you'll need to use Canvas, but the problem with that is while it's pretty quick, it's not ballistic. What that means is that it WILL take time to render your scene, so if the PC is busy (however briefly), your game will suffer. That is to say, if your game needs 75% of the time, and all of a sudden a background process needs 40%, then there simply isn't enough time around to keep it smooth.

Enter WebGL: Stage left.

All of a sudden, a game which used to require 75% of the machines time, now only requires (say) 20%, and that means when that pesky background task requires 40% of the time, there's still spare capacity, and your game won't hic-up nearly as much (or at all!), smoothing out the game play experience for the user. So, if it's an easy job to do (as it is in GameMaker:HTML5), switch it on and get the benefits whenever possible.

So there you go...Some things to think about. Now all we need is Microsoft to implement WebGL (or do a DirectX style interface like the WebL one), and we can move past canvas altogether and truly enter a world of smooth browser based gaming!

This post was brought to you by: bored ramblings on a Friday night! :)

Seamless tile scaling in GameMaker

2011-07-07T07:30:00.000Z

There has been a long standing issue with tile maps in GameMaker, where that if you scale them (or the viewport) you'll get cracks, or other tiles poking in and corrupting the display.
So the aim of this post is to show you why this happens, and how to avoid it. Some users have already figured a way around this, but don't really know the cause, so I want to also clear up what the hardware is actually doing, and why your getting these visual artifacts.

First, lets look at an image where cracks are showing through. The image on the right by Titanium, shows the kind of visuals you can expect to get if you zoom in on a tile set that hasn't been created properly. The problem with many tile sets is that they either have little spaces around them, or they are right next to other tiles, and when growing or shrinking (in particular), this can cause some really nasty issues to solve if your not sure why its happening in the first place. It's also one of these bugs that you'll be convinced are GameMaker's fault, after all... it allows you to scale the tiles, so it should work! Well, yes and no...

First, lets take a look at a couple of normal tile sets that you might create.
(Thanks to Titanium and TeamSkyfire for the tile sets.)

So, these are the most common ways people create tile sets. Either jammed up together, or with little spaces between them. Now for a non-scaling game, this is fine. You can happily predict what the hardware will render, and you can pretty much create the tile set anyway you like. But... what happens if we scale this? What does the hardware actually do? The tile shown on the left here, shows how tiles are mapped using D3D. The red line around the tile shows where the U,V coordinates are mapped to. As you can see it picks the center of the texel (a "pixel" in a texture map) to map, this is because this is where D3D "picks" the textel to draw, so we map there directly. Now 1:1, this is all well and good... so what happens when we scale?

Now, the issue with scaling down is that when you shrink, the UVs also scale down and try to fit into a compressed space. This obviously can't happen, so D3D picks which pixels to draw based on pixel centers. Now, if we are "just" moving into a new screen pixel, then because D3D uses the center of the pixel to decide what to draw with, it'll pick a texel surrounding the tile, not a tile texel itself.

Shown here is a tile being draw scaled down into 5 screen pixels. Now, this shows that when you overlap a little into the next screen pixel, there is a choice to be made. It can either drop that texel, or it can try and fill it with what it thinks is a valid texel. This is where a lot of confusion arises, as each graphics card actually does this in it's own way, but if you're careful you can work around it. Now lets say in this case it decides to draw that texel into the screens pixel, since it's now clearly outside our tile, where does it get the pixel from? Well, either the next tile, or the little bits of space you provided around the tiles. This means when it shrinks... you'll get cracks, or corruption.

How about we do this again, but this time we'll draw the other tiles around it; those that exist on the tile page next to it. Now you can see that the hardware will probably either choose the space between the tiles, or a tile next to it.

So knowing this.... how can we fix it? Well, if you draw from a single texture (not on a texture page or texture atlas), you have the option of using a texture mode called CLAMP. What this does is repeats the last row of texels infinitely off into the distance. This allows you to scale and forces the hardware to get the last row of pixels no matter what, and for scaling down like we're attempting to do, this works just fine. However, when using a TPage (Texture page), this isn't possible without a shader, but we can cheat by drawing this in ourselves!

Shown above is a "fixed" tile set, you can see it now has a "repeated" section around each tile meaning that when the hardware now overruns, it will always pick the last texel from the tile, rather than one of the spaces, or the tile after that! When importing these new tiles into GameMaker, it's important to make sure you point GameMaker to the tile INSIDE the "smear", this means you still get the original tile, and it now has a "smear" boarder area. The space is optional, but might help you keep track of tiles better, so it's up to you. Below is the resulting image of drawing the tile, complete with the smear. As you can see, it now has plenty of texels to chose from, and since they are all the same, your tile should be drawn correctly. (none of this is to proper scale... so don't try and measure things, it's just for illustration purposes.)

Now... technically... if you have a VERY large tile, and are zooming a long way out, you might need a bigger buffer zone. Also, if you're using bilinear filtering (where it blurs the image when it scales up/down), then there are further rules you have to consider. First, bilinear filtering uses 2 texels, and blends between them. This means it'll go to the next texel it "would" draw in the image, and that could be a fair jump if you've scaled out a long way. This may mean you need an even BIGGER border if you plan to scale in/out a lot. This is basically a "suck-it-and-see" situation. At some point, we might try and automate this into GameMaker, so that it creates the "smear" area for you, as it does take a long time to draw and maintain, but for now you'll need to do it yourself.

I have created a simple example HERE showing this in action, and it scales the sample map in/out reasonably far without any problems.

Collision detection...

2011-06-12T20:29:00.000Z

So I've been very busy doing the HTML5 version of GameMaker, and as I've been adding the collision code, it's becoming clear that the general way folk do collisions in GameMaker is pretty slow. This isn't to say that you can't do fast collisions in GameMaker, just that the way the samples are all written, it's no wonder some people find it painful and slow at times. So I thought I'd describe how I usually do collisions. Fo starters, I've only ever used what GameMaker calls "precise collisions" once in my whole career. And looking back on it, I could have easily gotten away without that as well; experience has it's advantages....

So first... what exactly does "precise collisions" mean? Well, simply put... it's using the pixel data in images to collide with other pixel data so that you only get a collision when actual pixels touch. Looking at the image of 2 circles here, you can see their bounding boxes collide, but the circles don't. What this means is that if you used a simple bounding box collision system, it would have triggered an event, while the precise collision wouldn't. Now, this may seem like a really obvious choice, if you use precise collisions, your getting them when actually happen. However... what does GameMaker have to do to determine that 2 random bitmaps have touched; because remember these shapes can be anything, but just circles.

Well, first... it has to loop through ALL instances of both these objects to find collisions with them. It does this simply by having 2 loops like this..

for( n=0; n<Obj1_Instance_Countl; n++) 
  {
     for( f=0; f<Obj2_Instance_Countl; f++) 
     {
       Test_Collisions( n, j );
     }
  }

Now, if you imagine all the collision events you have going on between different object types, you can see that this will burn up lots of time. One of the changes we'll make as time goes on, is to "bucket" sort instances. This means we'll only check for collisions of objects that are actually close to each other. But we don't do this yet....

So... once we have two instances that we need to test, what does Test_Collisions() actually do? Well, first thing it does is it checks the bounding boxes. This is a simple check and it allows an early out if they aren't even close.

if( bbox1.right < bbox2.left ) exit;
   if( bbox1.bottom < bbox2.top ) exit;
   if( bbox1.left > bbox2.right ) exit;
   if( bbox1.top > bbox2.bottom ) exit;

Now... if we were "just" doing box collisions, we'd be done... and an event would be thrown. However, because we want precise collisions, it gets more complex than that...

Next, the system works out the overlap between collision boxes (as shown in the next image). Now each "pixel" in the sprite can be treated as a TRUE/FALSE, meaning if it's not the background colour (in this case, white), then there IS a pixel there. So the image shown is two overlapping arrays. One holding a BLUE circle, and the other holding a RED circle. We then loop through the appropriate section (slowly) and see if we ever read 2 pixels from the same position. In this case,we don't. So no event has occurred.

Here's some pseudo code for the bitmap to bitmap collision detection...

for( y=YStartPos;y<YEndPos;y++)
  {
    for( x=XStartPos;x<xendpos;x++)
    {
      if(x < xSprite1Start) || (x> xSprite1End ) continue; 
      if(y < ySprite1Start) || (y> ySprite1End ) continue;
      if(x < xSprite2Start) || (x> xSprite2End ) continue;  
      if(y < ySprite2Start) || (y> ySprite2End ) continue;

      if(( CollisionMask1[ x+(y*width)]!=0 ) && ( CollisionMask2[ x+(y*width)]!=0 ) ){
           return TRUE;
      }
    }
  } 
return FALSE;

Now, although this is simple pseudo code, you can see this isn't going to be quick! Even though it's been narrowed down to the overlapping sections, it's still having to loop through the whole thing before deciding that there is no collision! Now, if you have many of these, it's going to bring the PC to it's knees! Worse still... GameMaker wants you to use precise collisions by default. This is horrible.

Now, it's true that on very RARE occasions you do want precise collision checking; Lemmings walking on the background, or They Need to Be Fed walking around shapes, these are rare cases, and can usually be done different ways. Lemmings never did full sprite to background collision checking, in fact all it did was test a pixel at the feet of a lemming, into the mask. And you could do that directly in GML if you wanted to! In fact, Lemmings had a "1600x160" play area, and you could easily convert this to a 200x160 "BIT" per-pixel mask. This would in turn mean you'd need an array 32,000 bytes long. And that fits nicely! If you didn't want to go that far, you could have 160 arrays, each of 1600 bytes long. then have a controlling array with each of these as a line of the collision. You could then easily check this array in GML using the lemmings X and Y coordinate.

But what about normal games? Shooters and platformers? These should never use precise collision detection, there is simply no need. First, when you use precise collision detection, there is no room for error on the behalf of the player. Everything must be perfect. The can't stray even a pixel into a baddie or background block. From a gaming perspective, this is horrible. There should always be a little room for error, because as humans, we simply aren't that precise when controlling games. Joysticks/keys aren't good enough, and our judgement isn't nearly good enough. So this means players end up either being over cautious and not pushing near baddies/backgrounds; or they simply get frustrated and give up.

So whats the best solution? Well, personally I've always either stuck with box or radial collisions. Both these mehods are fast, and simple to implement, and when you use things like buckets to gether objects together, you can also cut down on what you have to check in the first place! For those that don't know... "buckets", are a simple way of grouping objects/instances together into groups. For collision, we tend to have a grid of buckets and place objects into whatever "bucket" cell they touch. This means if you want to check collisions, you no longer have to check everything to everything... just everything in the surrounding buckets. This is much, much quicker.

So... how do you define a "fair" bounding box? I normally try and create a box that is completly "contained" within an enemy, this helps avoid cases (like the 2 circles above) where players die without ever touching baddies at all. Players are MORE than willing to forgive cases where you run into objects a little, but they are very unforgiving of cases where they die without hitting anything. So, as shown in the player character on the left, the yellow box is well within the player, but it's also more than enough to get killed, by baddies or bullets. Theres also no rule saying this is the bounding box you would use to collide with the background... so chances are you'll have something that doesn't let to player get to far inside the background. Whatever looks and feels nice is all you need; if the gun goes into the background, it doesn't really matter....

Now, while I've said I'd use box or radial, one thing I wouldn't do myself.. is use a bounding box check like the one above. The reason for this is that "IFs" are slow, so if you can minimise them, all the better! So I use a trick that I learnt from Dave Jones when he was doing Blood Money; I use a box center, with a 1/2 width and 1/2 height.

Now remember that these boxes are INSIDE sprites, so they will probably be well inside each other, meaning the player knows his goose is about to be cooked. So, in this case, you can see the 1/2 width and 1/2 heights are 16x32 and 20x20, while the distance to centers are 25x35. So how do I work out theres a collision?

This is pretty simple... so I'll do X, and you'll easily see how Y works. I simply subtract the 2 X coordinates, and this gives the distance between centers (in this case 25 pixels), and if that distance is less than both 1/2 widths added together, (16pix+20pix) then we have a collision! What this does, is lets us do the X check with only 1 IF. Looking at the code below you'll notice abs(), and normally you would have to do an IF in there, but if you're sneeky, can do abs() without an IF.

So for a simple bounding box, this is probably the quickest way, and you can see the code below is nice and simple. In fact, it's fair to say I always prefer having a center and width/height collision, but that may well just be the way my brain works!

   if( (halfwidth1+halfwidth2) < abs(x1-x2) ) exit;
   if( (halfheight1+halfheight2) < abs(y1-y2) ) exit;

Now, while this is fine for standard sprite-2-sprite collision, what about sprite to background? Well, GameMaker has a handy function move_outside_solid(), but when you have precise collisions, it will sit in a loop doing collision checks over and over as it slowly (at whatever "step" speed you've given) until your sprite is move outside of whatever collisions have occured. This is a horrible function, particually if you have look back at whats involved in doing even a single "precise" collision check.

Again, I've never needed this... For "tilemap" style background, I always collide to the tile array, and then move myself out of a background collision. So how do i do that? Well... If you use tiles that are a power of 2 (8, 16, 32 etc...) then it's an easy thing to move to a tile boundary. For example, If I collide with a 32x32 tile at X=64 and Y=32, and my 32x32 instance coordinate is 56,12 ( so it's overlapping by 24,12), then all I need to do to move the instance OUT of collision, is AND it with $$FFFFFFE0. This removes the lower "fraction" bits, just like doing:

   x = x-(x%32);

Now... even if you were to keep the system GameMaker currently uses, it would still be much quicker by not using "precise" collisions, but still slower than a normal "pro" would use. Now, I could go on and on about how to do efficiant collision detection, but really... I should really do a post on each method, and you would then easily see what system was best for you particualr case.. but lets see how much time I have. :)

So final words... Well, GameMaker is often accused of being slow, but in fact, on a modern PC it's a pretty quick system for 2D games. However, because of the fairly nice commands like the complex collision systems it has built in, it's very easy to abuse them, and think theres nothing wrong with your code... however, being a good coder is all about knowing the code thats being run, even if it's not yours! If it's your game, it's your problem, and GameMaker has all the tools you need to make a the game great.

GameMaker 8.1 - Faster 3D

2011-04-30T20:19:00.001Z

The next update of GameMaker will introduce a new, faster 3D system, but in order to use it there are a couple of new rules you'll have to follow.

Model classifications.
There are 2 different kinds of models; static and dynamic. Dynamic models are models that you create each frame, where as static ones are models you make once, then never touch them again - except to draw them.

Up until now, GameMaker has only ever used dynamic models, even for models where you use d3d_model_create(). In fact, all d3d_model_create() did was to allow you to pre-generate the primitives you would be using; nothing more. On top of this was the method of actually using D3D, which wasn't efficient either. All this added up to a slow use of the graphics card.

GameMaker 8.1 introduced full Hardware transform and lighting, but this has brought in a couple of new restrictions in exchange for the speed boost it'll give. First, DirectX8 hardware only allows for 8 lights, any more and you'll get unpredictable results - or none at all. But this just means you've to manage the lights yourself which isn't hard. Hardware T&L gives you a nice little boost on its own, but drawing quads (2 triangles at a time) isn't what modern hardware wants. It wants large batches, the larger the better. And this beings me onto the next speed boost.

Static Models.
The next update will introduce true static models; models you make at start-up and then just draw. The new system takes GameMaker models and then generates full hardware based, static VertexBuffers the first time you try and draw them. What this does is provides the hardware with exactly what it wants for rendering, a large buffer full of primitives. This new system allows you to up the number of primitives per model to tens or even hundreds of thousands of polygons per model. Unlike dynamic models, the more polys you have in a mesh the more you let a graphics card can do its thing.

The picture above shows the new faster system, and it shows it can now draw a 19,683 cubes merged into a single 236,196 polygon mesh at 96fps rather than 4! This is a significant boost, but to achieve this, you need to follow a couple of new rules...

Draw as much as you can in a single model call. Every time you stop rendering to do something else, the CPU gets in the way and the GPU gets bored!

Don't change the draw_set_color() of the mesh if you can help it. If you only need (say) the same mesh but drawn in 2 colours, then make more the model twice.

Your probably better drawing 5,000 polys as to 2.

Lastly.... this "batching" DOES change the order of things. It will batch triangles, lines and points together, and this means if for some reason you draw a triangle, a line then another triangle... the result MAY be different from what it was before as we now draw ALL triangles, then ALL lines, then ALL points. If this is the case, and you NEED the previous result, then you should probably draw it as a dynamic model instead; i.e. don't use d3d_model_create().

GameMaker 8.1

2011-04-11T13:12:00.001Z

GameMaker 8.1 will be released very soon, so I thought I'd talk about some of the major changes and what this means for both Lite and Standard users. First, naming; Game Maker has become GameMaker, while Pro has become Standard. Simply put, we think Game Maker feels like a description, while GameMaker is more like a product. It should also help focus searching in the future.

So... onto more interesting things - new features! The first big thing is the room editor's new ZOOM and PAN features. This helps bring the room editor more into what a modern editor should be, and it feels so much better, so much so, that swapping back to 8.0 is now a nightmare! What I find is that I now move around the level by zooming out from one spot, and zooming back into another. It quickly becomes a natural part of your workflow - as it should. There are 29 levels of zoom (14 up, 14 down) allowing you to zoom right in, or right out to see the whole level. This helps when using small sized tiles, just as being able to zoom right out helps you visualise an entire level.
This improvement in workflow is also the same for panning. Using the middle button to pan around instead of clunky scroll bars, again makes life much easier. To me, these two features are the MUST HAVE things in 8.1, and I'd recommend everyone try it before deciding not to upgrade - it's that important.
Initially the zoom wasn't going to be available in Lite, but we've since decided to add it; more on this later.
We've also updated the image editor to use the controls, while adding PAN to the path editor allowing much smoother workflow there as well.

The code editor has received a little love as well. I've increased the drawing speed in the code editor so large scripts should be quicker to edit. I've also added a couple of common requests. First, you can now select a block and use TAB to block indent, and Shift-TAB to unindent.
Another often requested feature was to add CTRL-F for searching, as it's such a common key in windows that not having it really breaks usability. So this has also been added.
We've also added the ability to cancel the codesense allowing a better smoother coding experience.

We have also improved 3d a little. Turns out hardware T&L wasn't enabled, so we've turned that on, but what does that mean? Well, modern graphics cards offload all transform and lighting calculations to the GPU, but if your using software T&L then the CPU does it all. This will give a little speed boost, although due to the way things are built in GameMaker, not as much as it should. There is a further update which should give a big boost, and one we've done in the C++ runner. This will come in future updates, but for now the hardware T&L will give a visible boost. We've also increased the ZBuffer from 16bit, to 24bit. This means there will be less artifacts as things intersect, and better depth control when things get very close to each other. So this should be great update for anyone using 3D, with better to come.
I've also added a new command for Standard Edition users, which allows them to control the ambient light level and colour. This again, should be a massive change for 3D users as it removes the jet-black background light level, into whatever you want! At the very least it means you'll be able to raise the darkness to you can always see something in the darkness.

We've also added a few new general commands.

dot_product(x1,y1, x2,y2)
dot_product_3d(x1,y1,z1, x2,y2,z2)
point_distance_3d(x1,y1,z1, x2,y2,z2)

These are common commands, so by putting them into native code, we give a speed boost to anyone using them. If you don't know what a dot product is, it's a very handy little thing that gives you the Cos of an angle between two vectors. The simplest use is for lighting, but since it effectively returns the angle between 2 vectors, it's very handy indeed; and now it's much quicker to use.

The last BIG thing is totally rewritten FONT generation. We haven't as yet rewritten the rendering (so it's actually still a bit slow), but we have rewritten the generation of fonts. This now gives much nicer, and smoother fonts, while at the same time fixing the horrible cropping some fonts used to get!
I've also updated the Font dialog, allowing you to type your own text in, and pick the language character set to aid multi-language support. Multi-language isn't yet complete, and is still bugged, but it will be fixed in a future update. You can see the new dialog

So...I said last big thing... but that's not true. The last BIG thing, is the auto-update system. This is huge as it finally lets us do small, quick updates, and to fix bugs that are stopping developers make the games they want. In the past, doing and update was horrible, but now, we simply release it into the web and everyone finds out about it and can download it. I hope this will make life easier for everyone!

So while there's a few other things in there - like full script searching, these are the biggies for Standard users, so what about Lite?

Well, first off you do get some of the new features (like the font update), but some are held back for standard users only (like script searching), and yes, there is a new TV style logo in the Lite edition, and there is an ad for GameMaker on exit. Upgrading to Standard removes these additions.

However, since we're adding further restrictions, we've also decided to "give something back". So, we have enabled ZOOM in the room editor (which is actually a biggie), and have also taken the decision to allow access to draw_sprite_ext(), which allows you to specify an angle, and an alpha value. This is another BIG change, as you will no longer will you have to pre-rotate all your graphics. This saves effort, and reduces the size of your games significantly.

So, along with a heap of bug fixes, we hope there's enough in here that makes everyone want to upgrade.

Game Maker and HTML5...

2011-02-27T14:17:00.008Z

So we've sprung a little surprise on folks by releasing a video of a Poker Squares playing directly inside a browser using HTML5, but how was this done, and what does this mean?

Well, first... we've made NO decision as to how this will be used. That is if it'll be available to the public, if we'll sell an exporter, or if we'll use it to publish stuff ourselves. This was done in such quick order that we really don't know where it'll lead to, but you can be sure we're now thinking about it. We obviously realise that everyone would simply want it as a free part of Game Maker, but that's unlikely to happen as it'll take time and money to make. Aside from that... we simply have no idea, so don't ask because we simply don't know yet.

Now... as to the tech demo itself. This was a lot of fun to do. I'd never touched Javascript before so I hard to learn Javascript and HTML5 programming while writing this, and while some of it was a little odd for me, it actually went pretty smoothly. In fact, far smoother than any of us thought it would. The project took a week and a half of Russell's and my time; pretty much to the exclusion of everything else. But even with that, a week and a half to produce what we did is an amazing result.

Before I go any further, I should stress this is a standard Game Maker game converted "automatically" into HTML5. We didn't rewrite Poke Squares to make it look good on the web, it IS the iPad version of the game running unchanged inside the browser.

So, there are two main parts to this demo...1st, the runner (or engine), and second the GML conversion. Now this is the first time we've attempted to write a Game Maker runner from scratch. When Russell and I first started we had a code base in the form of the C++ runner, and although we hated it, it was what we started with. So writing this version was a particular challenge to me because there were still areas we've never looked at, and this time I would have to understand the flow completely. It's ended up being a great learning experience, because many of these "black holes" have now been clarified. Some have had us rolling our eyes as to why it was implemented in a certain way, and others have lead to a deeper understanding as to why something was implemented in a certain way.

So with the runner side progressing, Russell then started on the GML conversion. What's really exciting about this, is that we compile the GML, then output javascript directly. This means that browser will run it as it would any native code (thanks to the Just In Time compiler). Now, while there's lots of padding around it due to the way GML handles certain things, it does mean we have now put the "GML to High Level Language" conversion to the test - and it works!! Boy does it work!! Russell has done a great job of this conversion, so much so that a couple of games convert directly, and are runnable inside the browser WITHOUT ANY GML/GAME MAKER CHANGES AT ALL!!. This is staggering really, that in less than 2 weeks we have produced something that would just convert a game and run it.

Now the runner has some issues to be sure. We are currently using the HTML5 canvas tag, although we may well swap the WebGL at some point because it'll give us everything we need. Currently the Canvas tag is lacking in some key areas; tinting images being one of them. I currently cache a slow conversion of any rendering with a colour tint. It works... but if you changed the colours a lot, it'll grind to a halt. WebGL would fix that, although there is word that canvas may well support this soon anyway.

Now it has to be said that currently, HTML5 isn't the best thing in the world. It's actually pretty slow on most browsers, and although Chrome is pretty good, IE9 blows them all out the water - its amazingly quick. FireFox 3.x is runnable, but slow, Safari is just rubbish, and IE8 doesn't work at all. All this will change over time. HTML5 is the way browsers are heading, and they'll all just get better and better.

That said... the engine, and the GML's javascript conversion runs incredibly quickly. ALL the slowdown is in pixel drawing, where as everything else runs in a few percent of the time. This is great news. Not only does it mean that the way I've rewritten the engine works okay, but for totally unoptimised code, the JIT is doing a great job with it. This is all good for the future.

Now, running this on an iPad or mobile device is still gonna be slow - really slow. These devices aren't optimised for this kind of experience, so don't think that once this is out you can do your own iPad games. It's just a bit pooh. This means our iOS and Android runner still has a place, and is still valuable to us. This also goes for windows and Mac though. Anything that will run in HTML5 should run MUCH faster natively. Soi native runners are still valuable there too.

Lastly... security. Yep. Put a game on the web and everyone will get your source. Not really much that can be done with that. We thinking long and hard about this one, it's nasty to be sure. Leave it with us... we know about it, and we're thinking about it. We do have a few ideas, but need to think about it. We don't actually think putting the "runner" on the web is an issue. All the "smarts" are in the conversion process, and that wouldn't be there. You can also obfuscate the entire code base. Still. We're thinking about it, lets leave it at that for the moment.

So there are two big lessons I'll take from this. First, I now have a much better idea on how to manage the C++ runner, and how to rewrite the bits I hate that are slowing everything else down (the events being the main thing for me). Second, we now also know we can do some amazing things with GML, from optimise the interpreter, to convert it to a whole new language to get it compiled - or even compile it natively ourselves. This is all pretty exciting stuff to us as it's not JUST about how well the HML5 port went, it's also how we can now use this invaluable information to make future versions of Game Maker and it's runner better for everyone! So while these aren't quick fixes or changes, we are now armed better for the future, so when we do a rewrite, we'll know exactly what we need to do to make it fly!

EDIT: Theres a discussion about this here: http://gmc.yoyogames.com/index.php?showtopic=501194 in the Game Maker Community Forums (GMC), feel free to join in there.

Reading GM suggestions...

2011-01-22T12:16:00.006Z

So, would you believe it... I found some free time. Probably because everyone at home is ill, or sleeping but time none the less. So I decided to read through the current GM suggestions listand there's some interesting stuff on there. I suspect much of it wil have to wait for the rewrite, but we can still do a fair bit during the many updates to 8.x we hope to do in the future.

Types... Not for 8.x (or not fully that's for sure)

Values
we'd like to get ints/bools etc. in there, but not sure when. Enums are also a must at some point - I hate having to define constants in the menu system. Unicode is a long term goal for Game Maker, but I think it may well be too painful for 8.x.

Collections.
Actually, I don't really like any of the collections. I think it's one of the few areas where you really NEED "class" based operations. So instead of giving you a handle to something, you actually get the object back. This will be a hotly debated topic at YoYo, that's for sure. We don't want to break everyone's source, but at some point, you have to make a change. This may mean keeping the old ones and giving some new ones, then removing the older stuff in a later version. But at some point, I think the old "handle" system should go. Again.... will be a huge debate internally on this, and we'll then need to open that debate up to external devs as well.

Scope.
Yes. Need Scope. I'm not a huge fan of C++ style namespaces, but they work well on C#. That said... they aren't vital. So not sure, another one to discuss. Multiple inheritance...Mmmm...prob not, but who knows. def not for 8.x. As to uninitialised variables not being 0, well.... that's needed for beginners, there's no doubt. We are coming to the conclusion that there may be a new level though - Pro (or something), where things get really interesting! Time will tell on that one.

Scripts.
Default args would be better. I suspect we may well start allowing proper script definitions, then all this would be possible. But it would also allow us to keep the current method for beginners. But I prefer proper definitions as it means you get proper error checking when calling functions as it knows the number of args it needs. We can work it out I guess simply by checking how many args it uses IN the script, but it's cleaner and less error prone to define it. I don't think you need pass multiples args back. Again, if you had proper defined functions you could specify "outs", but other than that, you can currently just use globals and set them. It does the same thing.

Flow control - not for 8.x
Multi level break? Don't be silly.

Editor.
non-modal editors. Sooooooooooooooooooooo YES! I hate the horrible modal dialogs! Hate them!! Hate them!! Hate them!! Hate them!! Depending on time, This might get in to 8.1, however we need to discuss with the community to see if there's any valid reasons to keep them. Mark thinks there is... but couldn't remember, so we'll open it up for discussion soon.
Better window management. Yes. def. Tabs would be nice.
Multiple selection/editing of tree resources. Yes.
Dragging resources between projects. This would be nice... but no idea when.
Group duplication. Another nice but "when we have time..." one.
Portable Installation.. We'd have to look into that due to piracy issues.
Escape closes... yeah.

Debugging
Whole debugger needs redoing, but that'll probably be 9.x or so. You need the new scripting engine for this. Once thats in, then pretty much all this is possible, and will be done. Not sure about dynamic recompiling though. It's nice, but might be tricky... Probably between game "ticks" is the simplest way.

Code
I've said before. The code editor is reasonably good, but just needs a little update to make it very good. Most of these should be done at some point, with luck during 8.x life cycle. I'd remove the external editor, but more on this later....

Objects
Bypassing D&D - yes.
Inheritance graph. I guess. I never use them, but on others games it might have been handy to see, and I know others use them.
Show GML equivalent of D&D. We hope to go one better than that...
undo.. yeah... need a better undo system over all. But that's probably a 9.x thing.

Rooms
Instance stuff. Yes. The idea at some point in 8.x is to move to a more select and change system, rather than the current kinda mushed one. We will start making everything brushes, and that will let us do all manner of things. Group selection/editing, grabbing chunks from the map, painting with them and all the rest. You should also be able to set some instance data directly from the editor. rotation, scale, colour etc...
Zooming. Oh HELL yes. Will be there in 8.1, in fact... it's almost complete. We might post a video soon to show it working. It's a massive MASSIVE improvement.
Layers/tiles. Yes. In fact, I want to completely change the tiling/instance system to be more "playfield" based. I find this is much less error prone, and will let the graphics engine draw everything much, MUCH faster. Currently tiles are really just very cheap instances, and everything is drawn pretty slowly. But if you do a proper tile/layer system, then you can blast whole layers very quicly indeed. Rendering would speed up massively. Not sure if this will make it into 8.x as again, we will need to take care not to break everything.
Grid offset/colour - sure.

Sprite.
onion skinning. Yes. Might be 9.x
Selection/manipulation... not sure.
Curves. Probably.
default precise checking. If this is the pixel checking for game collision, then no. This is really REALLY slow... so you should be forced to think about it. If its something to do with the editor, then not sure. Preload. I think all preload stuff is going.

Triggers.
Not used them yet, so won't comment.

Files.
split gmks... More on this later....
Remove redundant compression. The file format will be changing. More on this later.
conditional compilation. Yes. Would be nice. Not sure when.

Editors
Sound editor. Perhaps...
Particle/effect. Yes, at some point. Preferably right inside the room editor. Prob a 9.x thing, but you never know...

Extensions
DLL access to in game resources. Yes, would be nice. But tricky. At the very least getting texture handles and a pointer to variable "values" would be good, but I don't know how possible this is yet.
IDE mods. Not for 8.x
extensions in general will be changed in 9.x I think. We want to do a lot more with them. 8.x ones are pretty limited.

Drawing.
Animated tiles - yes.
isometric tilesets. Not high on the list. (I presume you all mean free assets here)
alpha in colour - oh hell yes! Full 32bit colour values rather than alpha, and colour would save LOADS of effort in the engine.
draw_*_tiled_region... not sure what this means. Draw a sprite./background tiled? yes, sure.
More vector support. more prims. bigger better drawing in general... yep
Layers - I'm a BIG fan of layers...
Correct normals for 3D solids??? They aren't correct? (spheres, cubes etc?)
More 3D formats - 9.x (at some point)

bloody hell this list goes on some!

Collision
Not used the more complex collision very much.. so won't comment. It's pretty slow though, so needs an overhaul.

Instances - sure. Though don't hold your breath for Lambda stuff.

Sound
Sound instance. Yes
formats - yes.
seek - probably
length - probably.
modification - probably
mute - yes. Master volume should mute media player music too really.

Rooms - yes and yes.
I'd also like to add scissor regions. So you can hardware clip to a rectangle.

Networking.
Total rewrite required.

Reflection.
Yes. But not sure when.... 9.x prob

Maths.
Well, better maths in general.

Files
ini files. INI files aren't too bad. But need some kind of instance or handle so you can have multiples open at once. You also need to be able to flush an ini file, to get rid of old stuff. Basically, a refresh would be nice. xml etc would also be good.
read whole file - yes. soon I hope.
game save/load. This whole thing needs redone. But it could throw an event.

Input
yes. Allow multiple mouse clicks at once as well (allows for multi-touch devices)
Joystick - sure.

Timing.
Mmm...
Naming alarms would be nice. I don't like just having alarm[3] either.
Hires timer would be great. It's available, so we should provide it.

Interface.
Message boxes. This is an on going debate. I think we should make all message boxes the OS native ones. This allows for Macs to look like Macs, and windows to look like Windows. But there is a backward comparability issue, in that the code allows your to change the look/feel. I think if you want to do that... do your own dialogues. SO not sure if it'll be in 8.x.
Not sure about the rest.....

Runner.
We will be changing the runner format, and making it harder to decompile. Will be done in 8.x time-frame.
Bytecode generation at build time. Yes. Not sure when. Might need the c++ runner for that.
remove debugging in release builds - would also be nice.
Unused resources. Yes, however... since you can refer to resources as strings, and then later make them into actual object references, then it becomes hard to actually know if someone has used an object. However, we hope to make this an option so if you don't do this, then we can strip out all the crap. We've seen sketches and photos in a games .exe as the developer as used it as a project workspace, but the final program has gotten it all as well. This should be cut in some way.

Wow. Okay, that was much longer than I though it was going to be..... Now just because I've said yes doesn't mean it'll happen tomorrow. And just because I've said no, doesn't mean it'll never happen. ALL these things are still up in the air, and under discussion. We're very aware that anything we change will have a massive impact on the community and developers work flow, so we want to be very careful as to how we proceed. I think I'll probably start some GMC topics to open discussion with the community about some of the changes, and we will speak directly to the devs we've been working with before anything major is affected. In general, additions will probably go right in, while changes may take some time to validate the need, and the effect on the community.

I've mentioned before just how excited I am to start working on Game Maker itself. It's a fabulous product, with a great community, and huge scope for change and improvement. I think we can drive Game Maker to be the tool to use for indi devs, but it'll take time. The real improvements will only come with the rewrite, but we should be able to start the process in this iteration.

In the next few weeks, you'll hear whats going to be in our first update, although you all know about the room editor zoom. We hope to do small iterations, more often. So with luck, for 8.x there won't be any more massive waits, you'll get updates much more often, and new features will slowly start to appear.

EDIT: Oh yeah... The documentation needs an overhaul as well. It should be more like DirectX with actual examples of function use, not just listing them - that's no use to anyone! However, this is a massive task. But one day, we will.

A new direction in gaming...

2011-01-15T12:12:00.002Z

I've been clearing out some of my folders and I discovered this, it's an article I wrote, way back in mid-2004 for MCV and it talks about appealing to the mass market, not hard core gamers. Re-reading it, I feel that very little has changed really. Realtime Worlds and APB epitomised this problem - to their cost, and while individual developers have taken some of this to heart via the new mobile market, consoles and PC games are still very much stuck in the old way of thinking. Sure, EA and other companies have just started to do the same in the mobile space, but it wasn't through choice, it was forced on them. Anyway, here it is. Perhaps I should do another, and try to predict what will happen in another 5-10 years! :)

A New Direction In Gaming

In today’s mass market climate, the idea behind making games is simple, spend as little as possible to make as much as possible. To do this, you need to get the highest percentage of players to development pound as is possible. For example, if you can get 100 mass market players for 1% spent on a project compared to 5-10 hardcore gamers for the same 1%, then you do what you need to get as many mass market punters as you can.

This makes sense, a lot of sense; so you have to wonder why so very few developers/publishers do it. Sure more and more players are being welcomed into gaming culture, but where’s the development cost going?

First, you have to decided how long an average project is, and for this discussion we’ll say two years. For many Large AAA games, this is conservative, since they can span 3 or more years (Half life 2 and Doom3 being 4 to 5!).

If we also assume that the cost is spread evenly (which isn’t usually what happens – costs usually go up towards the end), what portion of your development do gamers play? Well the mass market gamer will buy a game, and play only a small section of it before either becoming bored with it, or simply not possessing the skills needed to reach higher levels. Problem is, with games being so expensive, they won’t then rush out and buy another one, they’ll simply play this on off and on, and not getting much further, and getting more and more frustrated.
The Hardcore gamer will play the game from start to finish, and take however long is required to do so. This means he won’t buy a new game until he’s finished the current one. The developer’s problem is that they make content for the hardcore gamer, making games bigger and bigger to satisfy these people (and I include magazine reviewers in this as well since they play games for a living).

This pushes up team sizes, costs and risk. The problem is, around ⅔ of this is wasted effort. The casual gamer just doesn’t get that far, so the return on your development pound drops after the first few levels. Ironically, the first few levels are easiest to make, the most polished and usually finished inside a year to 18 months, and would probably reduce the development cost by at least half. So, what if games were ⅓ the size? What if they were ⅓ the price? This would place games squarely in the impulse buy bracket (around the £15-£20 mark), and as a result, people would probably buy more games. And even if they did finish the game, a new one isn’t 4 years off. Updates could extend the game easily with more levels; in fact the exact same levels that were going to be in the game in the first place, only now, the casual gamer will now want to buy and play them, pushing up the return on the development pound.

Teams should not only find that the dreaded overtime is now reduced giving them a social life, but that the next set of games are much easier to do. With a firm codebase to work from, extra features and content can be added along with new levels in around 6 to 8 months making new releases quicker to come out, again increasing the value of the development buck.

So what’s the downside? Reviewers will no doubt complain that games are smaller, and hardcore gamers moan that they finished it already and will then promptly rush out and buy more. However since the price is now at least half what it was, they can afford to.

They may have to wait 6 months for the next set of levels and added features and so on. But what percentage of your paying public is this? No clear study has been done, but several reports suggest that only around 10-15% of the market can be attributed to the hardcore.

Given a choice of paying ⅓ to a ½, most of your paying public would opt for the smaller game, given that they’ll never finish it anyway. Putting it another way, if GTA was ⅓ the price and ⅓ the size (say only 1-2 stages), would you care? Especially if you knew another was only 5-6 months away?

There’s also a sound psychological reason as well. When a player finishes a game, he gets a thrill from seeing it through to the end, and this encourages him to do it again. Being beaten over and over isn’t very satisfying, and will eventually drive them off. Valve’s “Blue Shift” was a case in point. Small, beautifully done, and possible to finish for the masses; not to mention only costing around £15. Reviewers weren’t happy at the size of it, because they were used to these games and finished them easily, but most people who played it, loved it.

Anyone who’s played Farcry will know that it just doesn’t stop! It goes on and on. By the end of it (and I cheated to see the end, only to discover around 15 huge levels!), you’ve had your fill. And if another one came out, I doubt I’d buy it, as nice as it was.

Certain games will always take time (Doom, Unreal and HalfLife etc.) since they also make engines to sell, and others will appeal to everyone no matter what the size (Sony’s Eyetoy being one). But for the most part, there is simply too much content in games. Anyone that’s played Halflife 2 will notice fantastic levels that you fly past and only see once; pointless.

The point is, that even though there is a small market for very large games, all gamers expect games to be large because the magazines, online reviewers and even publishers assume that every game has to be, when its simply not the case. Games are one of the cheapest forms of entertainment around; DVD’s and Cinema give you only a few hours fun at most for a lot more cost. However reviews and the hardcore seem to expect games to last for months, but without the price tag. This needs to change.

While games will always represent value for money, the size and scale of them needs reducing. Around the days of Shenmue on the Dreamcast, there was talk of episodic game creation. While not quite the same thing, the concept is sound. Smaller games, more often.

The Sims have proven the bolt on market very successfully, and while the game is larger than normal, it keeps extending itself with each “small” release. This in turn keeps the interest up, and sales going. The last problem here, is convincing publishers that they need to sell these games cheaper. After all, the public's used to paying £30-£40 for a game, so why stop? We can make even more money? Publishers must also be made to realise that its in their who best interests to reduce the price, and get into that critical impulse buy bracket. Once there, sales should go through the
roof.

Not only would this aid in getting a better return on development costs, but it helps the development team do less overtime per game, reduces the risk to the publisher, and thereby allowing more variety in gaming. It also helps the public by reducing gaming costs and by allowing them to complete games, which in turn encourages them to play more, and hence buy more.

Its time to stop coding for the hardcore gamer, and go where the money is.

Goodbye 2010. Hello 2011.

2010-12-31T12:07:00.006Z

I feel in the mood to ramble, so stay with me here :)

First... 2010. Been an odd year for me. Start of the year was pretty bad for me, I was having massive disagreements with the heads of the My World project. I felt they were killing it, making stupid short term decisions, and were letting a bunch of juniors who didn't know what the hell they were doing, redesign everything. I started this project; all on my own. There's been a load of posts about the rise and fall of Realtime Worlds, but I think the real crime (money aside), was that they just didn't listen. Over the years, I told them over and over; Don't do this or that, you'll regret it. But no... they knew better. Yet, years later, they realised over and over that they had been wrong. You hire experienced people for a reason, you should really listen to them.

So this was the start of the year. They drove me out far earlier than I would have liked, but then in stepped Sandy and YoYo Games. Having been working freelance for them for quite some time, I was able to just jump right in and get going. Working from home was hard at times, but then again... it was also a joy! With Russell starting just a few weeks before me, we were in a real comfort zone, and worked well together, using Skype to discuss the hard bits. The real long term plans were finally kicking off. After about 3 months of this, we were ready to look of offices, both in terms of needing a place for new hires, and the fact that Russ and I had about exhausted the ability to work at home.

After looking at lots of places, we got a great deal from Abertay that we just couldn't say no too, and we moved in. Starting up, getting an office and moving in is always a great time. You feel like everything is on the up and are extremely motivated, so we ploughed through the work. Kirsty and Andrew obviously joined us about this point, and the feeling of growth continued. Much fun and joy ensued.

We plodded along like this for a little then we heard a loud bang from across road. Realtime Worlds had imploded. While it wasn't a huge surprise, it was a shock that it went down so quickly. Still, every cloud and all that... we picked up a few great guys from Realtime Worlds, Stuart, Lee and later Malcolm. Geoff also joined us as we shifted focus from PSP to iOS.

The iOS port was done very quickly, and so in less than a month we hard ported the Win32/PSP version of the runner over to iOS and had submitted our fist App. The long term dream of Sandy's was now a reality. Games running on multiple devices. Community games being sold on other devices. Getting Stuart from the ruins of RTW was a godsend, he jumped head first into production and started to formulate the pipeline, and we soon had several games lined up, and were pumping them out at the rate of about one a week.

Abertay also came into it's own. A huge pot of student artists, testers and musicians ready to help us, and this was all very welcome.

Sandy then wanted to release a free game, something to raise our profile a little in the iPhone/iPad world, and decided a little Solitaire game would be nice. So Andrew started work on this little game. But it actually turned into a monster. Lots of little niggles and bugs were causing Andrew to pull his hair out, so I took a little break from the platform side, and gave him a hand. This was the first time I had really used Game Maker in anger, so it took some time for me to get my head around it. It's a totally different way of doing things (from my perspective). Still, I took Solitaire apart, and put it all back together, and we were finally able to submit it to Apple. Little did we know that it would cause such a stir!

Now.. Christmas is a unique day in app-store time. Downloads are huge for everything as everyone gets apps for their new devices, and even though Solitaire had been doing great already, it stunned us on Christmas day. 75,000 downloads in a single day! Of course... we didn't find this out right away; no. The Apple site was down for a week over Christmas, so late on the 28th December when we got the weeks numbers, we were ecstatic!

So... all in all, a good year, with a bad start. But a good year never the less. So what's next? Well, Sandy has already said we're now working on Gamer Maker 8.1, and I've been doing just that over Christmas. I've been itching to get my hands on it, and improve Marks already damn fine program. I'm currently adding the much asked for ZOOM feature to the room editor. Ever since I started playing around with Game Maker, I felt this was missing. I've never written a modern tile editor that didn't have a zoom. Simply put: you need it. Moving back from my test version to the 8.0 is now hard going! The lack of ZOOM in there is even more apparent, so it's great to finally get it in.

However, because of this... it also needs a little speed boost. So I'll also be speeding up all the drawing code that's in the editor. I was surprised to discover it's not hardware accelerated, so it's actually doing pretty well in it's current state! We will at some point change that, but not just now, that'll take more time, and we simply don't have that just yet. However... once we've done a new release, we'll be able to play with it in the background and make the improvements we need, and you want.

We will also be doing a load of bug fixes. As many simple niggles as we can, along with the more complicated ones that stop folk dead in their tracks - if we can (it's still a new code base to us). I really feel excited to finally be able to extend and improve Game Maker, and although it'll take a little time; it's gonna be great!

So finally... looking forward to 2011. What does it hold for us? Onwards and upwards I hope!!! We're building some real momentum here, and it's looking better and better for all things Game Maker and YoYo! We have big plans for both community games, and Game Maker itself, and I am literary tingling with anticipation! I'm a games coder at heart, and the thought of helping you make more great games is a real buzz.

So lets all hope for a good 2011, and we'll see you all on the flip side!!

Language features...

2010-11-14T16:43:00.009Z

So at what point do language features become a hindrance? Well having learnt using BASIC, I know what the features of other languages has allowed me to do. SO lets have a little lookie and see what these features have added.

First up: TYPES.

I remember coding on a ZX Spectrum and being incredibly jealous of the BBC as they had INTEGER variable types. This option allowed your code to run MUCH faster than using the standard floating point number variable. Now, back then ALL floating point code was done through emulation and so was much, much slower. Nowadays, doubles (which is what Game Maker uses) is all done in hardware, so why do we care? Well first, it's not always done in hardware, so we're back to the CPU doing emulation and that's really bad. In fact, even is we're doing this on a machine with hardware for doubles, integer computation is simply faster, what with the multiple execution pipes and single cycle execution on most hardware, if you can do it in integers, you should at least have the option. After all, how many FOR loops really need floating point? Lastly... How much would this really affect folk who don't care? I'd argue not much. For example...

   i = 1.12;
   b = 12;

compare that to something like...

   INT  b;

   i = 1.12;
   b = 12;

I'd say if you don't want to use them, it's not exactly going to bother you, but if you want to declare the variable (with INT, DIM, VAR or whatever we end up using), then you will not only get a speed boost, but it'll help you debug your code because you KNOW it can't be a fraction! That can be a valuable bit of info.
Second: STRUCTS

I'm wondering how I can even begin to say how important this is. Lets give a couple of examples. (this isn't proper code, so don't jump on errors please!)

    BaddieID[i] = id
    BaddieGridX[i] = round( id.x/16);
    BaddieGridY[i] = round( id.y/16);
    BaddieType[i] = enemytype;
    BaddieParent[i] = id.parent;

Now, in this little sample, we need multiple arrays to deal with storing all the bits of information I need for processing later. This is pretty common when coding and having multiple, dynamically resizing arrays is a nasty thing. So what can we do to improve this? Welcome to the world of structures.

   struct SBaddie{
      id,
      gridx,
      gridy,
      type
      parent
   };
   
   baddie.id = id
   baddie.x =  round( id.x/16);
   baddie.y = round( id.y/16);
   baddie.type = enemytype
   baddie.parent = parent;
   
   Baddies[i] = baddie;

(I'm deliberately avoiding adding any types here... but you can do)
Now... how I'd hook all this up is unclear, but having a single object (much like a standard, but very lightweight Game Maker object) with variables you can access can mean you can contain data in a single packet. This means you no longer have lots of dynamically resizing arrays (which is always a good thing), but if we are to expand what can be passed into functions, it also allows you to pass a lot of data in a single blob, removing lots of parameter stacking. This is all good, not only from a performance standpoint, but simplifies your think about about variables you're dealing with. No longer are you thinking about lots of individual variables, remembering which ones do what, you now have a single variable with all the information you need and this again simplifies your work.

Structures are good. Structures are VERY good.

Third: FUNCTIONS.

Being able to breakup large functions into smaller common parts is nice, not just from a readability standpoint, but for allowing you to reuse code better. It's a very good skill to learn; making code general so you can use the same function over and over again. This not only teaches coding flexibility, but allows you to start to make an API for certain features. Good APIs are a real skill, and one thats vital to learn if you ever want to progress as a coder. All that said, if you don't really care about coding and it's simply a means to an end, then being able to break your functions up does make code just simpler. Having a function that is pages and pages long is horrible to maintain, and will introduce bugs, so this would also help you reduce bugs as each function is smaller, and easer to think about. So again, its another good one.

Fourth: CONSTANTS

Simple one. PROPER constants. This is mainly an internal thing... but allowing you to define them in code would be great.

Now... I'd also say there are features that would just confuse most folk so we should just avoid them. Things like anonymous delegates, the C++ << style operator, operator overloading, templates, and even to some extent #defines; these are all simply not required inside GML. While I do like #defines, I think they can be so badly used, I'd simply avoid them.

EDIT: Oh... and the other thing I'd LOVE to add; argument passing to the instance_create(x,y,obj) function. This would be brilliant. This would allow you to do stuff like this...

    w = instance_create( 10, 10, cBullet, "smallbang.wav", false, sSprite );

I could have used this quite a few times already....

To GML or not to GML...

2010-11-10T20:50:00.006Z

So... I've been idly thinking... If I had bags of cash, oodles of time, and free rein, what would I do? Well, before I say ANYTHING else, this is nothing to do with YoYo. While its obviously been discussed, we haven't decided anything, and much of what I'm about to say goes against the basics of what Game Maker is all about! So don't get too excited/angry. Now that that's out of the way... what would I like to do? Like? No...LOVE to do...

Well, first... I like GML for what it is. A very simple scripting language. It does what it says on the tin (as it were), and that's a great achievement in itself. What I don't like about it, is that the syntax is a little woolly, and you can't declare types or sizes upfront. This has a huge baring on performance and what you can do to optimise the engine itself. So first and foremost I'd allow types. ints, bytes, shorts, floats and doubles along with strings and fixed size arrays (I think lists should grow, arrays shouldn't; personal preference). Not only are these things which would help you develop your skills, but it also helps you track down bugs. For example, I have an array 16 elements long, but I have a bug that touches element 4000! Currently, the array simply expands and it's hard to track down. However, if I knew it was only ever supposed to be 16 entry's long, I could set that as a fixed array then I'd get an out of bounds exception and hay presto! Bug found!

Next on my list would be structures. BLOODY HELL!! I MISS STRUCTURES!!! So many times in the past few months as we've started to push game out, we've needed to fix a bug, or add a little feature, and I've though, "well, just have an array of x/y coordinates, possibly an index to an object and then a type", only to actually realise.. I'd have to have multiple arrays for this. This is crap. So... Arrays next would be awesome, particularly when merged with real types.

Next up... I'd like objects to have custom functions you could call. So rather than having a script where you pass an object in, you call the objects function directly like so...


     Player.SetHealth( 100 );

This is nicer to me, and would help teach some basic skills you could use as you learn and perhaps want to move into other languages. So it's a plus to me. Not that you couldn't keep the current script method where you pass stuff into it, but I prefer this, it reads better to me, and keeps the code bound together with the object that it affects.

Another thing I'd love to add is the ability to have functions inside a single script. For now if you want a new function you have to declare it in the scripts section. Again, I think this is okay, but you lose the context in which you would probably use the function. Although using the new object function feature above would allow something like this, it still means jumping back and forth in source files for a single function. It would be much nicer if I could simply declare the thing; something like...


BaddieObject  FindBaddie()
{
   //Do something
   return the_baddie_object;
}

bool MoreBaddies()
{
   // anymore?
   return answer;
}


main()
{
     //Do stuff...
     while( MoreBaddies() )
     {
         baddie = FindBaddie();
         baddie.die();
     }
}

Now... technically... you don't need main(), we could just detect your not in a SUB function and do all that for you... so it would look like...


BaddieObject  FindBaddie()
{
}
bool MoreBaddies()
{
}


//Do stuff...
while( MoreBaddies() )
{
   baddie = FindBaddie();
   baddie.die();
}

Which would be okay for beginners I think. I suspect the real GOAL of GML should be to make it open to beginners, but allow for experts to excel in it.

Now what else would I add? Well...I'm a MASSIVE C# fan, so I'd love to add the ability to call .NET stuff. Not only would this open a fully functional plugin system (in both directions!), but would mean we could drop support for things like GML stacks, queues, lists etc. as .NET already has really cool ones.

But what about this plugin thing? Well. allowing plugins to see into the main program via .NET interfaces or reflection would be massive. You could suddenly get access to the entire rendering engine, the variable system, rooms, instances etc. ALL done legally via a simple C# style interface. Not only would Plugins become much simpler to do, but their power would be immeasurable! The whole of Game Maker could then be done as a series of plugins.

Yes I know... veered slightly away from GML, but it's all related. Still, all this is my little fantasy world. Not only would we have to make sure Marks vision of a learning tool is protected, and that everyone else agrees with the direction. We'd also have to make sure we had enough cash to be able to do it justice, and not a half arsed attempt that would alienating the whole community.

So... not quite yet then... Oh well. Perhaps I'll do another post soon on what I'd like the graphics engine to actually be like. We lose so much performance because of the simplistic interface, a more comprehensive one would allow proper throughput and would probably even allow real 3D stuff to be done; not that I'm a fan of turning Game Maker into a 3D tool though....

Writing cross platform code...

2010-10-11T19:58:00.007Z

You know, it occurred to me that some folk may find it interesting to see how we manage to port the Game Maker runner to other platforms, so I thought... Let's write about it. I then thought, well... it's not specific to the runner, Russell and I have been doing this for almost 20 years. I'll use the runner as the example, but the method holds true no matter what you do.

So the first thing you have to get into the habit of doing is abstraction. This doesn't mean layer upon layer of code and calls, but a very thin level that can remove any real platform dependence. Now, since I'm a graphics guy at heart, I'll talk about abstracting graphics code, but the theory is the same be it networking, audio or a basic file system. So here goes...

When we got the C++ runner it was all tangled up with windows specific code, from DirectX to MFC (Windows Foundation Classes), so the first thing we had to do was remove all the specifics, well... as much as we could. We spent months removing MFC and started using a simple WIN32 interface as this is much simpler and gave us control over the main loop which was vital to actually running on other platforms. We also started to add a thin layer between Game Maker, and DirectX. This meant that instead of calling D3D directly, it now called one of our functions, and we called D3D. This was done throughout the code, from creating textures and surfaces, to rendering lines and triangles.

The first thing we did was takeover the screen/canvas creation. This means we're now creating the device and have access to all the normal D3D functions inside our little world, and as far as Game Maker knows, it's simply asked to OpenWindow().

Next, we want to get something drawn, so we change all the rendering calls to a call to our triangle rendering instead so we now have access to all the vertices and can draw flat/coloured triangles where all the sprites would be. Most of these changes are pretty straight forward, and are a simple search/replace. Change DrawPrimitive() into a DrawArray(). Once that's done, we can start to change ALL the primitive types from being D3D specific, into our own custom values. So rather than using D3DPT_TRIANGLELIST, we now use our own ePrimType_TRILIST. So far so good.

Now there's lots of drawing code inside Game Maker, fonts, sprites, tiles and backgrounds and so on, and we really don't want to have to rewrite these every time. However, now that we have something that will render triangles in an abstracted way, we can rewrite them once, into OUR format. So the font rendering will now make vertices into our buffers, and use an ePrimType_TRILIST to draw them. Hay-Presto! The font code no longer needs D3D to render things. But what about the textures it uses?

Well, we created a new CreateTexture() call as well, which returns a simple void* which then allowed the internals of texture management to do whatever it liked. It also has the advantage that the texture system can now resize/resample textures if it liked, as Game Maker will never know; very handy when memory is tight! After all, Game Maker doesn't really care what the call is, as long as it can set the texture, so this works well.

So now we have the ability to render primitives, and create/change textures, so what else? Well there are lots of render states to do, so we'll need to abstract them as well. This means things like the D3D culling renderstate (i.e. D3DCULL_CW) now changes to eCull_CounterClockwise and so on, until every state, every D3D call has been abstracted away into a new interface. But why bother? Well, for a start it means that we don't have to include the D3D headers on other platforms! D3D obviously has windows specific includes internally and that would end up being a nightmare, but my abstracting things a little, the other platforms have become much simpler to port to.

And, although it seems odd... D3D is in effect our first port. Game Maker now runs using YoYo's interface and API, which then has a set of classes which translate things into D3D calls (which has been upgraded to DX9 BTW). Theres lots of other functions which we abstracted, matrix operations, viewports, grabbing screens, surfaces and render targets and the like, but at the end of it, we have a clean, non-D3D interface. And we can now port it easily.

Now, this method is true of any platform specific API you care to mention. We also changed the Audio system on windows to XAudio2 (the latest DirectX audio system), and we did this by simply having calls to Load a sample and return a void* which Game Maker can then use as a handle to the sound,midi or MP3.

Now... the real trick here is to get most of the code to be platform independent. Although things like fonts draw to the screen, they don't have to know anything about the underlying API. All it wants to do is set a texture, some blend modes, and then give you some vertex data. The interface then handles the rest.

Once you have a set of files that ARE platform dependent, you can then port these to any system you like. The real win for this, is that any new feature you add to Game Maker, will usually appear on all the platforms at once. Only the most obscure thing like grabbing screen rects without using the CPU (the PSP needs this) will have to be hand crafted. But other things like optimising font rendering will be the same on all platforms, and only require to be written once.

So, for the record.... we now have a Win32 DirectX 9 render, and PSP render, and an iOS OpenGL ES render. Making a Mac OpenGL render would now be trivial as the OpenGL ES is actually a subset of it, so we can actually ADD features!

As you can see, making a true platform independent bit of code is fairly simple, as long as you think ahead and don't try to be too clever. It also means that all systems benefit from any core changes, and porting to another system can sometimes be achieved rapidly if required.

Now, porting to something like iOS is interesting because your supposed to use Objective C, but in reality... anything that can call C++, can use the whole runner. We use Objective C to create the display, flip the screen and get the touch input, but everything else is done in the normal way using the C++ runner. Any system that allows C++ code, can be done like that making it a trivial port (i.e. simple to do, but takes a little time). If a platform doesn't allow calls to C++ (like XNA), then this means you have to write directly in the provided language, and that then becomes a monster task to rewrite the whole engine. It also means any improvements to the C++ code must then be replicated to the new system, which isn't very nice.

The Game Maker C++ Runner is now very portable thanks to the abstraction it's received, and we also know it's very hardware independent as it runs on Intel, MIPS and ARM cpus. Different CPUs can also give some headaches as byte order can flip, and many systems don't let you access INTs on non-INT boundaries and so on. We've now been through all of that, and now have a very portable engine which is looking good for the future.

So there you go... This is how we ported the runner over, and how other platforms suddenly seem to spring up. All that's really missing from it are some of the features we removed initially to get it all working, and they will come back in time, and one day, the C++ runner will be THE way to run Game Maker games.

Runner/Progress follow up...

2010-10-01T20:51:00.004Z

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! :)

Game Maker runner performance

2010-09-29T09:07:00.009Z

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.

What makes a profesional programming language?

2010-07-27T17:24:00.005Z

One thing that I find a lot working at YoYo games is the disrespect GameMaker's built in scripting language (GML) gets. You see it all over the various forums, and in responses to glog entries, that if you really want to make games, you should learn a proper language. This does annoy me, and I'll explain why in a moment... First, I want to explain where I've come from in terms of games, programming and how I got to where I am today.

So, when I was around 13 a friend of mine got a ZX81 and we'd sit and play games, type in programs from magazines and on occasion try to make the computer do what we wanted it to do. Later, I bought the ZX81 from him and would make little games at home in BASIC, and then started to learn Z80 assembler. I then progressed to the ZX Spectrum and wrote a database for a solicitors office using Sinclair BASIC, and the progressed to the Commodore Plus4 where I wrote a few games in a mix of assembler and BASIC. Eventually I progressed to full assembly programs and moved onto the Commodore 64 and my first job at DMA Design. While writing Ballistix and Blood Money I learnt Pascal and wrote several tools on the PC for development, and when I progressed to the PC Engine and its 65c02 assembler, I again wrote many tools in Pascal, including a full (and very powerful) remote debugger. The same goes for the SNES and 65816 assembler, while all it's tools were in Pascal on the PC. While coding on the SNES I started to learn x86 assembler on the PC and did lots of game stuff in Pascal and x86, including the prototype that lead to GTA.
I then moved onto C and used x86 for all rendering stuff, and eventually SIMD and C++. I did lots of JAVA here including mobile phone J2ME and Java Applet code, including some Java Virtual machine assembler (if you can believe that!). I then did PS1 and PS2 C, and learnt some MIPS assembler while also playing with the Gameboy advance and it's ARM assembler. At home I was also doing some Dreamcast stuff and some SH4. These days I hardly ever touch x86 assembler and it's mostly C/C+ or C#.NET, although I'll probably do some Delphi pascal again soon. There you go... a pocket history. I've missed loads out (particularly home projects), but it's pretty close.

So... Why do I bring all this up? Well, you can see that I've progressed through many languages and use whatever is appropriate. On the PC where the machines are fast (these days), I don't need to dip into assembler any more, while on the PSP I'll happily drop down to MIPS assembler again.

So what makes a language? Well, you have variables, loops, branches and function calls. In more object orientated languages, you also have objects you can access, but these certainly aren't a requirement. Old machines like the C64 or spectrum didn't have them, and they managed quite well without all that. You just arrange your data differently, but it's all pretty much the same thing.

GML has all of this. The loops and branches are there, as are variables and function calls. In every important respect, it's a full language. Some might even say it's much nicer to use as you don't have to worry about lots of things and it makes it much simpler to throw things together. There are lots of ways to write games, I used to write in BASIC as did many others, some still do. There's plenty of jobs around for Visual Basic programmers, so this is definitely a proper language, but I would never write a game in Visual Basic. I would use a language better suited to making a game. GameMaker gives you LOTS of tools and support to quickly make games, just like many other game making tools do, but very few pull everything together for you into such an easy to use package.

So to put this in context. There IS no professional language. You use whatever you must in order to make the application or game you want to make. If you make a game or application, and you sell it, then it's a professional language, it's that simple. There have been many games created and sold that were done inside GameMaker, and there will be many more. If you make a Tetris game, can the end user tell that it's written in Game Maker? Would they care? No of course not... If your talking about a game, then the end user just wants to have fun and only cares about if your application delivers that.

Now... if you want to make a game for console, then Game Maker might not be the right tool - yet!! But that may well come, then you'll have a much wider choice as to what the right tool is.

In the old days we used to mock C programmers for using slower languages than assembler. We could do at least twice the amount, but they would develop twice as quickly, and now we hardly use assembler at all! We're getting the same thing with GML. Unless your talking about making Halo or GTA 6, then GameMaker and GML may be just fine. I suspect all 2D games (pretty much) can be done with GameMaker, and a LOT quicker than if you tried with C++ and DirectX too.

So... ignore the requests to learn a proper language. Use what's right for you, and what makes your life easiest.

YoYo Games - Competition05

2010-05-12T12:56:00.012Z

We've just finished the judging on YoYo's latest competition, and overall I think it was a great one. Some of the entries were outstanding, some were innovative, and some pretty, some were amazingly well presented, and yes...some were poor. But as this was the 1st competition I've helped judge here I was keen to look at every entry, and it was hard going at times. We had so many games just to get through, never mind trying to narrow down the number to an acceptable level.

However, we finally came up with the winners and most notable selections. However, it's worth saying that there were a good 60+ more that were notable, and even some that never got past the 1st round were still pretty good, but I knew there simply weren't going to progress past round 2, so there was no point in adding them to the list. On the whole, I think there were around 100-150 games which were extremely well done, with the rest being on average; pretty good. Very few were actually bad. For a community like this, that's staggering. Almost 500 games that were at LEAST okay.

We particularly loved some of the retro or simple styles, and while the winners were of a more standard fair, there were many games like Switch which displayed a simple, clean style, but great gameplay.

I don't want to go on about the list we posted which was a group decision, and one were we all agreed on, but I did want to give a shout to some of the others that I personally enjoyed... (not in any particular order)

The Scribbling - A pretty game, nice style and with a little more work, could spawn a few imitators. Although gameplay was a little clunky, it has a lot of promise.

Extinction 3D - This was quite impressive and looked very pretty as well, however it was lacking a certain "something", it felt a little repetitive and that meant it didn't have the longevity that other games could have. But another one which shows promise.

Ninja Penguin - I loved this, great little story and very well presented. I particularly loved the way it had a split story! Brilliant! Initial battles were a little too tricky though, but with a little T.L.C., it could be a real winner.

Sonneillon - This game surprised me with its presentation, and in-depth gameplay. It's amazing that there was such a variety of games types, and that they were so well done. I enjoyed playing this one, and it looked fabulous, but it was a little too slow (as many RPGs are) to really capture your attention. I think if the story was refocused a little at the start, so that it was a little more engaging, it could also do well.

Western Shootout - Great little "fun" game. Nothing more... nothing less. A great quicky, and I'm all for them.

Ne Touchez Pas IV - Unusual game, but I really enjoyed the way you could select a different vehicle, and then have the whole feel of the level change; very interesting indeed. I think it was a little too simple looking overall and would benefit from a stronger art style; perhaps even the old Star Wars vector arcade machine style.

two-sides-of-a-one-square - Great art style here... rough but consistent. Holds together well. Another one that needs a little love in terms of gameplay, but one to watch.

The Core - Another game which has great style, amazingly well presented. Game was okay too, but being a simple breakout style game (really..), it was only going to get so far in a contest which has such a depth of gameplay from other entries.

Pinball Panda Ultimate Toybox - I'm just listing this one because I love these games. Great fun, fits the format well. :)

Fate Elaments Intro - Nice little effect. I'm a big fan of "2D" platforms with a little depth, I think they look great. Gameplay on this one was a little flaky, but has some nice possibilities.

Now... again these are just a few that stand out from a crowd of great games, there are many more in there that I enjoyed that for one reason or another, just never made the cut. I think the whole community should be pretty proud of itself and the overall level of quality they managed to achieve.

For those that didn't make it, well there's another competition coming soon, so you've another chance to show us what you can do. One thing I will say; while stunning graphics and sound aren't everything, presentation, handling and a good difficulty curve is, so you should take a little time to try and make these are slick as possible. After all, you can always replace graphics and sound, but if you replace gameplay... then it's a different game altogether.

DMA Design radio program

2010-05-02T18:16:00.003Z

A while back the BBC did a little radio program on Dave and DMA Design, it's a pretty good program and well worth a listen. It's mainly four of us talking about how it all started, and you can hear Dave, Me, Russell and Steve talking about how it all got going. Anyway... it's pretty good, so have a listen.

Texture packing....

2010-04-30T10:35:00.008Z

While Game Maker allows very simple access to sprites and drawing images, it has a side effect of bloating texture usage. From a users point of view it's done absolutely right. That is, it's very simple to use and understand. Now... enter the PSP with it's limited memory, and all of a sudden, these bloated images are an issue as there's large textures with not much in them, taking up valuable space.

So first, what do I mean by not much in them. Well, lets say a user wants to display a logo, over the top of the actual game. Now there are 2 ways of doing this; first you cut it right down to size, and use code to position it using a little trial and error, or second, you could make a full screen image, and use a painting program to position it just right. The second is far easier, so many users opt for that option, but this results in lots of empty space around the image. Now, even a few pixels space around a sprite adds up if you have hundreds of sprites, so what I've been doing in the past few days is a little smarts in our texture page packer. This looks at the image, gets rid of the surrounding space as best it can, then gets the runner to reposition the image automatically, so it's just like the original. This can seriously reduce the memory footprint of game.

So if we take an example game and apply this and a few other tricks, we can reduce the number of textures required down hugely, in this case from 28 512x512 textures to only 17 512x512s. That's a saving of almost 3Mb (DXT5) - that's a pretty meaty chunk for a platform with only 24Mb free.

Lastly, why do we pack images onto texture pages in the first place? Well, some systems (like the PSP) only want power of 2 textures, that is a texture can only be a width/height of 2,4,8,16,32,64,128,256 or 512. (512 is the maximum size on the PSP). so we can either pack them into a page, or we'd have to scale them so they were a POW2, and that makes the image look a little funny. It also helps cut down on texture swapping, and speeds up the graphics a little.

All this helps in reducing the memory footprint, and speeds up loading. When we first got something running on the PSP, the initial loading of SkyDiver took 40 seconds, which was obviously unusable. Now however, the new way we have to loading data into the game means we can now load SkyDiver in around 6 seconds, which is much better, and the smaller the file, the quicker it'll load.

All these optimisations will one day make it's way into the main Game Maker runner, which will give all users these benefits, no matter if it's on windows, mac or some new mythical platform.

GameMaker DSi...

2010-04-28T10:02:00.005Z

I've read quite a folk folk question PSP over DSi for Game Maker, but to me the choice was very simple. Sandy has mentioned before that given some time and money, DSi would be very interesting; and nothing is impossible. However... DSi (and I'm ignoring the DS completely due to its severely limited memory, and very slow CPU speed which effectively makes it a no go) has some very tricky issues.

1) The DSi has only 16Mb or RAM. This isn't terrible, but would limit the types of games you could port/make for it. The runner itself requires some ram for both the program and it's internal variables, so you'd probably be left with around 12Mb. I've no idea what the OS takes up, so that would be another factor. Call it 10Mb. Possible, but not great.

2) CPU speed. While the DSi has 2 CPUs, they are only 133Mhz each, and that's really slow. You could certainly do some multi-cpu code, but lots of it depends on serialised operations, so for the most part, your stuck with 1. This again limits the number/style of games - but not impossible.

3) FPU. The DSi has no floating point - at all. This is a massive problem. As anyone that's used game maker will know, it's totally based on floating point values. Every script "number" you use is not only a floating point number, but a "double" (a very LARGE floating point number). Part of the work we've been doing is to limit the double access, but they're still there - and have to be. This means all the floating point code would have to change into fixed point. This would take some time... but is possible. Obviously, you couldn't use FPU emulation as on a 133Mhz CPU, you'd burn all your time just doing FPU stuff.

Now, longer term we have been thinking about adding more "types" (i.e. a RAW integer type) which would allow developers to speed up their scripts, but there's huge changes internally to allow this to happen, so that won't be around for a long time. Russell has been doing some very cool updates the the script processor for the Game Maker Runner, and that's opening up a whole new bag of tricks, but I'll leave him to talk more about that; some of the updates we're looking to add will make you drool in anticipation.

So... while a DSi port is possible, there's a huge amount of work required before we can realistically consider it. Of course, if Nintendo announce a NEW console at E3 this year... that's a whole new ballgame!

And a quick note about the new Apple T&Cs... The rule says you have to build a game with C++ or ObjectiveC. The runner IS in C++, and interpretes scripts. This is fine as there at LOTS of apps which use scripting in some form or other, not to mention quite a few emulators (which is ALL scripting). So we don't anticipate any problems, although Sandy will be speaking with Apple to verify.

Lastly... this is my personal blog. So if you post a comment, be constructive and don't be rude. I have no problems in deleting what "I" consider offensive comments. I don't mind people saying they disagree, or even giving me valid reasons in their mind as to why I'm stupid, but if you post single line comments of "it's crap", or "you're an idiot", then it'll nuke it from orbit. Thank you, come again!

YoYo Games Ltd...

2010-04-26T13:50:00.006Z

Well, a little later than advertised.. but here we go. After leaving Realtime Words at the end of February, I can now announce that I'm now working full time as Head of Development for YoYo Games Ltd. YoYo have an amazing product called Game Maker which, to put it simply, allows you to make games without being a hard core programmer; or in fact a programmer at all. This is really neat. Russell Kay (who you may remember is doing the ZX Spectrum port of XeO3) and I have been working for some time to port the runner part of Game Maker onto the PSP, so that we can put some of the amazing games into the Playstation Network, as well as other console or mobile targets. In fact you can see a work in progress shown here..

This is a month or so old now, and we've made some real progress in speeding it all up, so Sky Diver hardly ever slows down now, which is great.

I've been having great fun doing this and hope to blog some more as time goes on about the problems, and internals of Game Maker, and what we hope to do in the future - so exciting times ahead! I'm also really excited to be part of the massive development scene at YoYoGame.com and hope we can deliver some really cool updates for them to play with.

I had to laugh... I've already been caught out by saying the PSP was uncool, so I thought I should at least attempt to clarify! :)

The cool wall isn't about what's good, or even what's popular, but what's perceived as being cool. Now, the PSP from a techie point of view, is very cool. Great colour screen, MIPS cpu (which I love), and good graphics through-put. But from a cool point of view.. well, the UMD isn't nice, it drains power too much and that kills it. When it first came out I was very excited about it, I loved the idea of playing movies on that very cool screen. But the battery let it down with the UMD drive, and the movies were too expensive; particularly for ones I already owned! One thing that really excites me with YoYo and Sony's NEW mini games, is this removes the UMD from the equation. Your battery life goes up, and the newer slimline PSP's are actually quite nice and pretty light.
The PSP Go is definitely heading in the right direction, but pricing is a little silly. If they can get the price down, the PSP Go could be a real winner; but cool? We'll have to wait and see!

Of course on top of this, you also have the minis being playable on the PS3, which is really cool. This means we should be able to get Game Maker games onto the PS3 as well, although perhaps one day... a real PS3 Game Maker HD might even be on the cards... only time will tell - now how cool would that be?

Hash

2010-04-24T13:50:00.008Z

I've been working to speed up some code and the original was a straight list which made finding entries slow, so it makes sense to try and speed this up with a better set-up. Now you can either use something like a binary tree or use a hash to look it up. Binary tree's are good, but can get unbalanced easily if it's a dynamic list, so I've opted for a simple hashing table. Now this is a VERY simple hashing table, but still far outstrips a straight array.

Each object I have uses a 32 bit INT as an ID, so I can use that as the HASH access. The simplest way of hashing this is to use the lower "X" bits as an access to multiple lists meaning we simply have far less to look through to find our object.

So, imagine an array of 512 linked lists, with each list being accessed with the lower 9 bits of the object ID. Pretty simple, and simple means quick. It's also worth noting I could use 512 binary tree's if need be, but I simply don't need that. And that's it, it's as simple as that.

Now I'm not a fan of templates, I think they are used far to often for really simple things, and then you end up with templates inside templates which means people simply don't know (or understand) what's going on inside the compiler generated code. STL suffers a lot from this, it's so old now, and has been updated so much, it's now crippling. Still, templates have their place and this is an ideal situation where a template will do some real good. So, I've dusted off my template head and written a very simple Hash template - which I'm now going to let you all have a play with.

The first thing to decide when writing a general API like this, is figuring out exactly how you want it to look, and what is the best use case. I normally do this by writing some sample code which will use the API in very pretty manner, then write the actual code around the desired API. So here's the API I've gone for; or rather some sample code showing it's use.


 TestObj* pObj;

 // Make the HASH table with 512 linked lists (must be POW2)
 Hash* HashTable = new Hash(512);
 
 // Add some dummy objects
 HashTable->Add( 0, new TestObj(0) );
 HashTable->Add( 14, new TestObj(14) );
 HashTable->Add( 271334, new TestObj(271334) );
 HashTable->Add( 512, new TestObj(512) );
 HashTable->Add( 512*10, new TestObj(512*10) );


 // Itterate over the WHOLE list
 Hash::iterator Iterator = HashTable->GetIterator();
 while( *Iterator != NULL )
 {
  pObj = *Iterator;
  Iterator.Next();           // Doing this here means we can delete the pObj from the list if we wish
  
  // Do code here....
 }


 // General functions...
 pObj = HashTable->Find( 512*10 );
 HashTable->Delete( 0 );    // Delete HASH index + object
 HashTable->Delete( 512*10 );   // Delete HASH index + object
 HashTable->Remove( 271334 );   // REMOVE from hash table, but DON'T delete the object!

And that's all there is too it. Very simple simple, but works. This operates very much like a C# Dictionary<> so is pretty nice to use. If you find that it's getting slow due to a high number of objects, you can either increase the base array size, or you could change the internal storage from a linked list, into a binary tree or something.

Anyway, you can get the template here: Hash.h

Hope it's of use to someone - Enjoy!

Quiz...

2010-04-09T09:21:00.006Z

Okay, so perhaps I should have been a little clearer, but the general rule of question one sticks through out. So here we got...

1) Memory Access. This is it pretty much it, especially on today's hardware but does have a similar effect (if not as profound) on older machines as well. If someone is reading/writing gigs of data every frame, it's gonna suck, not just because they have a huge loop in there, but because in modern computing (and we'll stick with this just now), memory is the number 1 enemy.

In the past, CPU access was around the same speed as memory, so it would be a little slower to read from memory - usually just a few cycles. These days, memory is incredibility slow compared to the CPU. Register operations will (in real terms) take less than a cycle, while un-cached memory access can take thousands of cycles (once you remember page faults and the rest).

This is crazy, so the less memory you can touch the better. Now... this may include reducing passes over data and doing it in one pass (while doing a little more register based work), or simply removing data access and tables if you can do it in a simple calculation. In the past, we used to have multiply and divide tables, but these days this table can be so expensive, you're far better just doing the ASM instruction which only takes a few cycles.

So, heres a real world example - particles. If your doing particles on the main CPU (we'll ignore the GPU for now), then the smaller you can make your particle structure the more you'll be able to render; not because you can draw more, but simply because the CPU only has a limited memory bandwidth and reducing that means you can do more, or better yet, do other things - like gameplay.

I've seen it over and over again. People continually looping over large amounts of data, wondering why things are slow when it's not that much data they're processing. Remember in this day of the multitasking OS, a 1Mb cache is not yours alone. You're data will be continually kicked out by other processes, so even if you only have 64K of data, you'll be surprised how little time it spends in the cache. The answer is to prefetch the next block, and do a little more processing on the current one, thereby reducing the number of iterations you have to do. After all, if your talking 400 cycles (say) to read a cacheline (around 64bytes last time I checked), then why not use the 400 cycles doing something instead of 400 cycles waiting on memory coming into the cache?

2) This actually has nothing to do with optimisation - by bad. Its a simple 2 part question...

2.a) Release it. No game, or application is any good if you never release it. No matter how shiny, awe inspiring, or ground breaking; who cares if it never sees the light of day? So rule 1 of any program development, make sure you get something out, or it's just wasted effort.

2.b) Make it fun. In games, it's easy to release something with lots of features and levels, but if it's not fun, no ones gonna play it. It's that simple. I can name several games that appear to have been developed by idiots. Games that were all gloss and no gameplay. Some teams fixate of making things as pretty as possibly, but thats really not the most important thing. You have to enjoy being IN the game, or like 2.a it's pointless and a waste of time and effort. You'd be amazed how often this rule is ignored, or something particularly frustrating removes all the fun that SHOULD be there.

So there you go... Yeah, not the best phrased questions, but I bet looking at these you're either nodding in agreement, or shouting at the monitor something like "Rubbish! Algorithms are FAR more important!!". Well, this is true... but given even a reasonable algorithm, you can then apply the memory rule and speed it up more. The less memory you touch, the quicker your code will be, it's that simple.

oh... and no smart answers about being in a calculation loop with no memory access for a second - we're assuming you're not a moron. :)

Performance...

2010-04-03T19:50:00.006Z

Here's a little quiz for you. Both of these issues have come up in conversation over the past week or so, and I thought it would be interesting to pose them, and give you the chance to prove your smarter that most games developers...

Question 1
Whats the main thing to tackle inside a program, that's virtually guaranteed to speed it up?

Question 2
When writing a game, whats the 2 most important things to make sure you do? (In order please)

The answer to both these questions should be obvious, but lets see how you do. I'll answer them in a couple of days...

Now... if you cast your mind back a few years, you'll remember me doing a fancy little routine for XeO3's bullet allocation. This was a simple "stack allocator" that sped up my code by quite a bit. Well, you can now find this article in the new Games Programming Gems 8 book. Yes, about a year ago I got the article accepted, and it's now in print and out. This is the 1st time I've decided to try and get an article published, but I thought it was about time. It takes the general concept a little further and uses it in standard programming (rather than 6502), and comes with a few little examples.

The only reason I mention this (aside from being chuffed that I finally got something published), is that this is one of the main reasons I still code old machines. Without writing XeO3, this would never have occurred to me. Old machine place unique limits on what you can do, limits that simple don't appear to be around anymore, and as such require you to think outside the box. They are still a valuable learning tool, and can lead to better code on a day-to-day basis. I've now used the Stack Allocator in several applications I've since written, and found it much simpler/quicker to implement than linked lists, not to mention easier to follow. I love how retro coding really can teach an old dog new tricks....

DMA Design - Now part of history.... apparently.

2010-03-29T07:26:00.003Z

So a couple of years back the old museum in Dundee closed to get a well needed refurbishment, and while shut it got in touch with Realtime Worlds and asked for everything DMA that would could get our hands on. Now the museum is open again and it has a section based on local history, and a selection of the DMA stuff has been put on display. It's very odd seeing something that I've been intimately involved with appear in a museum! Particularly as (last time I checked), I'm not dead yet! But it's very cool to see DMA Design given the same kind of importance as Timex (who made the ZX Spectrum, right here in Dundee) and D.C. Thomson who...well.. own half of Dundee. There's also lots of stuff dealing with life sciences and the like, and to think that we've managed to influence Dundee's past enough to warrent a little display is very satisfying, not to mention a little cool.
The newly opened museum is pretty good, so if your in the area, you should pop in and see it

Update....

2010-03-04T16:12:00.003Z

So, it's been sometime since I've posted anything and a lot has changed - well, for me at least. I've left Realtime Worlds after some long term disagreements with how the project I was on was being handled, but I wish them all the best and hope they make a go of it. All I can say about the project is that IF they manage to pull it off, then it's gonna be huge! Good luck to all involved, I spent 5 years of my life on it, so I'm still very keen to see it work.

Still onwards and upwards I guess. I'm currently on gardening leave from RTW and have just over a week left before my official end date. It's nice to be able to kick back and relax a bit, although I have been finishing off some freelance stuff I've been doing on the side. I hope this will be announced soon so I can start blogging a little more about it, because it's really interesting in its own right. With luck, I'll have things sorted out in a couple of weeks and everything will become clear.

Because of all this, my retro projects have obviously taken a back seat, and will remain so for some time to come; and the same goes for my electronics. I'd love to get back into them but I have bills to pay like everyone else so I have to concentrate on other things. I'd love to dabble back with my electronics in particular, but it's going to be a while before I can afford to do that again.

Anyways... I hope to announce some stuff in a couple of weeks, and with any luck, you'll all be interested in that as well!

Oh! And you can follow me on Twitter if you REALLY have no life and nothing else to do... I'm on there as MDF200 (which was my old Visual Sciences login ID!

The cool wall

2010-01-21T09:17:00.029Z

Computers and Consoles
Seriously Uncool	Uncool	Cool	Sub-Zero
IBM PC Tatung Einstine Amiga CDTV New Brain Commodore16 Spectrum+ Vic 20 Oric / Atmos Philips CDi Konix 3DO TI99/4A IBM 360 C64gs TRS80 BBC Micro Amstrad GX4000 Amstrad PCW Sinclair Zx80 Altair 8800 Nintendo Virtual Boy Dragon 32/64 Philips Videopac Elan Enterprise PC 200 Sun Ultra Sun Sparc Mattell Aquarius Cambridge Z88	FM Towns Plus/4 Commodore 116 Atari 400/800/1200xl/130XE/65XE Amiga CD32 Amiga 2000 Amiga 4000 Atari 2800 Atari ST Spectrum 16k/+2/128 Commodore 128 / 128D SAM Coupé Commodore Pet Atari Jaguar Sega Saturn Nintendo Game Cube Atari Lynx Sinclair ZX81 Nuon Acorn Electron Acorn Atom Amstrad CPC MSX Archimedes XBox Sinclair QL Playstation 3 Gameboy Advance PDP 8 Dec Vax PSP NeoGeo Pocket Commodore 64sx Vectrex Nintendo Nes Sega Master System	Atari 2600 Amiga 1000 Amiga 3000 Amstrad 6128 Plus Cray PC Engine Megadrive NeXT NeoGeo Mac Thinking Machine Nintendo DS Playstation XBox360 Dreamcast SGI Workstations N64 Nintendo DS	Magnavox Odyssey Pong Sinclair Spectrum 48k/+3 Commodore 64 Apple II+ Colecovision SNES Playstation2 Amiga 500 Amiga 1200 Gameboy Wii

A little while back the members of our team during a week of coffee breaks came up with the following cool wall. It was a hard fought list with many arguments about the virtue of each machine, but in the end we had our definitive list of old machines. Fans of TopGear will know all about the cool wall, and know it's nothing to do with how good anything is - just that it's cool or not. So heres our list... let battle commence!

Now remember... it's how COOL they were, not how useful, or powerful. The Plus/4 is a great little machine, but I'm not gonna pretend its cool. Also machines like the Amiga 4000 were awesome! But too expensive to be cool. So there you go - thats the rules.

PS. I don't know WHY theres a huge space above the table either...

Life changing magazines #4

2009-11-30T18:40:00.013Z

So this one is a little simpler. It's my first published work. I was 16 when I sent it off, so in the 2 years from reading the WORMS program listing, I had learnt basic Z80, gotten a spectrum, written a Database for my Mums work, was without a computer for a almost a year(spectrum went back to my mums work), and then gotten a Plus4 and learnt 6502. I find this frightning as these days, YEARS seem to slip by without anything appearingto happen!

So here is the letter I wrote, the reply I got, and the final article. I was well miffed that they didn't put my name on it however - everyone else got that! Story of my life that.... everyone's always taking credit for my work in some shape or form....

From now on, they're not that "life changing"... just important, or funny. There was one other one, but I appear to have lost that. It was a turbo loader for the Commodore Plus/4 which I used a lot, but I then adapted it to be an interrupt driven one on the C64, which then allowed me to play a game while things were loading. Aside from this one, the rest were all after I "turned pro", and so weren't important, just funny/cool/etc.

Life changing magazines #1

2009-11-29T18:17:00.009Z

I guess every programmer has a genesis moment. One where everything starts to make sense and it's the true begining of their love of programming. This was mine. I was 14 and must have had my ZX81 for about 6 months or so when I bought this magazine. I was at my grans in reading this and suddenly all those HEX numbers I'd been typing in made sense. There in front of me was a true assembler listing. I suddenly realised what all the codes at the back of the manual meant, and how you used them. I poured over this article for days, playing with it, trying new values, changing little bits to see what would happen. Up until now I'd been doing ZX81 BASIC and was getting on okay. However when I got this article I saw the routine that drew the border and called it directly.

BANG!

Unlike Basic, it popped up instantly. I was gob-smacked! It was SO quick. Basic would have taken over second to print that much! I played around with it, changing the character it drew and so on.

This showed me just what computers were capable of, and how these games I bought actually managed to do what they did. Now I could see how it all worked, I started to learn it all...

Put it simply... this is what got me hooked.

Life changing magazines #3

2009-11-26T21:15:00.006Z

So, I got this I think around 1985, second hand again. This was very cool though, it showed how to make your own turbo loader! Now I still didn't really understand it at this point, but I was able (with the aid of an amazing tape deck) to make a screen grab load at an amazing 6,000 baud! This is microdrive speed; from a NORMAL tapedeck! It just blasted in! I was also able to load data in via a slightly odd pattern so the screen would come in backwards, and even from both directions at once! Normal spectrum turbos were 3,000Baud (with the original ROM routine at 1,500), so I had great fun fiddling with these routines.

I've still to track down the No.1 magazine. I do still have it, but I've no idea where!

Life changing magazines #2

2009-11-25T13:20:00.023Z

Yes I know... I'm starting at #2, I need to track down the No.1 magazine. So this one was published when I was just 13, and it had the key equations for doing very basic 3D and perspective. I used these equations for years before real full matrices were possible, but it still holds a special place in my heart. And yes... theres a chunk missing from it. I got it 2nd hand, and someone had sent off for something ripping a big bit out of the article. Fortunately, it wasn't important as I didn't really care about the program, just the method and equations.

ZZap64!

2009-11-24T10:49:00.008Z

I've just received my original Oli Frey ZZap64 artwork! And I'm pleased as punch! It's from issue 9 of ZZap64 and it's a beauty! It's actually draw at the original size (or very close) to that of the magazine, which I'm astounded at! Normally artists will draw x2 or larger so they can get the detail in, but he hasn't! How the hell did he do that! The detail is amazing on it. I've also discovered I have that magazine, so I'll now get them framed together and it'll take pride of place in my workroom.

I can't wait to see what other ones he'll put up for sale, who would have thought all those years ago I could own an original! Very cool....

You can go buy your very own original at the ZZap superstore: CLICK HERE!

(must now stop using exclamation marks to end every sentence...!)

KISS - Keep it simple, stupid.

2009-11-23T12:07:00.004Z

I'm a big fan of simple code, probably because anything more complex confuses me and I'll never understand it. This is a hard lesson which I learnt when I was about 15 or 16. I had written a very clever platform routine in assembly on the spectrum. It would draw a Manic Miner level using likes and some king of direction control. However, it was so clever, that after I had written it, debugged it and it was fully working - I had NO idea how it worked. Not a clue. Now, I'll cut myself a little slack here... I was only 15 or so, and had hadn't been doing assembler that long really. Still, I had written it, so I should have understood it! Since then, I've followed the KISS philosophy. Keep it Simple, Stupid. Although the original was apparently Keep it simple and stupid, I prefer the newer interpretation, as you really don't have to be clever to be an engineer these days (particularly a software engineer), and we love to complicate things; so I prefer the insult. If you haven't kept it simple, then you're stupid.

I see this everyday at work, coders who think the latest shiny blog posting about some cool new method is the absolute BEST way to code, and anyone that doesn't is mad! MAD I TELL YA! Well, thats obviously rubbish. If you follow every posting by some new publicity hound, then you're codes going to be terrible, plain and simple. The only real rules for coding is that its got to be clean, readable, fast (enough), maintainable and extendable.

Outside of these simple guidelines, nothing else matters, and it's simple a personal choice. You can throw other things into this mix, like testable, abstracted etc. but these can cloud the code to the extent that its none of the things it should be. I've see code thats been abstracted so much, it's beither readable, fast, maintainable OR extendable. A little abstraction is a good thing, but only when you need it. If you're writing a bit of code for windows, and it's never gonna be moved onto any other platform, then why abstract windows calls? If your going to add value to them (but having them do more, or make the API easier), then thats fine. But never add layers for the sake of them. You should never end up with an API that just passes things through directly unless theres a damn good reason (moving platform it a good reason, as you're wanting to hide the underlying OS calls).

However, desire for coders (especially a novice/junior) to complicate things is pretty high, as is the desire to make a perfect API. Take it from me, thats an impossible dream. You might think it's great, but others will always want something different. The idea is to make an API as good as you can right now, and adapt as time goes on. In the world of professional development, it's all about getting products out the door, not going back over API's trying to make them absolutely perfect. They have to perform the job, and do so with an API that was as good as you could make at the time, otherwise, you'll simply never finish and go bust.

In the end, there's 2 types of coders.... Those that want to get things done and out the door (and this doesn't automatically mean bad code!), and those that want to polish things and write docs, and make things pretty, but ultimately cost you dearly.

Oh...and if you've never seen the second kind, then your one of them!

Designing a good API

2009-10-04T20:07:00.003Z

So I've been doing some work porting some code to another platform (which I'll speak about later), and it's showing a severe lack of API design. Now I design APIs for a living I thought I'd quickly go over what I think makes a good API, not just from a users point ov view, but internally as well.

Simple and Fast. And we're done. Thanks for reading.

Okay... I'll go into a litte more detail. Now, API's are usually there to give a coder simple access to a more complex system. Take DirectX. The underlying hardware and systems are pretty complex these days, what with interrups, DMA chains dynamic memory management and all the rest of it, yet the API is (reasonably) simple. So... here goes.

Simple. An API must be simple, in fact as simple as you can get away with. This isn't to say you should make it basic, no. You should make it do everything a coder will normally have to do, but don't over complicate it by using 1,000,000 calls for each function. Take DirectX texture creation... Now, whenever I do a graphics engine I have a single CreateTexture() function where as DirectX has several. Textures, Surfaces, DepthBuffers and Cube Maps, the list goes on. Now why? Theres really no reason for that kind of split. You could just as easily use flags and paramaters to allow the various types of selection. This means the coder only has a single function to learn, and if you follow this kind of rule for the whole API, then the entire system becomes much smaller. After all, would you rather a 1,000 call API where you have to set the width and height of a texture indavidually, or 10 functions that can do everything! The smaller the API, the more control you can keep over it. If you give access to every single function and variable, then it becomes a nightmare to change or upgrade.

So, keep an API simple. It's less to maintain, and the programmers that use it will thank you for it.

Speed. This is obvious. It has to be fast. If your management code gets in the way, then the API will become too expensive for coders to use properly, and they'll end up writing support functions themselves. This is really bad. You want the programer to have confidence in the API, not only that it'll do what you say it'll do, but that it won't slow him down. Streamline as much as possible, remove as many if's and but's as you can inside performance critical areas.

Now, a quick word about abstraction. It's important to abstract certain types of API so that it's clean and portable. Now theres a few of reasons for that. First you expect the API to change under you. If your using some open source interface, you never know when the latest buzz word is gonna take hold and your whole API is gonna change, so a simple layer of abstraction will protect you. Next, it will allow you to add value to an underlying API. Take DirectX texture management, if you add a simple layer to your API, you could then now keep track of all your textures, and it'll allow your to manage things like device resets (when you resize the window etc.) as since you own all the texture pointers you can free/reallocate things like render targets automatically. Lastly... Portability. Now most hobby projects don't care about this, but you never know when your project might take off and someone else might want to port it for you to a Mac, or a ZX81...or something.

The program I'm currently working on was hard coded for windows, using not only MFC, but DirectX calls and enums directly. So, being someone that designs APIs, I know all about abstraction. Being someone who's worked on lots of multi-platform games, I know all about how to make an API platform independent. So, thats what I'm doing. All calls to DirectX and being put through a layer of abstraction, each ENUM is being changed to be platform agnostic. This means the API can translate (very quickly) to whatever rendering API I want, without the main application knowing, or caring. The classic case is DirectX and OpenGL. Doing this would allow this program to run on the Mac, without the main program changing. I'd only have to port the (now pretty small) API, and not the whole program.

If you've done your job correctly, you'll have to port a handful of API's. Sound, Graphics, Networking and simples file systems and memory management. All games can be based on these simple API's, and then be made to run on other platforms (reasonably) easily.

Theres obviously lots of ideas for each API. Designing graphics APIs is an art in itself. I've used the same API for the last 10 years. The underlying graphics systems have been PS2, XBox 1, DirectX 8&9 and I know it would work just as well on a PS1, XBox360 (never seen a Ps3 SDK), and DX10/11. A well designed API will work on any platform and be a pleasure to use.

So there you go... Keep an API simple - don't get sucked into the latest fad. Keep if as fast as you possibly can. And abstract to reasonably protect yourself from underlying systems and to allow simple porting.

The good, the bad, the ugly.

2009-08-17T18:32:00.006Z

I've currently been looking at another code base at work and it's brought to light something I've known for a while, but which is now front and center. Not all programmers are good programmers. It's something which is pretty obvious, but what isn't obvious is the split. You would like to think that it's a pretty linear grade with even numbers of coders at each level, but in fact it's pretty biased towards the lower end and the numbers drop off quickly the higher you go.

Now the games industry is pretty hard to get into in the first place, so truly bad coders in our industry are exceptionally rare. Thats not to say we don't get them (and I think we have a couple in our company to be sure!), but most of our problems are due to the lack of training. We have a heap of juniors on our project and they just haven't been mentored correctly. Now for the most part they're all pretty good (or they wouldn't be there), but without proper mentoring they'll just do it their own way, and not the way they should. Training, and experience is everything, and while it's far easier to churn out decent looking games due to the sheer power of modern hardware, thats not to say that the underlying code couldn't, no shouldn't be far better.

This is much more important than you'd think. In the past you'd write a game and as soon as your finished, you'd hardly ever look at the code base again. That just doesn't happen these days. For starters, engines and tool sets take time to write, so you have to look after them and use them as often as possible. Second, sequals are very common and the turn around on them is usaully very tight, so having a solid codebase to start from is important which means you can't just fudge your game and forget about it. Companies are made on their I.P. and your codebase is a vital part. This means you have to not only value your staff, but make sure you train them as best you can, and I think the games industry as a whole fails in this.

Time marches on...

2009-08-07T09:14:00.007Z

Wow... what can I say... WOW! As of the 1st of August I've been in the games industry for 20 years. 20 YEARS!! Who would have thought it. My mum said it was a waste of time and I would never amount to anything (okay, she was still right but..), and back then it was such a bedroom industry that you almost knew everyone that ever coded a game. These days, I've never heard of any of them!

*sigh* happy days. We has some great times at DMA, the early days being by far the best - it was just so much fun back then! Thats not to say some of the later days weren't good too, but hardware is just so boring these days - powerful, but boring. Just about anyone and his dog can make a reasonable game now, and that takes away much of the art that you needed to do really cool things.

I did a little test at work recently and was able to draw 1,000,000 lemmings faster than we could draw 100 on the Amiga. 1,000,000!!! That covers a 1280x1024 screen 195 times over!! or to put it another way, imagine a SNES with 3,900 parallax playfields, and STILL have enough grunt to draw 1,600 sprites! Amazing power. But what do we do with it? CPU's are now so powerful, it's like having over 500 SNES per CPU - and I have 4 cores on my machine!

So much has changed, and a little of the fun has gone. Now and then you get some of it back, a little bit of fun optimisation still brings a tear to eye as you remember the fun you used to have pouring over a few lines of assembler while trying to get a single cycle off. I sit and watch all these new boys, and shudder at the waste in their coding, memory, cpu power, disk space, network bandwidth... all of it. They don't seem to spend as much time thinking about these things as we old timers do, and the sad thing is, they probably don't have to. Sure a little more care would work wonders, but CPU's are actually made to help average coders. Thats a sad fact of life, the world is full of average or less than average coders, so all the clever folk at Intel, AMD, ARM all work away to make things run faster for them. but this leaves the few of us left struggling to find the fun we lost.

Still, it's not all bad. Some new hardware is always around the corner, and your mobile phone is now more powerful than even the old consoles. Look at the iPhone. Really nice bit of kit, and fun to code for. Languages have changed too, and I've (almost) given up assembler for the likes of C# as it's just faster to work in. I've had some hard leassons to learn here though, giving up memory management is still a sore point but it does make life simpler for most tasks, but I really miss knowing where every byte of my program has gone.

It's sad I guess. I'm a man stuck in the past. On the one hand, I'm trying to hold on to the fun I had in the very first days of coding, while on the other, I try to use all this new power as best I can, and teach these new boys thing or two while I'm at it. It's now all about bridging my experiance, learning from the past to bring forward old ideas and use them in new contexts.

So will I be here in another 20 years? Who knows... I suspect I'll still be coding in some shape or form. It still has the same lure as it did when I first sat down in front of a ZX81 and black and white portable TV as a 13 year all those moons ago. But what will change in the next 20 years? or even the next 10? More CPU cores I guess, bigger badder machines, easier to program and just perhaps, a little more fun.

Lets hope...

Anyway, heres some of my career highlights I've enjoyed...

1989 - Ballistix is released - My first game!
1990 - Blood Money on the C64 is released.
1991 - Lemmings
1994 - Lemmings 2 SNES
1994 - Uniracers
1995 - Writing various prototypes and trying out several game ideas.
1996 - Minus4, my first emulator!
1997 - GTA, particually the 3Dfx version.
1999 - GTA 2
1999 - I left DMA and moved to Visual Sciences at Head of Reasearch and Development.
1999 - XeO3, a small on going project begins...(still not finished!)
2000 - Internal debugger for the PS1 based on an Action replay, along with some fun on the PS2.
2000 - F1 2000 on the PS1
2001 - F1 2001 on the XBOX
2001 - I left Visual Sciences and moved to Simian Industries as Technical Manager.
2005 - Moved to Realtime Worlds after Simian went poop to prototype some ideas.
2005 - Various tech demos for an undisclosed project.
2006 - Russ joined me at RTW and my project team doubled in size.
2006 - Actually started to use C# in anger.
2006 - Huge scale tech demo. Great fun.
2008 - Rewrite and an even bigger scale demo - pretty cool.

Delphi conversion

2009-07-18T09:58:00.005Z

So, I'm doing a little Delphi conversion just now and while looking through the code I came over a little bit which didn't quite make sense. Rounding floating point numbers into integers. Now my default has always been to truncate for rounding. Not only is it faster (by far!) but it's easy to predict, and everyone understands it. Now, Delphi's rounding...wow... it's nuts!

Dephi seem to have gone out of their way to complicate things, and I can't figure out why. Anyway, after doing a quick search heres the Delphi rules...

The Round function rounds a floating point Number to an Integer value.
The rounding uses Bankers rules, where an exact half value causes a rounding to an even number:

12.4 rounds to 12
12.5 rounds to 12 // Round down to even
12.6 rounds to 13

13.4 rounds to 13
13.5 rounds to 14 // Round up to even
13.6 rounds to 14

Now...why o WHY would you do that.... Round .5 to EVEN! What! Nuts I tellz ya...

Editor woes

2009-06-27T20:26:00.003Z

You know its amazing how fast you can do an editor if your not trying to be fancy. Take RetroEdit. It's actually trying too hard to be the jack of all trades, and as a result, its currently the jack of none. This isn't to say it won't eventually work and do its job, but currently because its trying to hard, its progressing slowly.

Now, take a look at a little map editor I'm currently knocking up for my little iPhone Golf game. I'm not trying to make it a generic editor, and I dont want to reuse it later (not that I couldn't hack it into something else later mind). But this means Im free to throw code in at a great rate of knots and as a result, within a day (almost) I've just about finished the basic editor. It's got a tile window, brush support (grabing multiple tiles at once), and I'll add a quick UNDO function in there for when Im being stupid.

It's amazing how quick you can do these things when your being specific, and I do wonder sometimes if the tools I try and do at home are being too ambitious and as a result might never get finished... hay-ho...

iPhone fun...

2009-06-26T18:34:00.002Z

Yeah, I know... long time again. I've started doing some iPhone coding to see if I can actually finish a (proper) game at home. Doing games programming at work, then games programming at home is hard going. Doing the same thing all day, then coming back home and doing it all again is a little soul destroying. However, I'd like to try and give it another go, and who knows.... perhaps make a little cash on the side.

So, XeO3 will (yet again) take a back seat for a while so I can see if I can make a real go of this stuff.

On the plus side, I've been doing some OpenGL at work, and it's putting me in good stead for doing some at home! I now know a reasonable amount about it so should be able to use the iPhone's OpenGL ES reasonably easily..

Well, here goes nothing....

Reporting In...

2009-05-24T20:54:00.002Z

Nothing much to report. I've just had a nice relaxing birthday weekend and done nothing but cut the grass and watch the Monaco GP. Great fun. However, I have gotten my subversion server up and running again, so that at least should be backup for everyone using it.

No idea when I'll get back to doing stuff, just not in the mood just now - not to mention still installing stuff for windows 7.

Still, had a great weekend so what the hell :)

Subversion

2009-05-11T19:31:00.002Z

I've now reinstalled sub-version. As I'd hoped, it was pretty painless since I already had all the config files setup and simply had to point at them. Windows 7 is pretty nice and I'm trying really hard to keep features like the user account control, but I'd also love to be able to switch it off for specific programs - like the command prompt (when run as administrator). Still, I'll keep plodding on and see if I can get used to it.

I'll need to test the remote access tomorrow, but since the firewall hasn't changed, it should all be fine; fingers crossed!

I've only a couple more programs to install and I should be back to normal. I have lost my 3rd monitor as it the display seemed to be locking up a lot, but since I've just installed some new drivers, I'll try switching it back on and seeing if its all working again. I like having 3 monitors, it'd be a shame to lose it.

Russell reminded me that I actually have a proper MAC that I could be testing with MONO (my dual core G5), and although I'll need to get more RAM it would be a good testing ground for retro edit (which Russ tells me runs pretty slowly on it) and mu debugger - once I get TCP/IP support in. I could probably knock up a GL version of Minus 4, this should be easy as Russ has ported my speccy emulator over I suspect I could pinch the source to that and get Minus4 working pretty quickly. This would then let me use the OgreDebug and the TCP link to the emultor.. I think.

Windows 7!

2009-05-08T07:20:00.002Z

I've just installed the windows 7 release candidate and it's all very nice. It has some issues with my 2nd graphics card (I use a small PCI card so I get a 3rd monitor), but aside from that many of the annoying vista-isms are now gone.
However... Because it's a clean install I now need to reinstall everything, including the sub-version server but I hope that since I'm just pointing at a depo it won't take too long this time. If I get a chance tonight I'll try and finish installing everything, then I can (I hope) plod on with more interesting things.

InpOut32.dll

2009-04-22T19:05:00.004Z

Yes!!! Not only have I got it working again, but they have managed to get SIGNED drivers! This means I no longer have to boot up pressing F8 and booting into unsafe driver mode. This is awesome! It also means I can carry on with my debugger and try to get it to a point that I can add the TCP/IP (or UDP) mode.

For those that are interested, full signed drivers (for my upload program for example) can be found HERE

I'm very happy!

Source control...

2009-04-15T19:41:00.003Z

I've finally (FINALLY!) gotten my subversion server up and running and even managed to open up access to other members of the team. This means Russell can now help out on the editor and debugger (if he gets bored), and once Luca gets used to it, he could actually build levels directly into the source without me having to make special versions for him.

I'm currently adding all my relivent projects into the depo and assigning various access rights but it all appears to be going well. Russell has been busy moving house so we're hoping that he'll actually start doing things again soon! (*gasp*)
(perhaps he'll even update his blog!)

I've been trying to get my debugger up and running againas it's quite close to a first version (I think), but there seems to be an issue with downloading to my plus4 - no idea why. I just hope my parallel port isn't fried again! I weas toying with doing an RR-Net for the plus4, and if my parallel port is dead, I may have no choice. I guess I could always do a C64 version in the meantime, and I still have the emulator plug-in to write as well.

I really need to get back up and running as I'm currently not getting anything done at home just now. Fingers crossed this will change soon!

New video...

2009-04-14T19:44:00.007Z

I've uploaded a small video showing the current state of the C64 version. I suddenly realised I'd been sitting on it for ages and no one had really seen it.

You'll notice its not quite right, as background stuff isn't animating, and bullets aren't quite right. Still, it looks pretty, and the multiplexor holds up pretty well too!

To API or not to API... THAT is the question....

2009-03-20T08:14:00.002Z

I was reading an old post on a form from Tim Sweeney about how all graphics cards will go the way of the dodo, and how no one will be able to write an engine and they'll all have to buy his. He was claiming (back in 2007) that the GPU will become extict abd we'll just be left with massively parallel CPU's that do everything, and that API's like DirectX or OpenGL won't be needed because everyone will simply code their own engine.....

wow.... while a pile of crap. While things are heading towards being able to do more and more with a GPU - or many CPU's like intel's larrabee, the API won't ever become extinct and theres a damn fine reason for that. Developers simply dont have the time to make the huge number of features that directX (or openGL) already has. Who really wants to write full perspective correct, tri-linear, multi-texture stage texture mappers? Not to mention that it'll probably only work on a single platform and you'll have to do it all again. Nope, its total rubbish. Whith will probably happen, is that DX/OGL will continue to deal with new graphics cards and tech and allow game developers to carry on writing games without having to worry about all the low level crap, while a (very) few middleware folk decide to implement their own custom code. It may well even be that normal developers use DX23 for most of the normal stuff, but then implement a really cool voxel rendering system to do some special features.

This makes sense, of course it does. DirectX/OpenGL aren't just about drawing triangle, they're about taking some of the development cost away from developers and allowing their code to run on almost any hardware without any real code change. For those that remember the good-old-days where you had to write versions for every card out there, you'll shudder at the thought that it'll return. I did my fair share of software/DirectX/Glide/PowerVR/S3 ports and it was horrible. True I prefered Glide as it was about 3 times the speed of DirectX, but graphics cards are fast today, and it doesn't take a coding god to make a pretty looking game. In fact most games these days are written by what I'd call normal programmers. Folk that don't really know what the hardwares doing, but its going fast enough so why should I care - that time. And thats fine, it means the games industry grows, you can let normal coders in, its easier to find people and the world is a happier place.

I also find it ammusing that Tim seems to thing API's like DX will go away. The only platform in the world without an API are old systems like the SNES/Megadrive etc. (and older). Everything else you have an underlying OS with...wait for it... an API!!

Theres always gonna be an API, and interfaces like DX and open GL will simply evolve to meet the demands of the programmer - whatever that is. It'll implement common features so we don't have to, and only if your really interested (and think you can do better) will you have to write you own VERY low level bit of code.

I can't wait for larrabee, not from a graphics point of view, but for the ability to run normal code on it. I really don't want to have to write another 100 triangle rasterisers for a single game because I can make each a cycle per pixel faster.... machines are fast enough to not worry too much about that, and if the Wii has proved anything, its pretty graphics isn't what makes a great game - Mr Sweeney should really buy one have have a look.

DO.EXE V1.2

2009-03-19T08:20:00.002Z

okay.... VERY quick update. I've quickly added C/C++ hex support. So now you can specify HEX numbers as 0x186abb etc. I meant to do this ages ago but never got round to it, and since the solution file was still open this morning, I've quickly added it. Find it in the same place as before....

http://www.javalemmings.com/blog/do.zip

DO.EXE V1.1

2009-03-18T21:29:00.004Z

I've fixed a minor bug in my DO.EXE program. It wasn't recognising lower case "c", only the uppercase one. This made entering HEX very annoying. If you use it, get the new one here. Its in C# (.NET) so is cross-platform ready using mono.

http://www.javalemmings.com/blog/do.zip

C# JIT

2009-03-18T20:36:00.005Z

I was speaking the other day about the C# JIT and how it sucks sometimes... well, heres some real code to prove the point...

            m_ArrayAccess[0].m_Pos.Y = 2.0f;
00000022  lea         edx,[ecx+8] 
00000025  cmp         byte ptr [edx],al 
00000027  mov         dword ptr [edx+4],40000000h 
            m_ArrayAccess[0].m_Pos.Z = 3.0f;
0000002e  lea         edx,[ecx+8] 
00000031  cmp         ecx,dword ptr [edx] 
00000033  cmp         byte ptr [edx],al 
00000035  mov         dword ptr [edx+8],40400000h 
            m_ArrayAccess[0].m_Pos.W = 4.25f;
0000003c  lea         edx,[ecx+8] 
0000003f  cmp         ecx,dword ptr [edx] 
00000041  cmp         byte ptr [edx],al 
00000043  mov         dword ptr [edx+0Ch],40880000h

As you can see it not only continually reloads the base address of the array+type, but appears to insert pointless CMP instructions all over the place. The only reason I can figure for this is to attempt to prefetch the destination; however since its about to access it on the next instruction, this is pointless - Not only that but since its sequential chances are its in the cache alrady! And even is by some mirricle that it DID matter, why the hell is it doing it TWICE!!!

Man I find that annoying....

More C# woes....

2009-03-17T22:13:00.004Z

The more I look into C# the more I wonder how it manages to run as fast as it does. Even the simplest things it appears to double up on code, put in random meaningless opcodes etc. For example a simpel series of load/store operators like below resolves itself into a reasonable ugly mess of asm...

   Vector.X = InVec.X;
   Vector.Y = InVec.Y;
   Vector.Z = InVec.Z;

The problem is that it simply can't track registers properly and that means it has to continually reload the base address of the object which ends up making the code twice the size.

It also insists on loading then storing floats even though its just transfering bits. You can obviously just use integer registers to transfer data and this could pipline much better than series of FPU load/stores. It's frustrating as if this was C++ I could just drop to ASM and do it myself, but in managed code your at the mercy of the JIT.

Now the JIT gets better each itteration but it doesn't appear to get better where it counts sometimes. For normal code, this simply doesn't matter, you lose around 5-10% speed max. But for code that needs to be highly optimal, this can be a real issue.

C# and Ants

2009-03-15T14:52:00.004Z

Since it's been a little while I thought I'd tell you what I've been up to lately at home and work. I've been playing with ANT4.0 which is a profiling tool for C# (and .NET in general). The last one was pretty good but had some issues, while the new one is excellent. Profilers can always get better but the leap from the last version is pretty huge. For a start profiling is almost realtime which is very impressive, normally apps crawl when they're being profiled. You can also play with results while the application is running, which is damn impressive!

I bought ANTS3.0 last year and its pretty expensive but I thought that since I do lots of C# at home I would get the use out of it... trouble is, the stuff I do at home simply doesn't need profiled! Not that V4.0 is here I dont really want to spend huge sums of cash on it again, bnut its such a nice app I'm a little torn... Oh well.

Anyway, I've been profiling some of my work and doing some optimisation at home. It's actually been years since I've done any serious optimising and I'm having a bit of fun with it. C# is pretty cool in that you can do real managed code, or unsafe C++ style code if you really want to. When you're optimising you tend to fall back to unmanaged code as its still quicker.

We've also been getting some little shocks at work as some of the C# collections just aren't as quick or optimal as we were expecting, this has meant we've been starting to write our own set just to make sure its doing what we think it should be doing. Games programmers are funny like that, we hate slow code and will happily sacrifce readability for speed (within reason of course). Anyhooo.. I'm having a blast playing with peep-hole optimising, although its hard to say how this will affect the app overall just now, but I'm pretty happy with the main loop now as its very tight.

It reminds me that optimising is great fun, and thats why I got into games in the first place!!

SubVersion.

2009-02-09T08:23:00.003Z

I've been trying to set this up again, but this time using Apache (since I have that installed anyway!). I've almost got it going, but for some reason apache can't see the repository. Its there, and the DOS commands can access it, but apache can't - must be something simple. Anyway, the reason behind this is because Russ has set it up on his machine and we reckon we can get it to share repositories so that I have a full copy of the history etc. Anyways, once I have it running Russ can start to help with the editor and the debugger and add features for the spectrum as he needs to. Once its running that is....

I've also finally gotten C# to give me the cursor keys! It's a bit of a hack to do it, but I finally managed to get a key up/down for them. This means I should be able to do cursor key movement in RetroEdit so you don't have to use the mouse. I didn't think this was important until I tried to use it on my laptop which only has those stupid PADs, it then became obvious that cursor key movement would be great! So I've spent a couple of hours trying to get C# to actually deliver cursor key inputs, and man was it yucky.... Still all done now, so I can now do the work to move around with them tonight.

Edit: Test....

Tick tock....

2009-02-07T18:57:00.002Z

Been a little bit since I did an update, so here goes. I've been busy playing games (of all things) so haven't done as much as I should have, but I am still making slow progress on RetroEdit. I picked an older game called The Witchers, a very pretty RPG. Now I'm not a huge RPG fan, but I do love games like Diablo which have small amounts of RPG goodness in them, and this is in a similar vain, so I've been having great fun with it. Theres a little too much running around, but it's pretty good fun all the same.

Anyway... I've added inserting, deleting and cloning of frames which means we are almost at a usable state, but before I get to use it I still need to add colour picking and project loading and saving. I've decided to use the good old IFF to store all my data as it means I can add new features without losing too much data if I ever need to upgrade. So I'm writing (another) IFF file processor that lets me load/save IFF files easily, and putting it in the RetroBitmap control which allows others access to it if they like.

Once I have these 4 things added (and it all going well it shouldn't take too long), I'll try and get Luca to test it - although he's been in hiding reciently, but if he resurfaces he can take it for a spin and we can get on with some real features instead of the core editing stuff.

I did start looking at Onion Skining, and its a little more complex than I wanted as the retro bitmap control would need multiple sets of data to render it itself. This means I need to add a fairly large command that can render any format the control can and then return the image for Onion Skining. It's a little bit of a fudge, but oh well...

RetroEdit small steps.

2009-01-28T21:51:00.004Z

I've had a little bit of a problem with a virus I think, but have managed to revert things by rolling back a few days. This however has screwed with my source files - even though it said it wouldn't. Oh well...

I've finally managed to get the colour palette into retro edit so I'll need to do colour selection next. It's a little flickery though but I'll deal with that later, as long as it's working just now I don't really care. It's feeling a little sluggish on my machine so I may be doing something wrong, but I'll need to try it on someone elses PC first. I have the feeling its drawing WAY too often. I'm happy to say though that its finally making some headway and I hope to deposit the first version into Luca's lap soon. I'll need to get loading/saving into it first so I'll do that after colour picking/selection has been added.

You'll also notice its missing sprite sizes, I'll add this later as well - it shouldn't be too hard - although I'll need to save differently for each platform. Currently these are Plus4 (MCM/Hires) C64 (MCM/Hires) and Spectrum. I'll probably add CPC down the line - along with anyother computer/console I play with.

Small Basic.

2009-01-28T13:57:00.004Z

For those who don't know, Microsoft development labs has released a new language called Small Basic. This is aimed squarely at the beginner. Do you remember how you started to program? Well, if your an old git like me it would have been on and old 8bit machine like the zx81, spectrum, Vic20 or Commodore 64 (or some other old 8-bit thing). The reason these machines were so cool to program with is that they were just so simple. Switch on and start. Basic was built right in and anyone could start and learn it.

Well, a chap at Microsoft called Vijaye Raji has started a personal little project that one day he hopes will be included with windows - like QBasic was with DOS. This is an amazingly good idea, and one I had quite a while back as well (see here), but typically never got very far with. He however is getting on pretty well and has now released a really nice little development environment that while a little buggy, is looking very cool indeed.

Theres an interviewwith him on Microsofts channel 9 which is well worth watching. This is something I'll be keeping an eye on and might even write a little something for in the future. Its very cool.

Home again....

2009-01-25T17:28:00.003Z

After my trip down to Warrington where I was able to take a side trip to Birmingham and get to the Commodore Computer Club meet it's good to be back home. I've decided an hour and a half is about as much as Im prepared to drive for a meet, and more and its a bit of a killer. This kinda rules out any others unless I happen to be in the area (like this time), or its particually large and I'm willing to stay for a couple of days; I'm getting too old for this shit... It was nice to be able to meet folk I'd been speaking to though, and gettting some faces to go with the names is great.

It's also the first time I've used my new iPhone for mobile web, and the map applications are fab. Asking for directions, or distances from where you are is a great thing to have on you. Safari was a little slow under 3G, but it worked and help pass the time at motorway service stations. However the battery life isn't wonderful so I kept feeling like I needed to switch it off. I'll need to see if I can find the PSU for it as being able to plug it into a wall to charge would have helped - if I'd but thought that far ahead....

I hope to do a little retro edit tonight, but I'm pretty pooped after the drive up, so lets wait and see....

RetroEdit to-do list

2009-01-18T12:56:00.008Z

So, heres my current to-do list. I'll update THIS blog entry as I change things, so you can always check back here to see where I am. I'll add a link on the right for easy access.

~~Paint with colour 1 (left mouse)~~

~~Paint with colour 2 (right mouse)~~

~~+/- to change frames~~

~~rotate frame (up,down,left,right)~~

rotate line

rotate column

Colour selection

Colour Changing

~~Cursor rendering~~

Cursor key movement or cursor

~~Copy frame~~

~~Insert frame~~

~~Delete frame~~

Colour Swap

Area selection

Copy

Paste

Brush paste (like a sprite, drops out the background colour)

Mirror

Flip

Save project

Save data (native format)

Load Project

Load data (native format)

Onion skinning

undo/redo

Remember to check back here to see how I'm getting on.

RetroEdit.

2009-01-17T15:17:00.008Z

I've not been doing much past few days/weeks. With the flu over Christmas and now a cold I've not really been in the mood. However, I've decided to make an effort and have started back on RetroEdit.

I've finished the refactoring of it an am now happy with its layout and internal code construction. Basically, the old control I was writing delt with retro graphics in an abstracted way, and so you had to do some work to use it, now however the control deals directly with the raw format which means all you need to do is copy actual retro graphics data into the control and your all set.

So with this done, I've started to plow ahead with some features. Actual editing is obviously first, and I can now draw pixels with the mouse in both hires and multi colour modes. This is also true for C64 and spectrum editing. I've also put in sprite rotate left and right, and am about to do up/down.

Once I've done this I'll add colour picking. Currently I have 2 default colours and you can't change them - this obviously has to change to be of any use, and as its a biggie, I'll do that next.

I'm sure I listed these before, but it must have been ages ago so here it is again; the feature list I want in for version 1.

~~Paint with colour 1 (left mouse)~~

~~Paint with colour 2 (right mouse)~~

~~+/- to change frames~~

rotate frame (up,down,~~left~~,~~right~~)

rotate line

rotate column

Colour selection,

Colour Changing,

Copy frame

Insert frame

delete frame

Colour Swap

Copy

Paste (+background)

Brush paste (like a sprite)

Mirror (+around selection only)

Flip (+around selection only)

Save project

Save data (native format)

Load Project

Load data (native format)

If theres anything else that you think is a must have, then let me know. I've no idea how long this will take me, but the sooner the better. Currently it lets you edit Plus4, C64 and Spectrum sprites although I still have to put real support for the C64 sprites.

Powering up.....

2009-01-14T20:20:00.004Z

Because I was ill over Christmas, it's actually been a while since I did any real work at home. So I thought I'd make an effort to get over this and actually DO something!

To this end I've resumed the refactoring of RetroEdit and decided to get editing actually working and usable. So now that I think I've actually finished the refactor I was wanting, I've started to write the editing features. I've currently got hires sprites being editing, so I'm about to try MultiColour Mode ones. I'll then do some basic features like scrolling the whole thing around the window, flip etc. then move onto colour editing.

I need to get the selected machine's palette drawn so I can pick colours and then I need to tackle saving. I'll need a PROJECT save, and a binary save. I'll also need to allow plugins so that folk like Russell can save formats he wants to deal with; although he may well end up doing his own editor, but others might need it so...

With a bit of luck, most of these shouldn't take very long, and I can take the core of the sprite editing and move it to the character editing tab. The core concept of this is a special RetroBitmap control. This allows you to deal with retro graphics directly without having to write huge chunks of code over and over - its also a standard control so others could use it in their own projects if they wanted to.

Back to normal?

2009-01-08T17:39:00.002Z

Well, not quite.... I've just gotten my new cable modem installed which has boosted my speed to an increadible 50mb/s!! I've also just discovered that my trusty Linksys router can't keep up, so I'll have to retire it and get a faster one, other wise I'm stuck to around half speed - damn.

So, I need to put my room back in order (theres upturned desks and what-not) then I can setup the plus4 again and start to get back to work. I've been thinking about my electronics again, and I really want to get back to doing some more - before I forget it all, and this lead me to thinking about doing a better download system. You see, as it stands I need a parallel cable/port and thats limiting - particually since I have to switch my machine off/on to enable the driver and plug in the C64 or Plus4. So I was thinking about a USB cable. Theres a few USB to serial cables, and if I did that (along with a PIC or something at the other end), I could pretend its normal parallel cable on the Plus4 side, but do serial on the PC side. This would also mean it was suddenly hot plugable, and allow me to plugin multiple machines at once; not to mention being able to download without rebooting.

So, I may start to look at that kind of thing this year too.

DO.EXE

2009-01-01T23:19:00.004Z

So... one of the big issues I had with upgrading to Vista64 is that a lot of my ( really, REALLY ) old tools stopped working. Now most I can actually do without, but theres one that I've actually been running under DOSBOX to keep. DO.EXE is a simple programmers calculator that I wrote back in the Shadow of the Beast days and does proper programmer calculations. That is it deals with HEX and BINARY as you'd expect, but also does AND, OR, XOR, NOT, Shifts and all the rest of it. In fact, I use it a lot just to convert numbers from BINARY to HEX since C/C++/C# doesn't take binary (its a crime I tells ya!). The old program was written in Turbo Pascal 7 and was very 16bit, and while I had the source there was no way I was gonna "update it".

Well, every since I started my debugger in C#, I had a brand new evaluator doing exactly the same thing, but in a processor (and machine!) nutral langauge! So I've finally pull out my logic prob, and blasted its little binary brains all over the back wall and updated it. Now, I know theres a million similar little programs out there, but I like the command line one, and I like that it takes the same format as C/C++/C# and even Java, and since I've always got a command line open, its ideal. CALC (and others like it) have just never cut it for me.

Anyway... I thought I'd be nice and release this into the wild and let others play with it. Its not hugely tested (so feel free to let me know any issues) but its an invaluable tool. Even simple things like getting bit patterns into HEX is a simple case of just typing it in.

Anyway...enough drivel...You can get it HERE. Shove it into your path somewhere then just type "do" on the command line for options. If theres any doubt in an expression, use brackets. I've not listed any expression order because it's different from all other compilers and that forces you to use brackets more to make sure the answers right. If theres anything else you think folk would like added, feel free to suggest it.

I hope some of you get some use out of it. It's the single most used tool I've ever written - period!

http://www.javalemmings.com/blog/do.zip

Flu season...

2009-01-01T11:28:00.004Z

Happy New Year - and all that jazz

I've not been doing much over the festive season, I've been stuck with the flu and feeling terrible. In the times I have been feeling up to it, I've actually been playing the the Hydra system I bought LAST year. I really do want to get back into doing electronics again, but to do so I need an easier way to make boards - or try and order some up and see how that goes. Etching them just didn't work fo me, so I'd rather try and more automatic way.

I've also been toying with the idea of a userport to USB connector for a more compatable downloader. Theres lots of USB to serial ports, and it wouldn't take much to change that into a pretend parallel connection for the Plus4 (and C64 etc.). So that would be nice. Also using the user port means I can keep the cartridge port free for more interesting things.

RetroEdit cleanup

2008-12-20T23:05:00.003Z

For the lack of any better ideas, I've been cleaning up retro edit into a more consistant state and I've now got the control editing the data in a native format. This means theres no real conversion required when lifting the data out an saving it off - or indeed loading data into it.

I still need to go through the application itself as I've changed my mind on several things. For example while its perfectly valid to allow you to edit HiRes and MultiColour more sprites together I'm not going to allow it. This means you dont have to run through a hundred sprites and switch them all to Hires or MCM, and in reality this would hardly ever happen anyway.

I can now draw a sprite okay so what I really need to do is add colour palette selection to let me pick which colour I want to paint with. Once I've done that I can add the features that make editing fun.

I'll need to extend the editing control to allow for character and bitmap mode because I want to use the same control to do all editing. That said, I'm still not sure what I'll be spending my time on over the Christmas break, but for now I'll carry on with this...

RetroEdit

2008-12-18T21:25:00.003Z

I was looking through the source of retro edit and wondering what I'd do to change it, and came to the conclusion that actually, its not as bad as I thought. The only major change I want to do is how the data is stored internally. You see when I started this I decided to store the data in a basic INT[] array, where each 0 or 1 was actually a BIT, and I would then process the data for editing and drawing. However, this is a bit yucky, and I now think it would be better to just store the data in a more native format. Thats not to say I'll store it in boxes, or colums etc. but as a simple X by Y row of bytes. This makes plug-ins to save the data in a custom format easy.

So I think I might have a little play and see if I can reorginise things so they are more to my liking, and this will (I hope) then allow me to use the custom control to actually do real graphics work.

The way I've gone about this is to have a custom control that deals with retro graphics. So you load it up with the data (in a simple rowxcolum format, and you can then select colours and plot pixels. The idea is that once its released (if ever!) then you could use the control yourself outside of retro edit to do other things. I have no idea if this would ever happen, but it might.

So I've decided to give it a few days and see how I get on. If I feel like Im getting somewhere, I'll carry on - if not, I'll bin it.

SID tunes.

2008-12-17T11:48:00.005Z

I discovered today that one of our musicians has discovered the SID chip. He got hold of a new synth that uses SID emulation (due to lack of SID chips) and has been making music with them. I find this amazing really, that folk are rediscovering older tech like SID chips and putting them to work making really. It's also funny when others comment that it’s all old hat and a waste of time that new comers find so much enjoyment in them that they buy dedicated units to play with. Stuart (Ross) said that while the SID is pretty harsh in its basic form, he loves the way the filters work and the sounds you can get with them - which is of course why oldies like me still love to listen to old SID tunes. While the sound is somewhat unique, at the heart of our favourites is a good tune and because of that, more musicians are re-discovering the wonders of the likes of SID/Synth style music. Great stuff.

Change of direction.

2008-12-15T12:01:00.003Z

So with Christmas comming up it's almost time for my anual direction change. I was hoping that my ATmega devkit would arrive in time, but its looking less likely as time goes on - pooh. Oh well. I've pretty much completed what I wanted to do with Minus4j, although I'd like an option to pick a file fom the ZIP to switch to or load, but until Plus4world allows real access to ZIP files, this isn't that important. I'll probably wrap up what I've got into another release and leave it there for now, although I've yet to look at the sid filters but that may also be defered until later.

As to what project I'll do at Christmas time, well I'm not sure. I'd love to get back into electronics a little, but theres also my debugger and getting it running on a C64 and emulator. I'm also starting to think I need to restart RetroEdit. When I started it I hadn't done much C#, and over the years I've learnt how to do things properly. This means I could make a real stab at a proper system but as i've seen with the debugger, this means some serious effort. That said, I'd love a very simple interface so that I could draw tiles/graphics for myself.

I also really need to get a basic MAP editor togther even if its a very simple interface so that we can make levels for Xeo3. The old one works but is a little crude in paces - it would be nice to fix that.

So I have a few things I'd like to play with, I guess time will tell if I actually GET to...

Java, java everywhere and not a drop to drink.

2008-12-09T21:20:00.004Z

So it turns out the ZIP file issue I was having is a bug, and SUN have now filed it. This is good as it means I'm not going mad! Someone from Sun got in touch and I was able to send them the offending file, so with any luck no one else will have to pull their hair out in frustration.

It's also good to know that it is indeed simple to read ZIPs, and I have been making steady progress now. I now have the ZIP being downloaded, and the first D64 being loaded and run. I really need to orginise the file processing better as it - well sucks. Its hacked in really badly and is sorely in need of a re-orginisation so that the normal rules about loading D64s and PRGs then apply to the contents of the ZIP. That said, I feel like I'm getting sucked further and further into emulator development again, and thats not something I want to do again (or at least, not right now).

This means I'll be hacking together a simple version and then I may update it later to allow better support and the zipping of everything.

I have also started using collections inside java (more to see what they're like than any real need), and while similar to C#, they just aren't as nice. C# has lots of little features like array access to them and handy functions like sorting all built in, where as its a little cruder in Java. Still, at least they're there...

It never rains but it pours..

2008-12-07T20:50:00.003Z

So, I've figured out what was wrong...ready? The ZIP file. And I have no idea why. I unzipped it, then rezipped it, and it all works. Sugar. Does this mean I have to go and rezip every file on Plus4world? Who knows... But at least it appears to be working...kind of. I wonder if I could send the broken ZIP to sun and have them fix it, because I can only assume theres a bug in the JVM. I'll need to see if I can find an unzipping program that CAN'T unzip it, because if they all work then its definitelty broken in the java JVM.

I hate java, I hate java, I hate java, I hate java....etc..

2008-12-06T22:30:00.004Z

So, back with Minus4j once more. I'm trying to get some ZIP support in here so that more files on Plus4world will work, but once moe=re I'm struggling to get Java to behave and do what its supposed to do. Opening a ZIP file in java is pretty is (supposedly) but will it work for me? Will it strawberry. All that should happen is I pass it an input stream and then read files, and while I appear to get no error, it also doesn't appear to actually read any file inside....Oh chocolate.

       BufferedInputStream bis = new BufferedInputStream(_stream, 16384);
       try 
       {
          ZipInputStream in = new ZipInputStream(bis);
          ZipEntry entry;
          while( (entry = in.getNextEntry())!=null )
          {
               // process the ZIP
          }
          in.close();
       }

So in the above code, it just never gets into the inner while loop and I've no idea why - so if you have any idea...let me know. I did think it was because it was coming over HTTP, so I read it all in and build a memory stream, but that doesn't seem to matter. On top of this, no one else seems to have this problem, so I can't find any answers on the net either..... *sigh*

PHP'ing

2008-12-04T19:02:00.005Z

I've been reading through my PHP for dummies book and I'm actually having fun with it! Its very like C/C++/C# with only minor differences really, so I'm thinking of using the Plus4world database to try a few things out; read only mode of course, I;m not stupid! So what I think I'll try first is to see if I can make a "play online" page.

The reason for this is that i've spent quite a bit of time going through all the games and testing them out with the new Minus4j, and their working pretty well. But I'd like to get them all listed so I can see how many we have and get them all under one roof - as it were. It'll also (obviously) teach me more about PHP, and the more I know, the more I can help Csabo out on the site - or thats the plan.

I'm obviously no where near that stage yet, but I find that doing a real project helps focus what your doing and helps you learn. So here we go!

I took was also speaking to someone about multi monitor setups a while back and was saying that while I have 3 monitors at home, I actually have 4 at work! So I've taken a piccy of my development setup (I should really do a home one too - even though its a hell of a mess) for you all to mock. I've got a really old TFT for my main source monitor as it rotates and gives me more lines to read - which is cool. All those monitors are from one machine and gives a lovely big desktop, which means I have loads of programs open at once, So much so...I think I need more RAM - Vista being the power hog that it is. Good fun though!

Oh...and you'll notice I'm still a fan of the good old "clunky" keyboard - I had to look long and hard for a good "click" one! I hate these springy things.

SNOOOOOOOOOOOOOW!

2008-12-02T13:06:00.005Z

We've got SNOOOOOOOOOOOOOOOOOOW!!! Good, proper, BIG snow! This is the view from the Realtime Worlds office, and its great!! I hope it hangs around for a while, but its getting quite bright and sunny just now..pooh.

I got on pretty well with Minus4j over the week end as I managed to get 1551 disk emulation in and working! This means that we should be able to get more games online at Plus4 world. However, I'll need to add ZIP support before we really get invloved in it as most disks on plus4 world actually have 2 sides and are packaged up. Still I think this should be okay, but I'll have to look at it later this week.

I've also got a couple of PHP books so that I can learn a little bit of PHP and help out a bit more on Plus4world; well, that and my DMA Site. It's in desprate need of re-vamping and I'd like to make the whole thing database driven. However, first things first - I need to learn PHP first! I'm looking forward to it I have to say!

I've also been reading through the Yape SID code to see if I can get something from it. The filter stuff is pretty complex and I need to figure out exactly what its doing before I can decided to use itor not.... I'm fairly optimisitc that I'll get something from it.

Vista x64 upload working!

2008-11-29T20:59:00.006Z

I've managed to get the upload program working once more with the x64 driver, however I now need to press F8 whenever the machine is booting up so I can disable driver signing. Stupid stupid stupid vista! I wonder how much it costs to sign a driver. This is a VERY popular driver, so it may be possible for everyone to club together and pay for it.

There used to be a work around where you could just switch it off, but Microsoft in their infinite wisdom disabled it. Its thing like this which will drive folk to other operating systems. (Course... MAC doesn't HAVE a parallel port...)

I think one of the things on my to-do list should be a simple USB to parallel wire. Now I know there ARE some, but I'd love to have a proper one that acts EXACTLY like a parallel port and does all the crap for you. I imagine this would sell pretty well, particually if it could get signed properly. Oh well... another one to add to the list.

Still, for now its working and means I can now test Plus4 code again. The original uploader hasn't changed, but I now have a new DLL and SYS file that I use on VISTA.

So what else is new; well I've added basic SID support to Minus4j but its a bit pooh to say the least. The lack of filter support really sucks and since most music/fx uses them, they just dont sound right at all.Attila has kindly sent me the core of the SID emulator from YAPE and I'll see if I can wedge that in. It's very much like trying to put a square peg in a round whole though as YAPE and Minus4j are not only very different langauges, but have very different design philosophies. Still, its worth a go! With any luck I'll get it added and we can get some good sounds playing in demos.

Speaking of demos, I noticed that many appear to over run their rasters, and I think I've finally figured out why. I dont think Minus4j (or Minus4w) are letting them have a whole scanline. Basically the "newline" function is being called at the start/end of a scanline (HBLANK) but thats not where the timing is working from. The horizontal dot clock is being reset by the newline function and losing clock ticks. This means you dont get all your processing cycles, and would also be the cause of my inability to load tapes. Tape loading is in fact VERY easy (once you have a good sample), all you do is set a bit on/off as it plays, and at the right time. But if the CPU timing is out, it'll never work - explains a few things.

It may however be a nightmare to fix, so I'll have to look into it. It would be great to be able to load PRGs, D64s and TAPs into Minus4j, but I'll wait and see how everything else goes. I really really don't want to get sucked wasting all my time on emulators again...I have bigger fish to fry.

EDIT: Oh, and if anyone else does want to use the uploader on Vista64, then let me know and post a ZIP with the new drivers and installation instructions.

A sound idea and Vista kicking you when you're down.

2008-11-27T12:42:00.007Z

I was fixing some sound issues with Minus4j last night, as I suddenly discovered it was actually pretty broken. If both channels went quite loud and high frequency, it all started to break up - samples too in point of fact. So I spent some time fixing this and its all much nicer, samples sound pretty clean and music in Commando and Monty on the Run are much much nicer.

This then lead me to look at D64 support. I was trying to load TerraNova and it started to work, then didn't. It gets stuck in some odd loop which i think is sample based, but I'm not sure, and I think I have my interrupt flagging wrong. Currently I flag them only when $FF0A is also set, but I believe this is wrong. I think you should always flag them, they just dont kick off an interrupt!

So i thought I'd do some test code on the real machine and see what happens. It was at this point I realised I haven't downloaded anything since I've upgraded (and I use that term losely) to Vista x64. Parallel port access requires a system driver, and under x64 all system drivers must be x64 based. This means my great little 32bit dll which gives me raw access to a parallel port under windows, now no longer works, which in turn means I can no longer download directly to the plus4 - OR carry on with my debugger. FEK!

So I've managed to find a 64bit version of the driver, but its just not working, and now I dont know if thats because the driver isn't working, isn't being found or simply because the parallel port on my machine is set up wrongly. FEK.

So tonight I hope to fix this and test out the interrupt registers a bit more. At the same time, I've started adding D64 support via the Commodore 1551 parallel port registers. This is why turbo loaders dont work on Minus4 as I assume its one of these devices. I used to just intercept calls to the LOAD command, but this is a little better. Anyway, I hope to get basic D64 support in soon although with all the disk turbo loaders around I'm not sure how much use it'll be.

As a little aside.. I was looking at the Minus4sim I started years back. This was a cycle perfect version of Minus4, but I got bored with emulation and mechanic was a little too messy for my likeing. However... C# has some really, REALLY cool constructs for pausing code mid execution, and i think if I ported it over to C#, it would all become VERY elegent and simple to follow. No longer would you have to hold partial states etc. You just pause and resume. So I may play with this at a later date as it would give some very simple code but yield some amazing results. It would also allow me to finally do a fully emulated 1541, which I've been meaning to do for years.

Still mustn't get too side tracked. I have to finish up with Minus4j, then the debugger, then back on to Xeo3.

Cool Electronics things....

2008-11-26T13:42:00.005Z

So first a couple of links:-

http://www.belogic.com/uzebox/index.htm
http://www.ladyada.net/make/fuzebox/

Now whats this got to do with anything? Well have a look at these videos

Very cool indeed, more so because its not a particually expensive chip. So I was wondering what more you could do with it, and I've been having a look at some videos, and the specs. Now I've always used PIC Microchips, but I've noticed an increasing number of projects using these ATmega things and after looking at the datasheets, I can see why. The assembler is actually pretty nice! It looks normal! PIC stuff is okay, but I'm not a fan where as the ATmega has 32 registers, hardware multiplys, and most instructions take a single cycle! Now that IS interesting! Now have a look at this video....

This guy does various demos with it, and he gets some pretty cool results for such a small little device. So, I've ordered myself a little kit to playwith, and I might try hooking it up to a VGA monitor (I'm still struggling with PAL colour output, this phase shift stuff is a tad confusing). The other thing this little chip can do that PIC's simply can't, is address external RAM without having to do all the work yourself! Thats awesome! It means you could have megs of addressable SRAM (in the same way a Plus/4 could) without any speed loss, where as a PIC would really struggle as you have to set address lines, read and write data lines et..

What I would really like to try is making a GPU for a plus4. If I use dual port RAM, I could get the plus4 to write into the ATmegas ram, then get it to use it as a frame buffer and render things. This means you could switch the plus4's screen off (saving lots of CPU time), and then output the signal from the cartridge's ATmega chip. You could then add sprites, sound and all the rest without too much effort. if you really wanted to, you could have multiple chips each doing a different job - one for 10 channel SID emulation (or something), another for pure sample playback, and perhaps one to deal with chatacter maps, and another could add sprites etc... kinda like an arcade machine does.

Course...that won't happen. but i'd love to try and hook one up to a Plus4 and see what it would be like. Having already done a RAM expansion without opening up the plus4, I don't see why something like this couldn't be done - it'd be neat!

JAR files.

2008-11-23T15:53:00.003Z

I've been having a little trouble getting resources inside JAR files working, I took some code from my mobile phone days and used it inside Minus4j without any luck. The idea being that I could package the ROM and WAVE files up in the JAR file, and so I wouldn't have to do a slow load over HTTP.

I've now managed to get this working by using the main minus4j class rather than a java object. No idea why this matters, but it does, and it's now working. This means I can now package up ROMs and samples without having the extra paramaters or load commands, which it turn will spead up loading.

I'm also planing to add a virtual keyboard that will let you click keys rather than search for them - Saying I don't get bored of all this first of course....

Minus4j Version 1.5 released.

2008-11-21T21:17:00.003Z

I've just released the latest version of Minus4j, this is the one thats been up on plus4 world for a week or so. Its got some major improvements like Audio, joystick/key combos and auto starting via the filename.

Added a paramater for the initial frameskip value.

Removed software screen scale and now use built in JAVA one - should be MUCH faster.

Added ESCAPE key (Escape)

Added RUN STOP key - ` (backwards apostrophe, beside 1 key)

Added the * key (numpad)

Added undocumented opcode LAS,Y ($BB) command. Danger Diamonds now runs.

Minus4j now picks up sys0000 style RUN commands from the filename. So games like "mercenary_sys23552.prg" now work without a seprate RUN command.

Minus4j now picks up g12AB style RUN commands from the filename. So games like "mercenary_g5C00.prg" now work without a seprate RUN command.

TED Sound!!!

TED Samples!!

New "sound" paramater. sound=off or sound=on are valid. ON by default.

You can now press F7 while running to toggle sound (mute).

Added VOLUME control register.

If joystick is enabled, CursorKeys and Space key is disabled.

INSERT now does a soft reset.

Emulator now shuts down better.

You can get the latest version from minus4.plus4.net.

Virtual Machine JOY!!

2008-11-16T22:51:00.003Z

I've just installed Microsoft's Virtual PC 2007 with Ubuntu running as a VirtualMachine, and its all going pretty well for a first install....so much so, that I'm typing this inside the Ubuntu VM! I've been testing the java version of Minus4 and it runs pretty well here, of course this is a pretty big machine (quad core, 4gig ram etc.) so its not a big surprise... still, at 50fps its pretty solid.

Once you scale the screen it starts to get sluggish, but a single frameskip pushes it up into the mid 40s and another to an solid 50. This is fine for games like mercenary that didn't draw the screen that much - or even XeO3 as I only draw the screen every second frame.

I still have to get sound working - and get the screen res fixed as its currently locked to 896x600 for some odd reason. Once I've done that I'm going to try and get mono installed ready for some real work! Then I want to get a Mac VM created (if possible) and try the same stuff there. This would give me a solid development platform and let me do ALL my work from a single machine/desktop! How fekin' cool is that!

Let there be sound!

2008-11-16T19:35:00.003Z

After a marathon day yesterday I managed to get some audio into Minus4j, and it really does make a huge difference. For the moment its TED sound only, and I do still have a little bit to do yet before its really nice, for a start volume isn't used at all! I ported this code directly from Minus4w and have only just noticed that theres no volume control on it, doppy bugger that I am. Still, you now get 2 TED channels (tone and noise) and samples (using the TED). Samples are a bit crude to say the least, so I'll need to work on that a little - although I think I'm driving my wife mad listening to odd sounding beeps all day, oh well.

Once I have TED music in a better state, I'll port over my SID music player, and although its far from great (its a little rough and uses NO filters), it's still a good 1st step. After that, D64 support will almost bring it in line with Minus4w! Almost.... I'll need to see if its possible to save data to the local machine which would allow you to save games etc. other wise adventure games would be a pain. The solution to this I guess would be to port Minus4 to C# and Mono, this would allow it to run on any machine, AND on silverlight at a later date. It might also be a good time to use my cycle exact CPU I wrote about 6 years ago! It was designed to be more in line with YAPE than my scanline based one.

Still, thats a loooooooooooooooooooooong way off, and theres loads to do before that. Russell also pointed out that I could let Minus4j host my debug stub as well, meaning you could develop and debug Plus4 apps on Linux or Mac OS, which would be cool.

Anyway, head over to www.PlusWorld.com to see (and hear) the latest one in action! I've also started validating demos on Plus4 world, and although some just dont work, many work fine and its a much easier way of browsing them. We should really do an online demo page so you can have simple access to them.

Even more java love.

2008-11-15T14:26:00.006Z

I've updated Plus4 World with the latest version of Minus4j. I've added a couple of handy features that allow even more games to run. The change list is below, and although I've not offically released this you can go and sample its goodness at plus4world.

Added a paramater for the initial frameskip value.

Removed software screen scale and now use built in JAVA one - should be MUCH faster.

Added ESCAPE key (Escape)

Added RUN STOP key - ` (backwards apostrophe, beside 1 key)

Added the * key (numpad)

Added undocumented opcode LAS,Y ($BB) command. Danger Diamonds now runs.

Minus4j now picks up sys4172 style RUN commands from the filename. So games like mercenary_sys23552.prg now work without a seprate RUN command.

Minus4j now picks up g12AB style RUN commands from the filename. So games like mercenary_g5C00.prg now work without a seprate RUN command.

I'm also looking to add sound just now. This is a long standing issue that I'd love to fix so I've been looking at a couple of other emulators and how they handle sound. I not have my Java applet buzzing with noise so thats a good start! I should now only have to port over my TED sound stuff (and later SID sounds) in order to get it playing. Although theres obviously a long way to go before that, but at least theres a buzz about the place now.

More improvements to Minus4j

2008-11-13T13:28:00.004Z

So I was adding the escape and run-stop keys to the emulator last night, and was about to change the fire key from space to control (or something) when I hit a road block. Java doesn't GIVE you acess to the control key - or shift and ALT for that matter. These keys come through as modifiers, meaning you only get them when another key is pressed. Fek.

I'll need to look at other emulators and see what they do, but if this is the case Im not sure where fire will go - unless I disable the KEYBOARD "space" while joystick is active. Thats a bit fudgy, but it would work.

Oh well, I'll just have to carry on until I figure out something better.

And another thing.... In the future I hope to ditch Java altogether and move to Silverlight which is all C# (much nicer!). Someones already done a simple spectrum emulator HERE and while its not ballistic (because it still quite new), it will be better in the future, and MUCH nicer to code for. I suspect any C++ app can be ported over to it reasonably easily - since its C# and not java. Very cool.

Polls are now closed....

2008-11-11T12:43:00.004Z

So...I thought it was time for another poll. Heres the results of the last ones.

What do you hope to do with XeO3?

Just play it! 52 (60%)

Just to look through the source for ideas 14 (16%)

Make my own levels. 7 (8%)

Reskin the whole game to make my own shoot-em-up. 6 (6%)

Use the full source code to make a complely different game. 6 (6%)

I'm not interested at all 1 (1%)

Which platform are you most interested in?

Commodore 64 56 (41%)

Commodore Plus/4 27 (20%)

All of them!! 15 (11%)

Amstrad CPC 14 (10%)

Commodore 64 Super CPU 10 (7%)

I'd like it on a different platform... 7 (5%)

Sinclair Spectrum 5 (3%)

So a couple of surprises.... One that theres actually 10 SCPU users! (unless he cheated and voted 10 times....), second that the CPC version out stripped the Speccy. Course, that could just mean we dont get a lot of speccy folk dropping by.

But with the main poll having a few folk actually wanting to use the source/scripting, I thought I'd ask another one. have any of you ACTUALLY looked at the demo scripting? Or better yet, even done something with it?!?!? Theres a new Poll over on the right, so let me know.

More Java - man I hate java...

2008-11-09T17:47:00.004Z

So with the release yesterday Minus4j is actually in pretty reasonable shape. Sure it needs the source cleaned a little - theres loads of commented out crap in there, but on the whole not bad. So as I was adding another paramater to it (allowing you to specify the initial frame skip - since Xeo3 runs at 25Hz, you never NEED 50fps drawing), I suddenly realised that these days, Java probably provides image scaling as part of the API!

And sure enough.... there it is. So, I've now removed the software scale I was using and now use the API. This is of couse good for 2 reasons. One... being part of the API means it might be assembler optimised, and not just some tacky code I did, and second it reduces the code I've to maintain. Its all good.

Before I set it all aside again, I'm going to look into sound. I do this every 3 years or so to see how much effort it would be to add sound to Minus4j. When I started, you just couldn't, but there are now a few apps which do what I need to, so chances are its not too hard. All I really need is a buffer or two that plays music at a specific rate through a software buffer. I can then fill this up as I emulate things. This would let me plug in TED and SID music - not to mention samples that Minus4w can play. That would be cool - then all I'd need is some basic D64 support!

Oh... and while I won't release all these little bits, I will update both my blog and Plus4world to use all the latest stuff, then release it when theres enough to package it all up.

Speed UP! Slooooow down....

2008-11-08T19:49:00.006Z

So, it turns out the Java compiler is fine (I think). My timing code (that makes the game run at a specific FPS) appears to be crippling things. But I have no idea how. If I take out my timing code and run the game unscaled it ticks along at 350fps - or 7 times the normal frame rate. It looks like thats correct too as everything is moving about 7x the speed, so I think the FPS counter is working.

So... whats wrong with my timing loop thats crippling it so much? I've tried to set and FPS of 200, but as soon as I do that, it tops out at 65fps. If I remove a couple of lines (the bit that makes it work), it jumps up to 350 again. So somethings rotten right in the state of Denmark... So, heres the timing loop, perhaps someone out there will spot it and save me staring at boring code for hours on end.....


          long tLastGameFrame = System.currentTimeMillis();
          long tNextGameFrame = tLastGameFrame + FPSRate;

          Last = tLastGameFrame;
          while (true)
          {
               long tNow = System.currentTimeMillis();

               // Quick check to see it timer has gone backwards!!
               if( tNow < tLastGameFrame ){
                    tLastGameFrame= tNow;
               }

               // Check to see if system is stuttering due background OS stuff.
               // if jumped ahead over 5 seconds, then just reset...
               if( (tNow-tNextGameFrame) > 5000 ){
                    tNextGameFrame = tNow;
               }
               
               // Timer has gone backwards
               if( tNow < tLastGameFrame ){
                   tLastGameFrame= tNow;
               }


               dTime = (int)(tNow - Last);
               if (dTime >= 1000){
                    dTime -= 1000; // dont get 0    (1000/1001)
                    actualfps = CurrentFPSCount;
                    CurrentFPSCount=0;
                    Last = tNow;
               }

               // Now the main timing loop
               if(  tNextGameFrame >= tNow ) 
               {
                      // do nothing...or yield/sleep
               } else 
               {
                      while( tNow>tNextGameFrame){
                             tLastGameFrame = tNextGameFrame;
                             tNextGameFrame +=  FPSRate;
                      }
                      CurrentFPSCount++;
               }

And there you go... pretty simple. Oh, and the reason for the backwards check is because in the modern world of clock syncing (to time.com or something), your clock might briefly go backwards. If this happens timer loops break - had this happen twice! Once on mobile phones, and once on a PC. Took me AGES to figure out the Mobile phone one, but fortunately I remembered about it for the PC.

New version of Minus4j released.

2008-11-08T15:47:00.004Z

Well, I've decided to release what I've done so far so that Plus4world (and anyone else) can get the new bits.so head over to my MINUS4 site and get the latest one if you need it. Heres a list of the changes...

Updated rendering engine ported from Minus4w, should handle more cases.

Updated CPU processing ported from Minus4w. More games should run.

Fix a crash in the CPU processing.

Changed the colours to what Yape uses (much nicer)

Added FLASH attribute, so things now...flash. (Manic Miner keys, Monty pick-ups etc.)

Fixed the rendering frameskip - it was always skipping at least 1 frame *idiot*

Fixed the overflow flag (V) on the ADC instruction. Mercenary now works!

Added the new "joy" paramater

Fixed commando - added several undocumented NOP codes.

SOME vertical scrolling games work.

More Progress.

2008-11-08T14:41:00.016Z

I've managed to fix Mercenary, although it wasn't the BCD mode it was the overflow flag inside the ADC instruction. Anyway... Here (I hope) is the current version. Click on the screen and then use the cursor keys to move and space to shoot. F9 is frameskip which may help speed it up on some slower machines. I'll be doing a release of this soon for Plus4World, but in the meantime - Enjoy!

This is pretty neat as it means I can show new things as code rather than video. However the new version of Java appears to be a little sluggish for some reason, and frame rate has dropped a lot. In the past I used to get upto 450FPS but that has now dropped to around 70fps - without scaling...pooh. I hate Java...

Still, when all said and done - how cool is it to have xeo3 actually PLAYING in a web page!!

Life in the old dog yet....

2008-11-08T13:14:00.002Z

I've managed to debug Minus4j using Eclipse. This is a JAVA based IDE and its pretty spiffy in places. Couse...being Java based, its a bit sluggish - even on my new monster PC. Oh well, at least I can single step my applet!

So, which one hurdle down, another begins... I've ported a lot of Minus4 back to Minus4j (its pretty cool that the code bases are virtually identical, coz I can cut and paste most changes), and the bug I had was simple that the mainloop on Minus4w had changed a bit, so a quick change on the java side, and we're all go!

Minus4j now has inverted characters, the flash attribute, and a proper hardware cursor (not that anyone really used it outside of basic of course... but still... I'm also trying to update the CPU module as well, as minus4j is prone to crashing, and doesn't run some games (like Mercenary). I'm having a little trouble getting Mercenary to work - oh it runs and all, but it doesn't get past the intro. I'm sure this was a BCD problem, but I've ported the BCD stuff back from Minus4w and its still fubar. Mmmm...

What would be nice is if Plus4world could just allow EVERY game to be played online. Sure some wouldn't work, but I think most would and it would be easier to exclude some, then include them all.

Anyway, back to work I guess. I need to try and fix this BCD issue (if I can find it), and then add an option for joyport swapping to the paramaters (another request). I would love to add sound, but I'll need to look into doing dynamic WAV's under java. I know the C64 emulator can do it, so I might disassemble that and have a peek.

Intermission....

2008-11-04T22:07:00.003Z

Albatross!! Albatross!!! Get yar Albatross here!

okay... Got slightly side tracked as a beta of Call of Duty 5 came out today so I had to have a blast at it... FAB game, got to be one of my fav all time games the COD series. Anyway... Aside from that I'm trying to update Minus4j for Plus4world so they can get more games on line, and so its well....better.

It does have some issues and I thought I'd port back some Minus4w stuff. This should be easy as the source for Minus4w originally came from Minus4j. So it was all going swimingly well, then BANG! It all fell apart. I have the drawing code ported back and as far as I can tell its now identical, except Minus4w works, and Minus4j jumps up and down like a rabbit on a pogo stick. So now I find myself in need of an applet debugger. Im sure it'll be obvious once I debug it, but until I do... I'm a bit stuck. Fek. I could undo it all and then just fix one issue at a time, but that seems silly as Minus4w is much bette over all.

*sigh*

Almost there....

2008-11-01T11:45:00.002Z

I've just about got my PC setup again, althought theres always going to be apps I've forgotten about and will only rediscover later on. I thought I could get away with just installing the C# Express edition for all my needs, but alas no. I really need macro support and it doesn't have source control built in so I'll have to install the full Visual Studio again. I do hope to do some C# Express projects for the debugger to allow people to write plug-ins without having to buy the full visual studio though.

Speaking of source control... I've reinstalled Visual Source Safe so I can get access to my old repository but I'm thinking I want to install SubVersion. This would bring me upto date a little and allow others to check stuff in/out of my depo. Russell's been moaning at me for months to let him get access to the debugger and so he can keep upto date with the XeO3 source. I have come across a tool which converts VSS databases into subversion ones, so I'll have to give that a go - I like having all the history for them, but as long as I still have to old VSS repository I guess its not a huge issue.

The guys wanting to do a CPC+ version of XeO3 got in touch (again - I missed them 1st time around; my bad), so we'll have to have a chat and see if they meet the criteria for offical developers (Yes, I'm a picky bastard...).

I'm having a slight issue with my new install as it's a 64bit OS, my 32bit apps are struggling to talk to the parallel port. Still, once I get DevStudio installed, I'll see if I can fix all that. It should also mean I can release 32+64 bit versions, or I might take the opportunity to port them to C# and mono.

I've also downloaded a VMPlayer and will get a mono vm image so I can start doing Linux support. This will let me play with Linux without having to dedicate a machine to it, or even reboot into it. (I hope - depends on how the free vm player works.)

So with any luck... back to normal next week!

uniracers_credits

2008-10-31T21:11:00.003Z

uniracers_credits
Originally uploaded by mikedailly

So someone was asking who was who... so here we go (hope I remember it right!) Clockwise fomr the top-left.

Robbie Graham - Artist
Malcom Scot Maxwell - Game coder and project leader
Dave Jones - Boss, Big cheese, and all round pest.
Andrew Innes - Front end, stats and general coding.
Martain Good - CG artist (did all the unicycles!)
Steve Hammond - Manual
Mike Dailly (Me!) - Level Editor, Uniracer compression, SNES framework and tools.
Colin Anderson - Music and effects.
Craig Arbuthnott - Head of testing
And I cant remember the last two. Testers I think....?

Head over to the staff pics on the Flickr account for better (all be it older!) pictures of some of us.

Demo coders....

2008-10-31T19:37:00.004Z

There was a post on plus4 world about how to teach new people to code on the Plus4 and it got be thinking about some pet hates. Demo coders are renown for keeping sources to demos secret, never releasing anything but binarys in case someone steals their ideas. Others don't release code becasue, well... demos are usually hacks that are horrible bits of code and they don't want anyone to see just how much of a hack it is. Great Demos usually flow like works of art, but if you saw the internals, then its like being told how a magic trick was done, and the wonder falls away.

Still, I was thinking.... I never really code demos because, well... I'm not very good at them. Sure I can code things so they run quickly, and I can code things so that they're small. But I've never been good at prducing great demos folk really want to see. That said, I think theres a market (as it were) for demos that simply show how to do something. Kind of like online tutorials, simple demos that show off a simple effect and how to pull it off. This would allow others to use it and do what I can't, make great demos - or perhaps even use the effect in a game!

I was watching the demo posted here and was trying to think how they did the full screen scaling coz I think it would be cool in game. I think now I know but I also suspect that if the source was available I'd be much more interested in using/trying that I am now. Anyway, Csabo over at plus4 world is thinking about this too and I think its a great idea. If nothing else, it adds something valuable to the scene - which is what its all about now.

It's alive!!!!

2008-10-29T23:23:00.003Z

I've rebuilt my PC, got a hold of a version of Vista64 and got it all up and running. I've also installed my new copy of office so my email is working fully again, which brings me to another point. If anyones been trying to get in touch and I haven't responded then feel free to ping me again as email should be back to normal.

I now have to reinstall all my normal software again, which will take a couple of evenings I guess, but I hope that by the weekend, I'll be back to normal - but with my fancy new quad core. I have also gotten two new terrabyte drives to try and get rid of all the little drives my PC was using, so with any luck... I shouldn't have to do this again for a long time!

New bits!

2008-10-28T12:19:00.004Z

My new bits have arrived at last! So I can finally get started on rebuilding my shattered life...err..PC. The motherboard looks pretty good and actually has 4 DIMM slots, not the 2 I thought it had (the picture was pretty small), this means I could go up to 8Gigs of RAM if I want to (thanks to Vista64).

However...first things first. Build and reinstall is the job for tonight, if I get a chance - hope so. I'm gonna go and buy another 1Tb drive though so i can cut down on all the smaller drives I keep having to put it. My old primary was 160Gb, then I had a 240Gb and a 500Gb. So sod that, time to clean up and just get 2 1Tb drives. They're getting pretty cheap now, ebuyer actually had an external 1Tb for only £85(ish). This'll make life much easier and I'm beginning to get retro withdrawal!

Picture Fun...

2008-10-26T20:52:00.002Z

I've been having fun with my new camera, and have been out specifically to take some nice piccys (something I plan to do more of if i get the chance!). I want to play more with the technique known as tilt-shifting. This is where you make real things look like models, and its very cool indeed given the right image. So I went up the law hill (the large hill bang smack in the middle of Dundee) and took a few images, then had a go applying the tilt shift effect to them. The image shown here is one of them, but I'm uploading more to my flickr account along with any other pictures I take (since they can stay full res there).

So if you want to see some of my piccys, check our my flickr account now and then.

New machine...

2008-10-26T13:03:00.007Z

Well, with pay day comes the chance to finally fix my machine. I've order the bits I need to rebuild my main machine and I must say, I'm really looking forward to actually sitting down and a proper PC and not using a laptop. When multi-monitor appeared back in windows 98 it really did change everything. Not that many took notice back then, but I've now been using more than one monitor for so long, I really take bad to laptops with a single machine. In fact, at home I have 3 montors, and at work 4! Yes, you read that right...I have a single machine with 4 montors attached! I really should take a picture of it sometime as its quite neat. It lets me have virtually all my applications open AND visible - its very cool. I do wish they would make newer PCI cards other than the NVidia 6200 or ATI 7000 (which isnt Vista compatable)- which are both pretty crap.

So, I've bought a new motherboard that'll take my new quad-core CPU and 4gig of ram. To be honest, I'd be happy with a dual core, and 2-3gig ram but since I dont like doing this, I may as well make sure I dont have to upgrade for some time (a year or two at the least), so I've bought a good setup. Its costing about £250, but thats still less than half the price of an off the shelf full PC (from what I've seen...). I've also decided to install Vista64 (*sigh*) because I dont want to have to go through this again anytime soon... It does mean I'll have to either install DosBox, or rewrite the important ones. The other reason is so that I can create 32 and 64bit apps easily. I want my debugger to run in 64bit mode for example, and it also means I get access to ALL my RAM - which is nice... So yeah... hate it, but Im buggered.

When I was in the US I got a stack of BluRay disks, and I was horrified (and disgusted) to see they've started to region code things. Now, I read somewhere that they do this because something might be released on disk in the US, but just be coming out at the Cinema over here in the UK. Now, you might think well...okay, we might just about give you that. But then I was reading through a list of region coded disks, and found out The Longest Day was also region coded. Now... it was released in 1962, so what the hell do they take us for. In todays climent, we're in a world market, not local - particually with the credit crunch having been in the US but affecting the world. So I think it's actually a form of racism. After all your giving preferential treatment to some contries, and not others - and thats racist; Particually given that their excuse of movie release dates is an obvious lie. Region coding pisses me off. I paid for the disk, I bought it legally when on holiday, so why shouldn't I be allowed to watch it? We're a global enonomy, so why should Joe Blogs from the US be allowed to watch it and I'm not.... Now I'll have to wait and get a multiregion bluray player. I'll tell you one thing though, I will have NO guilt getting a hidef media version of it to stream from my PC - I already own the fucker. I'm a big fan of buying things you use,watch or play. If you get a copy of anything and dont like it, delete and and dont buy it. If you do..then you should buy it - whatever it is. I have a stack of games I tried loved so bought - many are still shrunk wrapped and only opened when I go back to play them years later. So my region coded Disk will be the same. Still wrapped, but at least I own them.

Sorry.... bit of a rant there.... Oh one thing though.... Some BluRay disks over there come with a PC media version, which is a FAB idea!! Well done those guys (whoever thought that up).

Past tools.

2008-10-24T10:18:00.005Z

I've just my old SNES framework source, so if I get a chance I'll clean it up and release it. Not sure who its of use to but its always fun to look at others code so... It does have a nice squareroot function in it, so you could always steal that. Its also (of course) 65816 based, so C64 SuperCPU users could steal more from it. If its of immediate interest let me know and I'll try and do it sooner....

Speaking of SNES.... I found this video on youtube ( YouTubes great! ) of the end sequence to Lemmings II. I had pretty good fun doing this. Theres actually a single pixel on the front end screen that if you click it, you get to the end sequence without playing the whole game - see if you can find it. ;-)

Home sweet home....

2008-10-21T22:40:00.003Z

I'm finally back from Florida and back at work (pooh...), but until I get my main machine fixed I won't be doing much of anything. I just cant work with my laptop, its small keyboard and single screen. I could use its screen and an LCD I suppose, and plug a USB keyboard in, but it just doesnt feel right. I really am an old geezer stuck in his ways - oh well.

If anyone needs any small task done, nows probably the time to ask :)

Disney world fun and games.

2008-10-12T14:34:00.007Z

Still here having a blast. Kids are loving it of course, and its a shame I'm being forced to relax and have fun too! I've not done anything over here, and I'm not sure I'll manage until I get back home and get my machine rebuilt. I was looking at some off the shelf PC's, but they're so damned expensive I'll probably rebuild it myself; I only really needa CPU+Motherboard I think so...

I got a new camera over here too. A nice Nikon D60, very cool. Piccys are virtually always just brill from it without having to do anything special, and the manual settings are great fun. The piccy on the left was taken with it on auto setting. It just works...fab cam.

Anyway... off to church and then downtown Disney for some more shopping! It's a hard life....

Busy busy busy!

2008-10-10T01:01:00.004Z

Been busy having some serious family fun so not had much time to do much - well, anything really. Still really needed to chill so here we are!

Kids have been in the pool a lot, and while I've only dangled my feet in, I've been lovin' it!

Still, time to eat I think, it must have been about 30min since I last ate! :)

Orlando!!

2008-10-08T12:23:00.006Z

I'm currently in orlando having a family break, it's long over due really but I'm loving it!We had a great flight over as the plane had TVs in the back of the seats, so you could pick your own films or TV programs. It also had some good games to play, so Rebecca and I had great fun - I didn't even get my laptop out I was having so much fun!

It's been raining a bit here, usually for about 1/2 hour a day, and it's incredibly heavy (as usual), but because of that, it's not getting as hot as it can get which is great!

We've actually spent more time in walmart than anywhere else just about! The misses is loving it! We spent most of yesterday in the Animal Kingdom and eventually had to leave cause the rain was so heavy we were soaked through. Our clothes dried pretty easily, but our socks/shoes were soaked. I also appear to have killed my iPod, as my bag got soaked through, and the screen is full of watter - bugger.... I'm trying to let it dry out before trying it, but iPods never really switch off so I'm not hopefull. *sniff*

Plus4 world lives again!

2008-09-27T08:17:00.002Z

Plus4 world now has a new home!! Although it still has some way to go in terms of files etc, you can now at least log on and use it again.

http://www.plus4world.com

Thanks again to Csabo for all his hard work!!