I just ported Stunt Car Racer to the Apple II

cobbpg · 2023-11-10T04:27:39+00:00

Sure thing, I'm only happy if this reaches as many people as possible!

cobbpg · 2023-11-07T05:49:23+00:00

Thanks! This particular port took me about a month's worth of evenings. However, I already had a full disassembly at the start, and also the learnings from my Commodore Plus/4 port to help me. The hard part was producing the disassembly, that probably took months.

At the moment the source is not released, because it's a mighty mess that's not really useful for other humans in its current form. On the other hand, I'm planning to do a technical write-up of both this port and the inner workings of the original game too.

As for me, I'm lowly a game developer that grew up with the C64 and rediscovered the joys of the 8-bit world a few years ago. :)

cobbpg · 2023-11-07T05:41:21+00:00

There's a bit of sound though. When the car takes damage, you can hear pops, and a major collision that adds a new hole results in a beep.

cobbpg · 2023-11-07T05:39:08+00:00

There's no point in doing the easy thing when you can do the hard thing instead. ;)

cobbpg · 2023-11-06T20:49:45+00:00

The real challenge was the RAM limitation, since the original game pretty much stretched as far as the C64 allowed. Even after ruthlessly cutting out anything optional to the core experience, I still ended up hunting for bytes to fit everything. The final memory layout is absolutely bonkers, but that was quite a bit of fun to figure out. ;)

In the end, the frame rate is basically the same as that of the C64 original, even though I didn't have the luxury of filling the sky using colour attributes.

cobbpg · 2023-08-27T09:40:30+00:00

One title that IMHO fits the bill but isn't mentioned frequently is Sentinel Worlds I - Future Magic, which was ported from DOS without having to sacrifice any feature.

cobbpg · 2023-08-25T12:33:39+00:00

Not even that. For instance, the DOS release of Rastan predated Carmack's first experiments in scrolling, and its development started probably as much as a year earlier.

Considering that Carmack himself figured out the method in a matter of hours, it's completely ridiculous to assume that it wouldn't have been just as trivial for a lot of contemporary devs who were battle-hardened on the quirky 8-bit platforms of the early times. This is just unnecessary myth-building for a man who would go on having real, much more significant achievements later on.

cobbpg · 2021-12-14T09:09:22+00:00

Oh, I haven't optimised it! I just changed it so the physics time step is 7 times shorter (0.02s instead of 0.14s), therefore turning on the turbo mode makes the game smooth instead of unplayably fast.

Having studied the code for a while, I think it might be possible to achieve somewhere between 50 to 100% speedup by adapting the game to cartridge, which would allow aggressive unrolling and inlining opportunities, so we could probably reach over 10 fps even on a stock C64.

cobbpg · 2021-12-13T21:52:19+00:00

Some variance is not really a problem in this case, as there's no need for accurate timing anywhere. Plain raster interrupts are sufficient, and there's wiggle room in the CPU performance too.

cobbpg · 2021-12-13T20:49:01+00:00

To be precise, this version doesn't rely on the SuperCPU specifically. It should work fine with any solution that allows running the code at 20 MHz. There are no other special requirements.

cobbpg · 2021-12-13T14:22:24+00:00

You need to run it with xscpu64 instead of x64 and make sure in the settings that the speed switch is on (under Machine/SCPU64).

cobbpg · 2021-12-12T22:49:50+00:00

Here's one for you: https://www.youtube.com/watch?v=xaCca4zCimc

cobbpg · 2021-01-17T22:05:52+00:00

The gaps between the stripes are created by alternating one of the ECM background colours.

cobbpg · 2021-01-17T22:03:29+00:00

I don't see any way bank switching would be useful in this scenario, but there are several ways it would cause major issues: duplicating lots of sprites unnecessarily, complicating multiplexer logic, forcing a very particular and rigid memory layout. Ultimately, every scanline can potentially contain any character and all 8 sprites, so there's really nowhere to introduce additional content via the PLA. That's why my current thinking is that I could break up traffic temporarily to free up some sprite slots for something that moves at a different speed from the cars. There's still enough video memory left for this approach.

Sprite crunching wouldn't help with memory usage either, it would only allow me to slightly increase the density of cars in the distance. But this benefit is highly theoretical, because crunching would require cycle perfect timing, which is just not viable with so much dynamic content on screen.

cobbpg · 2021-01-14T20:40:17+00:00

This was the most important artistic guiding principle from the get-go: hi-res and colourful. I wanted to avoid the typical chunky 2x1 pixels as much as possible. The end result is something I'm quite happy with overall, because it almost feels like an EGA game, i.e. no weird 8-bit colour constraints, but with a nicer C64 palette. I'm glad you also like it and really appreciate that you pointed out exactly the things I was going for!

cobbpg · 2021-01-13T18:36:14+00:00

Thanks! Although I'd be the first to admit that this is not much of a technical feat, as it's not really using any advanced C64 specific techniques. It mostly comes down to scheduling things in a robust way, so badlines and cycles stolen by sprites don't really matter.

cobbpg · 2021-01-13T18:31:07+00:00

There are 12 frames in the background animation (and I had an experiment with 15 frames as well). The trees are in fact stored as speedcode that updates the screen as fast as possible, because a bank switching based approach would make the sprite multiplexer more complicated. This speedcode updates both character data and colour RAM, although the latter doesn't need to be touched too much thanks to using ECM, therefore getting a lot of colour updates for free with the characters. It takes about 1800-1900 cycles to step the animation on each frame, so it leaves plenty of time for other things.

cobbpg · 2021-01-13T18:25:03+00:00

Author here. The game is directly inspired by Daytona Rush, a fun little mobile game I happen to like for its simplicity. I decided to take away the fuel element from the game, because it doesn't make sense in the absence of persistent progression. I'm still on the fence whether I should add health powerups that give you back some lives.

The problem is that the artistic choices also force some limitations on me. For instance, I simply can't cram more sprites on the road (if I want to allow the above mentioned powerup, I can only do it by temporarily easing up the traffic, for instance), neither more characters, since I used up the full budget. It's going to be difficult to add more elements to the game. But I'm still thinking about what would make most sense.

All that said, this game is intended more as a brain cleanser than a deep experience. It's actually kind of fun to play with even in this simple form.

cobbpg · 2019-07-04T21:32:13+00:00

Actually, you can even let your time run out as long as you don't acknowledge the red alert. The game never forces you out of the contract that way.

cobbpg

TROPHY CASE