Lou's Pseudo 3d Page
extentofthejam.com
extentofthejam.com
A few years ago I used this tutorials to hack together a little raycaster is JS: http://jsfiddle.net/htyvrjaa/
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:
https://www.youtube.com/watch?v=G3PcHBFsjxg
The other polygon-based racing game that was impressive, but it hard pretty horrible controls and not as beautiful, was Hard Drivin':
https://www.youtube.com/watch?v=g6JC-HCNcio
The cool thing about Hard Drivin' is you could go anywhere and do anything, where as with Virtua Racing you had to follow the track.
Surprising.
Personally I love this kind of old-school programming article. It reminds me when I was developing homebrew games for the GBA!
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...
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.
Oh well.
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.
It's much much much much more simpler (since it's top down)
https://gist.github.com/seivan/b8f50a8505675b61be22
It depends on layers centered on top of each other. Requires special art work.
Here's some videos:
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.
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.
Here is someone playing it:
http://en.wikipedia.org/wiki/Chase_H.Q.#Ports_and_related_re...
I still have this copy of SU laying around somewhere where they reviewed the game:
http://www.worldofspectrum.org/showmag.cgi?mag=SinclairUser/...
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!
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.
> 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.
It is indeed very fast.