Racing in 2.5D

I had been wanting to do something like this for a while. I was getting the itch to create a 2.5D racing game and, at the same time, experiment with using AI for programming.

In fact, I saw it as a way to experiment and learn how to use these new AI tools that I had already tested a bit, but not as a full "project." Before continuing, I want to clarify how I am (and how I wanted to) use these types of assistants. Perhaps you've seen some of those videos where someone who doesn't know how to program claims to have made a game with just a few prompts, simply by saying what they want. That's not what this is about. It was about having a kind of assistant and not losing control of the code. To be clear, this is not a game programmed by an AI, it's a game programmed with the help of AI. But I won't go into much more detail on this topic for now; maybe I'll take some time to write another article with details about that later.

The goal was also to make this work on my Amiga 1200, albeit using a PiStorm with a Raspberry Pi 3 that acts as a 68k CPU, giving this old machine much more power than the original and RTG graphics.

But above all, the idea was to have fun. That's why I wasn't going to use purely Amiga development languages or tools, nor was I going to dive into dealing with its Custom Chips. I would do it in SDL1.2, using a Linux machine with which I could run it natively or cross-compile to 68k and launch it in an emulator or on the real machine.

Part of the fun, as I said, was using an AI plugin in the IDE to help me writing the code, but this fun should mainly come from not complicating my life. I wasn't going to worry about performance issues since the PiStorm would be more than capable of running the program made in SDL...

Nonsense! As soon as I started introducing objects into the scene, the performance began to drop, and I found myself implementing things like "dirty rectangles" and rethinking the code to see what other tricks I could use. By the way, the recommendation to use "dirty rectangles" also came from an AI, but that's another story. In short, I thought SDL would be less demanding for a PiStorm, and I was wrong.

The result is what you can see in the video. It's a technical demo where you can only drive the car along a (fictional) circuit. There's no collision detection, but the 2.5D graphics engine is sufficiently advanced. There are also no rivals (NPCs), and therefore the logic to make them move on screen doesn't exist yet. As for performance, on a Linux machine it runs blazingly fast, and on the PiStorm, as you can see in the video, at 800x600 the FPS is just over 30.

Inspiration

Of course, it's a 2.5D racing game in the style of Out Run, but perhaps closer to other titles like Nigel Mansell or Vroom, because it tries to approach a simulation style, with an engine that responds to the characteristics of a real car and includes gear shifting, etc. However, there's one feature that I think makes it different from the vast majority of existing games: it won't have obstacles to collide with at the edge of the road. The driving experience should be fun and relatively easy. The difficulty will come from the times you need to achieve or from the rivals on the road. Going off-track will have its consequences, of course, but it will normally just be a loss of speed.

Motivation

Apart from what I mentioned about having fun, I would like this to serve as an example to demonstrate that it's possible to make specific and new things for the PiStorm. If not, what are we using it for? I say this with respect for those who release something for the original machine (ECS, AGA) or those who port something existing (whether it's something for classic Amiga or something that tests the power of this accelerator). In other words, the intention was to create something new (and hopefully attractive) that would push the limits of the PiStorm's capabilities.

Will this become a game?

It depends. Mainly, for that to happen, it should run smoothly at a reasonable resolution for an Amiga. For me, that means maintaining those 30FPS at a resolution of 640x480, and there's still the logic of rivals to implement, drawing them on screen, and adding collision detection.

Requirements

Amiga

• PiStorm with RPI3
• RTG Graphics
• Plenty of RAM. Currently, it consumes about 250MB, and it's just a prototype.

Linux

• Works well on a Dell laptop that's over 10 years old, easily exceeding 60FPS (I haven't even calculated the exact FPS it reaches)

Features

2.5D Graphics Engine

All the initial work is based on Jake Gordon's Tutorial  and also on what is covered in Lou's pseudo 3D page.

Road Rendering

• Implements a segment system to represent the road in perspective, where each segment has start and end points with 3D coordinates that are projected to 2D.
• Uses the perspective projection technique to create the illusion of depth.
• The road is drawn segment by segment from the farthest to the nearest, creating the depth effect.
• Parallax system that implements backgrounds that move independently to create a sense of movement.
• Uses the "dirty rectangles" technique to optimize rendering, updating only the areas of the screen that have changed.
• Implements an occlusion system to avoid rendering sprites that are hidden by other elements.
• The Amiga version replaces the sky texture (background) with a "copper sky" to save CPU time.

Vehicle Physics and Control

• Implements a realistic physical model with variables such as:
  • Acceleration, braking, maximum speed
  • Centrifugal forces in curves
  • Terrain effects (on/off track)
  • Manual and automatic transmission
  • Engine RPM calculation based on speed and current gear
  • Sound effects for gear changes

Loading Circuits from JSON

• Circuits are defined in JSON files (sierra.json).
  • Road segments with curves and elevations
  • Objects and decorations along the circuit

Sprite System

• Implements a cache system for scaled sprites, improving performance.
• Sprites are scaled according to distance to create a depth effect.
• Supports composite sprites for complex objects.
• Uses a sprite registry to avoid loading duplicate textures.

Configuration and Other Available Options

• The game loads configurations from external files to adjust:
  • Screen resolution
  • Fullscreen / OS window
  • Drawing distance
• Implements controls for both keyboard and joystick.