I remember when I first saw SEGA's Virtua Racer in the arcades back in the early/mid 1990s. It was the first impressive true polygon-based racing game I played:
GBA programming was used in my school's class that covered (among other things) introductory C. It's really fun and pretty simple for beginners to write for bitmap mode.
That's exactly how I started programming! It was indeed a lot of fun. I remember being blown away the first time I saw a game/demo I wrote run on the real hardware. It was so rewarding.
It's nice to see teachers using GBA programming as an introduction. It's so much more fascinating for a beginner in comparison to a regular "Hello World" written in a terminal or a basic sorting algorithm in C.
This kind of thing is why I got interested in programming in the first place.
Pseudo-3D racing games in particular... as a kid, it was boggling to me how these simple 2D machines could produce a pretty convincing pseudo-3D racetrack! The Atari 2600 could hardly handle drawing the ghosts in Pac-Man; how could it draw a decent "3D" roadway?
Bizarrely, I lost interest in that kind of programming once machines got so powerful that drawing this kind of thing became easy...
> I lost interest in that kind of programming once machines got so powerful that drawing this kind of thing became easy.
Me, too. Once libraries and APIs become commonplace, programming became much more about connecting known working objects together rather than understanding multiple topics in depth.
Just before the internet took off, around 1998 or so, I spent months and months learning what every byte in .jpg, .gif, .mid and .wav files did. That really itched the scratching in my brain. I would love to find a new skill or hobby that affects me like that. Making pictures with ImageMagick just doesn't interest me... I'm actually finding woodworking to be somewhat as engrossing, but the difference is that in woodworking, you constantly see steady progress toward a goal, whereas in computers, a picture or sound would spring to life instantly once you'd cracked the code. You really felt the jump.
The actual answer to your question is that the Atari 2600's fundamental limitation is sprites per scanline, not per screen. It can draw lots of objects by reusing sprites across many scanlines, but can't draw many objects that need to move independently in vertical space.
So you can draw the "3D" racetracks by reusing two sprites all the way down the screen for the road boundaries, but you can't draw three Pac-man ghosts on the same scanline so you have to flicker between them on alternate frames.
That's the hard part(for me, and you apparently). That's why I think it's a good thing to have people with different personalities in a project. Some like to start and organize things, some like to finish things.
Ah, this brings back memories. Arcade racing games were my favorite as a kid. High poly models and realistic lighting in the living room will never be as exciting as speakers right behind your head, real steering wheel and pedals bolted to something heavy, and your friends talking shit from the multiplayer linked machines. Plus the background chaos sounds of all the other games in the arcade, token machines, people yelling...
Chase HQ, Cruis'n USA, Suzuka 8 Hours, and Daytona USA were my favorites. Daytona USA was true 3D and lacked the pseudo 3D charm, but carried on their arcade spirit. Its 8 player form was about as good as it gets for a little kid in the arcade with friends. Putting down money for each game made it more meaningful. Kind of sad that kids today will never experience that thrill.
The most interesting thing to me was the bit about dedicated road hardware(!). That just sounds so awesome. I imagine someone inveting that or implementing it.
I used to have a ZX Spectrum clone and still remember liking Chase HQ racing game. This was late '80s, on a 3MHz, 48K machine and they had road barriers and tumbleweeds that you'd bump and they'd bounce off. It was a stupid detail but it really stuck with me as it being a fancy feature.
I was an avid Spectrum user and I remember this game very well, mostly because I could not get my hands on it in South Africa. Chase HQ was praised to high heavens when it was released on the ZX Spectrum. For a long time, this was THE game to get on the machine. That and Rainbow Islands.
Chase HQ was a great game on the ZX Spectrum. I got an original 48k release copy when it came out so that I could crack the loader for school and drop pokes in. After seeing your comment I thought I'd have a look in an emulator and see how long it'd take me to walk through the loader with modern tools.
The original release uses Paul Owen's protection system, which is really just a headerless loader and some playing around with system variables. If you want a bit of lunchtime fun, go and get an emulator with a debugger, get the original from WoS[1] and switch off all the tape loader acceleration. Type LOAD "" (Usually J, alt-p, alt-p on a modern keyboard) and press return, then make sure you're playing the tape.
If you load it you'll get an initial basic loader, then a screeching red and black striped loader which sets up the initial load.
The loader uses the IX and DE registers to specify where to load the next block of data and how much data to load respectively. The initial bit of data loads in at 0x8200 and is 0x0200 long.
If you break in your debugger after that initial high pitched red and black bit you should be able to see that the IX register will point to 0x4000 and DE will point to 0x1800, 0x4000 is the start of screen memory, which is 6144 bytes (or 0x1800) long.
After the screen loads you'll see the next block (at 0x5B00, 0x4A80 long) - this overwrites the system variables and lower parts of memory. As this is in contended memory it runs more slowly than the rest, this should be used to store the main system code that makes sure everything's ticking along with some of the code to handle bits between the levels and the text used in the game. It's been nearly 25 years since I've hacked ZX spectrum games on a regular basis so I could be wrong.
The following block loads into 0xC000 (IX) and is 0x3F00 (DE) bytes long, which if memory serves is the main in-game code and some game assets but again it's been a long time and I might be wrong. I'd expect music to be up here too and any time sensitive code such as the code handling the countdown timer for the game.
After this a small two byte header is loaded into 0x5BD5 which is used to load a small header. Another block overwrites system variables again at 0x5C00 and some of the earlier loaded game material then jumps to the main game code where it loops around FEFE jumping to the music player and keypress check starting at EF19.
If once you're in the game you want to have a fiddle, go to the redefine keys option and redefine the keys to be "SHOCKED" then press enter for the last key to enter test mode for the game. The 48k version is a multiload game which means each level is loaded from tape. I think the 128k version is similar but with music, but I never looked at the 128k version.
I would've been able to do a bit more with something like ZX32 (which is what I used to fiddle with) but I'm on a Mac and half the fuse debugging stuff doesn't work. Still, it's amazing what you can do with emulators these days compared to my multiface one. I would've killed for tools like this!
Wow man, you remember how to do all that. That stuff bring back so many fun memories.
I was younger at the time (13-14) but I got to play with assembly. Remember typing up my own assembly interpreter for fun.
You obviously got into it a lot deeper. I wonder how many kids turned to liking computers because of ZX Spectrum philosophy of dropping the user straight into a programming shell. Other game consoles drop you in some kind of greeting loader screen, so you never see a programming prompt.
I recapture some of the thrill of working closer to hardware, I got a Beaglebone Black. But could never quite get excited about it. I find it more interesting now to learn a new programming language or build a small game or hack on an open source project.
> I would've killed for tools like this!
Exactly. I remember doing POKEs and messing the game up then having to load everything again. Having an emulator and debugger would have been a lot more fun.
To be fair I don't remember the offsets or anything, I fired up an emulator and a debugger and had a look through the game again.
> I wonder how many kids turned to liking computers because of ZX Spectrum philosophy of dropping the user straight into a programming shell.
I think people only began to realise that being dropped into something that required you to know how to tell it what to do next at a lower level than we experience today once people stopped coming into contact with shells and programming interfaces.
> I remember doing POKEs and messing the game up
Usually it was fairly easy to find pokes but sometimes games would rewrite code over the address space that the poke's meant to be used. This was much more common in multiload games on the 48k spectrum. I remember doing an obscure game called braxx bluff and I just gave up on pokes because the different minigames all overwrote different parts of memory. Some of the later spectrum games would store compressed data in memory and decompress it in different places at different times. I remember one game where data would be executed as machine code, but I can't remember which one it was.
This page was a gold mine for me a couple years back. If it was a tape I would've worn it out with how many times I re-read it. Had lots of fun experimenting with different features. I've got a javascript version of one of them online:
http://www.elusivegames.com/games/rocketracers/rr.htm
A few years ago I used this tutorials to hack together a little raycaster is JS: http://jsfiddle.net/htyvrjaa/