This is a bit of a love letter to Space Invaders, and video games in general.
I started working on this as a simple emulation project, to rekindle my own passion in low level video game hacking, but then realized with a bit of care I could take it further.
So, this is not a simple clone of the game, but rather a painstaking recreation of the source code in clean, readable C code.
I wanted to make something nice that would last a while, as a tribute to the original, and hopefully function a bit like a rosetta stone for future audiences.
Looking through your code, the text character set seems to be coming from the original ROM image. Is that correct? What I thought was interesting was that the glyphs appear 100% identical to the original Apple II character set, down to the pixel. Was there some kind of unexplored connection between Space Invaders and Apple, back in the day?
I have to ask an honest question (as someone who is interested in emulation and old-game restoration as a whole): why C? Did you consider a newer hacker-news-friendly language like D or Rust?
(my usual disclaimer: I'm not asking this passive aggressively, I'm genuinely interested in the answer to this).
I'm obviously not the author, but I can think of a good reason not to use rust.
The project works exactly as the original and recreates the memory state byte for byte, so like the original it has different tasks running at once that are reading and writing to shared memory. Rust's borrow check exists to prevent this sort of thing, because it is so hard to do it correctly or prove it is correct once you have done it. So to use rust, the author would have needed to either totally re-architect Space Invaders, or write the whole thing in ugly, non-idiomatic rust.
Rust simply doesn't let you do the things assembly and C programmers did all the time in 1978 (and with the complexity of our software now and the extra computing power, that's usually for the better). C, on the other hand, has at times been described as "portable assembly," which makes it a good choice for someone wanting to stay true to the original program flow.
I'm a hacker-news reader and I use C on a daily basis. Seems pretty friendly to me.
Every language has a problem that it is good at solving, and some languages express the underlying idea more clearly than others. In this case, the author has done a bang-up job picking a common, everyday language to solve the problem.
Story time: I wrote an 8080 emulator to play the Space Invaders. I implemented just enough instructions so I could play the game. Problem was, the game's title screen would show, but after a few seconds, it would immediately jump back to the beginning.
First I thought "oh I must have implemented an instruction wrong". So I re-checked all the instructions, read through the Intel 8080 programming manual multiple times. I did find a few errors related to the carry flag, but fixing them didn't change anything.
I then started to actually debug the game code. This was significantly harder than I'd expected. Since the game was in assembly, it was not obvious what each instruction did. What I had to do was pretty much annotate each and every instruction, along with all the memory locations. E.g. address 0xABCD is for player score, 0xCDEF is for player position, instruction X is for drawing the bunker, etc.
It was truly a pain, but it paid off. So the game had an interrupt handler registered to the display refresh signal. And I finally realized the game was constantly interrupted when it was not supposed to. Turns out I had forgotten to disable the signal when entering the handler.
> In the early eighties you would have found the Space Invaders cabinet in an arcade right next to the pinball machines. So a "tilt" switch, like you would find in a pinball machine, would not have seemed as strange as it does today. If you shake, slap, or otherwise physically abuse an SI cabinet you will get a TILT message and your game will end.
Interesting! With pinball machines, that was to prevent cheating, since you could change the course of the ball by smacking the cabinet. (Some players consider doing this without triggering the tilt sensor a legitimate part of the game.) Hilariously, Video Pinball on the Atari 2600 supported it specifically: holding the button while you move the joystick nudges the ball around, but if you do it too much you get a TILT message and can't score any more points until you lose the ball.
It seems like a weird sort of reflex action to put a tilt sensor in a video game, though. Maybe they were just worried about frustrated players damaging the equipment?
Space Cadet on the old versions of Windows supported bumping, too. You could avoid tilt by alternating which side you bumped. Two in a row from the same side would tilt, but alternating sides never did (for me).
Interesting metrics, you'd expect C to do a lot better in the line-count department than assembly.
I tried building it on Ubuntu, if you follow the instructions the SDL library include files will end up in a directory called SDL so you have to include SDL/SDL.h and even then the build fails with lots of SDL related definitions missing (SDL_Window for instance).
After downloading you'll have to rename the files because the names will all be uppercase:
cd inv1
mv INVADERS.E invaders.e
mv INVADERS.F invaders.f
mv INVADERS.G invaders.g
mv INVADERS.H invaders.h
cd ..
Now the game should work:
./bin/si78c
Some minor nitpicks about the code:
- bracket your ifs and place the starting { on the same line as if/while, or one day you'll sit there staring at the screen for 8 hours trying to figure out why your code no longer works due to an accidentally deleted line.
So:
while (num < 64)
{
int has = SDL_PollEvent(&event_buffer[num]);
if (!has) break;
num++;
}
becomes:
while (num < 64) {
if (SDL_PollEvent(&event_buffer[num])) {
break;
}
num++;
}
> bracket your ifs and place the starting { on the same line as if/while, or one day you'll sit there staring at the screen for 8 hours trying to figure out why your code no longer works due to an accidentally deleted line.
This is some rather strange advice. That and the rewrite dropped a '!'.
That's advice borne from a lifetime of programming C. Good catch about the !, but that was just as an example of the form, not meant as a cut-and-paste replacement.
Well, if you want to go all K&R you can just put the whole thing in a single while line, without the extra conditional inside. Single for line, if you're going for a more 'asshole C expert' style. If you're on your 200th hour trying to capture the flavour of the original 8085 assembly, you might end up writing something like what's in the code.
you'd expect C to do a lot better in the line-count department
You would but it's worth keeping in mind this implementation is constrained by closely following the structure and logic of the original. It's like writing C but being told exactly what state you have to maintain (and where), down to the bit, in advance. It really is a 'hardware simulator' where the spec and input handed to you is the sequence of memory states (and a few other bits) of the original machine.
Good show dragging bracing style into the discussion. Nevermind that it is one of the oldest and least important battlegrounds in the history of programming, at least you got to be needlessly pedantic.
That's where I assumed the comment was going as well, but it's actually not really about brace style at all. Rather it's about "if style" which is a much more interesting discussion (at least as applied to C error checking).
That's not a charitable reading of my comment, it actually does have practical impact and is not just about style but all about function. I could not care less about the looks but found out the hard way that separating the { from if and while constructs can bite you really hard.
Thanks for pulling the code and trying it out, jacquesm!
That kind of feedback is gold.
I have updated the README with the correct Ubuntu package details.
I think the issue with the includes is likely to do with having both SDL1 and 2 installed, and the slightly dirty way I am pulling in the header (so it works on Mac too).
I will have a bit of a think about how best to resolve that issue, likely needs some ifdefing.
If you like this kind of thing, there's also a faithful re-implementation of the original Elite game, with (readable) source code.
Quoting Wikipedia:
"... around 1999 Christian Pinder developed Elite: The New Kind as a modern PC port of the original BBC Micro version. He achieved a faithful port by reverse-engineering the original assembly written BBC Micro version and recreating a platform neutral C code variant from it, but at David Braben's request this version was withdrawn from distribution in 2003. In September 2014, on Elite's 30th birthday, Ian Bell blessed Elite: The New Kind and re-released it for free on his website. Since then, Elite: The New Kind is also distributed again in version 1.1 by Christian Pinder; a source code mirror is hosted on GitHub."
There's a crash bug in the source: when the local star is to be rendered, the game crashes because it tried to explode the star. There are a couple of forks that solve that rather glaring issue, however I don't recall if they're in a playable state themselves.
The white invaders on a black background was iconic in my childhood, so I was kind of blown away when I first saw a real arcade machine with the painted backdrop and the screen reflected over it with a half silvered mirror (or whatever crazy tech they used in those days).
Thank you for posting this! Me too! I was at a local arcade and came across a real/original spaceinvader cabinet and I was floored at how much of the experience is not captured by an emulator on a laptop. The silvered screen layer is very eye catching and the sound - so much bass really adds to the experience of the dropping invaders.
Readit News
This is a bit of a love letter to Space Invaders, and video games in general.
I started working on this as a simple emulation project, to rekindle my own passion in low level video game hacking, but then realized with a bit of care I could take it further.
So, this is not a simple clone of the game, but rather a painstaking recreation of the source code in clean, readable C code.
I wanted to make something nice that would last a while, as a tribute to the original, and hopefully function a bit like a rosetta stone for future audiences.
Enjoy.
Well spotted, it looks like you are right. A quick glance here https://computerarcheology.com/Arcade/SpaceInvaders/Code.htm...
and here
https://www.fontzip.com/apple-ii-screen-typeface
Shows a distinct similarity.
(my usual disclaimer: I'm not asking this passive aggressively, I'm genuinely interested in the answer to this).
The project works exactly as the original and recreates the memory state byte for byte, so like the original it has different tasks running at once that are reading and writing to shared memory. Rust's borrow check exists to prevent this sort of thing, because it is so hard to do it correctly or prove it is correct once you have done it. So to use rust, the author would have needed to either totally re-architect Space Invaders, or write the whole thing in ugly, non-idiomatic rust.
Rust simply doesn't let you do the things assembly and C programmers did all the time in 1978 (and with the complexity of our software now and the extra computing power, that's usually for the better). C, on the other hand, has at times been described as "portable assembly," which makes it a good choice for someone wanting to stay true to the original program flow.
Every language has a problem that it is good at solving, and some languages express the underlying idea more clearly than others. In this case, the author has done a bang-up job picking a common, everyday language to solve the problem.
Dead Comment
First I thought "oh I must have implemented an instruction wrong". So I re-checked all the instructions, read through the Intel 8080 programming manual multiple times. I did find a few errors related to the carry flag, but fixing them didn't change anything.
I then started to actually debug the game code. This was significantly harder than I'd expected. Since the game was in assembly, it was not obvious what each instruction did. What I had to do was pretty much annotate each and every instruction, along with all the memory locations. E.g. address 0xABCD is for player score, 0xCDEF is for player position, instruction X is for drawing the bunker, etc.
It was truly a pain, but it paid off. So the game had an interrupt handler registered to the display refresh signal. And I finally realized the game was constantly interrupted when it was not supposed to. Turns out I had forgotten to disable the signal when entering the handler.
I fixed it, and it ran perfectly.
> In the early eighties you would have found the Space Invaders cabinet in an arcade right next to the pinball machines. So a "tilt" switch, like you would find in a pinball machine, would not have seemed as strange as it does today. If you shake, slap, or otherwise physically abuse an SI cabinet you will get a TILT message and your game will end.
It seems like a weird sort of reflex action to put a tilt sensor in a video game, though. Maybe they were just worried about frustrated players damaging the equipment?
Those tilt sensitivity is common in computer games, although in some computer pinball games there is no penalty for bumping the table too much.
(Of course, Space Invaders is not a pinball game and so physically attacking it is not legitimate.)
I tried building it on Ubuntu, if you follow the instructions the SDL library include files will end up in a directory called SDL so you have to include SDL/SDL.h and even then the build fails with lots of SDL related definitions missing (SDL_Window for instance).
That's because you really should be doing
Then change the include file line to and type: The roms can be found here:http://www.freevintagegames.com/MAME/invaders.php
After downloading you'll have to rename the files because the names will all be uppercase:
Now the game should work: Some minor nitpicks about the code:- bracket your ifs and place the starting { on the same line as if/while, or one day you'll sit there staring at the screen for 8 hours trying to figure out why your code no longer works due to an accidentally deleted line.
So:
becomes: Neat project!This is some rather strange advice. That and the rewrite dropped a '!'.
You would but it's worth keeping in mind this implementation is constrained by closely following the structure and logic of the original. It's like writing C but being told exactly what state you have to maintain (and where), down to the bit, in advance. It really is a 'hardware simulator' where the spec and input handed to you is the sequence of memory states (and a few other bits) of the original machine.
The C version also loses a few lines here and there for function prototypes and structured control flow.
Handwritten 8085 can be quite compact in some places due to sharing code fragments. It's a bit like self ROP.
Particularly handy in the Visual Studio debugger when working with C#.
That kind of feedback is gold.
I have updated the README with the correct Ubuntu package details.
I think the issue with the includes is likely to do with having both SDL1 and 2 installed, and the slightly dirty way I am pulling in the header (so it works on Mac too).
I will have a bit of a think about how best to resolve that issue, likely needs some ifdefing.
Not necessarily if the C code is trying to reproduce, in detail, all of the externally visible effects of the original assembly language.
Quoting Wikipedia:
"... around 1999 Christian Pinder developed Elite: The New Kind as a modern PC port of the original BBC Micro version. He achieved a faithful port by reverse-engineering the original assembly written BBC Micro version and recreating a platform neutral C code variant from it, but at David Braben's request this version was withdrawn from distribution in 2003. In September 2014, on Elite's 30th birthday, Ian Bell blessed Elite: The New Kind and re-released it for free on his website. Since then, Elite: The New Kind is also distributed again in version 1.1 by Christian Pinder; a source code mirror is hosted on GitHub."
Link: https://github.com/fesh0r/newkind
How hard would it be to port the sound as well?
si78c is faithfully sending all the right bits to the right port, but the hardware component would have to be emulated to get it going.
The relevant code could most likely be borrowed from MAME.
https://github.com/mamedev/mame/blob/master/src/devices/soun...
Emulates the TI SN76477 sound chip.