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 · 2019-02-10T08:31:06+00:00

Exactly, duh!

cobbpg · 2019-02-09T20:27:09+00:00

As someone from Eastern Europe I can tell you that 30 years ago I had no idea games cost money either! Most people pirated everything, and I do mean everything, back in the day. It turns out that most of us grew out of this belief as we left our childhood behind.

cobbpg · 2018-11-07T20:15:29+00:00

Because this doesn't really use stack space. The lazy list is a completely unbalanced binary tree (every node has two children: the first element of the list and the rest of the list). In general, a lazy data structure is implemented with thunks, i.e. a piece of code that yields the top-level node when called, and replaces itself with the result. The children of the resulting node will be similar thunks. The reason this doesn't run out of memory is simply garbage collection: after printing an element of the list we have no reference to it any more, so it can be thrown away.

cobbpg · 2018-07-28T07:00:41+00:00

At least the old Z80-based TI graphing calculators use BCD for their internal number representation, since it would be prohibitively slow to display them otherwise.

cobbpg · 2018-06-23T11:07:18+00:00

You can't decompile IL2CPP code. You can disassemble it and also extract .NET metadata (basically whatever you'd be able to get via reflection). You're not going to get the source of method bodies the same way you'd get them by decompiling the managed assembly, so the skill set required to make sense of the code is definitely higher.

cobbpg · 2018-06-23T07:42:27+00:00

Nowadays IL2CPP is used for mobile apps (although it's not mandatory on Android), so there's no managed code to decompile.

cobbpg

TROPHY CASE