Sunday, September 25, 2016

ZX Spectrum colour clash on modern hardware

There are always some games that like to do very retro looking games, usually in the style of a Spectrum since you still get "hi-res" from it, rather than the C64 or something where pixels were doubled and couple look a bit nasty, even for today's retro fan club. However, as retro as they look, they never really capture the full spirit of the old machine because of one thing - colour clash.

The ZX Spectrum's screen consisted of a hires (for its day) bitmap of 256x192 pixels, and a colour (or attribute) map. The pixels in the bitmap would get coloured every 8x8 pixels depending on the colour in the attribute map.

So, roll onto modern day. We no longer have separate pixels and attributes so simulating this old mode can be a little tricky.

Roll on further and I suddenly realised a really simple way of achieving this using the hardware we all have in our machines already. So lets say we simulate the way the spectrum drew things, a bitmap screen an a colour map. First, lets draw everything in "white" pixels only - which is much like the spectrum would be, it would look something like this.

If we then drew the colour map, we'd just end up with big blocks of colour going over the top of the screen - like this

And this is where modern hardware struggles. However... if we could somehow use the first image, as a "mask" for the second, then we could get rid of the pixels from the blocky colour image and get the image we wanted. We could generate both these images and then send them through a shader and do - well, whatever we want to, but there's actually a simpler way.

Let me introduce you to destination alpha. DestAlpha is the alpha channel on the screen surface (or render target) that you render to all the time anyway. Whenever you draw a sprite the RGB goes onto the surface from the texture/sprite your drawing, and so does the alpha. When you clear the screen to black with no alpha (or UINT32 of 0x00000000), and then draw a sprite onto it, you're effectively making a copy of a sprite. When you start drawing lots of other sprites it all gets a bit of a mess and is basically useless, but if you control can be very handy

There's also another string for our bow; the colour channel write mask. This lets you switch off and on the different channels of the screen (red,green,blue or alpha). Now it gets very interesting.....

Lets say that black and white image above was also represented in via the alpha channel.
The image shown here has white pixels where there is data, and transparent everywhere else. This is a "mask" of the data we want to draw, and if we put the same data into the alpha channel we can use "destalpha" to actually mask everything.

So, the first thing we need to do is draw the background - whatever we want, however we want. Next we need to clear the alpha channel only - leaving the colour screen intact. We do this by setting the colour channel mask so that only the alpha channel is being written to. We can then render a filled rectangle with alpha of 0. One the alpha channel is cleared, we then set the colour mask back to normal and render everything else.

Once this is done,  the alpha channel will look something like the transparent image above, a lovely alpha mask - now if only we could add this to a sprite it would be like any normal texture....  Step in dest alpha. Normally were use source alpha, inverse source alpha as the blend mode. This would normally take the alpha value from the source i.e. the texture, but now we'll use destalpha, inverse destalpha. This will use the screens alpha channel as the alpha for the blend.

Now when we render the solid rectangles of colour that would be the colour mask, the underlying pixels that crated the alpha channel, will only let colour through were we drew a pixel in the first place.

So, by using the transparent image as the alpha channel of the blocky image, we're left with the image above - which is just like the spectrum.

Now comes the good bit. When we render objects - players, baddies, pickups etc, all we need to then do is change the colour block in the blocky image (which is rendered layer), and then this gives us the same blocky, colour clash feel that the spectrum had

Here's the general order to rendering things....

Render "paper" colour map  (32x24 of 8x8 blocks of colour)

Set colour mask to alpha only

Disable blending and alpha-test
Draw giant flat rectangle of 0 alpha, and 0 colour
Reset colour mask to full ARGB
Enable alpha blend and alpha test

Draw everything

Set colour write mask to RGB - disabling ALPHA

Enable alpha blend and alpha test
Set blend mode to DestAlpha, Inv_DestAlpha

Draw all colour blocks (32x24 of 8x8 blocks of solid colour)

Set blend mode back to SrcAlpha, Inv_SrcAlpha

Once you've done all this.... you'll be using the "pixels" from your sprites, and the colour from the attribute map. Whats better is every bit of hardware out there can do this. It's all standard blend modes stuff - even older hardware. If you've done all this, you should get something like the video below. Make sure ALL your sprites background graphics are transparent, and don't have solid pixel colours (like black) as this will effect the mask.

One final point... It should be noted that the "colour" pixels written at the same time of the mask aren't really needed, but if you colour them as they are meant to be (not just white), then it means you can easily switch the effect on and off without affecting the game. This gives the end user the option to have colour clash or not, which is a nice side effect.

Friday, January 01, 2016

Why create a GameMaker export to the Raspberry Pi?

Okay, these are very much personal opinions...
So I've been asked a couple of times why bother? It's a tiny machine with (probably) zero chance in making money from it - so why?

First, the Raspberry Pi is an amazing thing, Eben Upton and his various partners have done a phenomenal job getting it out in the first place, never mind the subsequent work of getting the Pi Zero - which is beyond amazing!

What I love about the Pi more than anything else, is that you no longer have to decide to take out a second mortgage on your home to give your kid a computer in their room! What's more, you no longer have to worry about them breaking it. At $25 you can just get another one. With the Pi Zero, this is and even simpler decision. Having a computer in my bedroom when I was growing up was life changing. Without that, I'd never be where I am now.

Of course.... there were other factors that helped. First - content. Without games to play, I'd have grown bored very quickly, and my ZX81 would have ended up in a drawer. What you need to inspire development is inspirational content. You want to play games, use programs and hardware and think - "That is SO cool! I want to do that!"  This is what drove me. We used to play the simple games available, type in programs from magazines, and spend hours trying to do stuff ourselves. 

Put simply, this is what I want to help achieve. With GameMaker, we have access to users who can provide these inspirational games, games that you want to play over and over, games that make you want to try and create stuff yourself.  Sure, there are limits. This isn't a Quad core i7 with 16 Gigs of ram and enough HD space to store most of the internet on. don't have to be full 3D ultra-realistic to be good. Vlambeer have some amazing games, Locomalito has made some astounding games - ALL FREE!  All they need (in theory) is a port of the GameMaker runner to help make it happen.

So... that's my reason number one. It's how I started, and if I can help others do the same, I'm all for that.

Second - Education. Not so much for game creation itself, but for Electronics. Currently most folk seem to use Python to do this, and to be frank - python sucks. Even with simple GPIO commands I've been having great fun with it. Remote development is ideal for this kind of thing, because when things go wrong and the Pi crashes (as it inevitably will), you can simply reset while your entire dev environment is safe and sound on a separate machine.  At some point I'll get the remote debugger working as well (It almost works now), and that means you'll be able to step through your code and development will be even easier.

On top of this there is an emerging home brew arcade scene. Folk like Locomalito take their games and stick them in PCs inside arcade machines - like a mame cabinet does, and then run their games like in the old days, complete with arcade buttons and joysticks. These days, they appear to be moving more towards using the Raspberry Pi - it's cheap, has lots of easy to use pins for interfacing and if it blows up - meh, they can buy another one. The runner port will allow games to be run on the machine, while the GPIO commands I've added will help them interface with buttons and joysticks easily.

Lastly... a word about the Pi Zero. I can't begin to say how much I'm impressed they made this happen. It's such an incredible break through, They even gave one away on the cover of a magazine! I'll let that sink in...

They gave away a whole computer on the cover of a magazine.

Wow.....It has the same GPIO pins as the PI, and while only a single core, it is a 1Ghz core. This means you could make a case for it with a 3D printer, get some very cheap SD cards, and then sell your game as a plugin console - probably for $20 or so. That astounds me. Even without the case etc. you could sell you game - complete with computer, for less than $10.  You can buy 50 micro 4Gb micro SD cards for £1.36 each, add that to the price of the Pi ($5) and you're still going to make a profit at $10. Wow.

Before the Pi came out, we tried to get GameMaker 7 actually running ON the machine. We almost got there, but ran out of time. We were doing it for free because we believed in what they were doing, but commercial pressures reasserted and we had to move on. Long term, I'd love to see a GameMaker IDE of some kind running ON the Raspberry Pi. It would be an amazing thing to behold, and would make learning so much more fun. day day.