Disassembling Supercross 3D

I've been playing a bit with my disassembler, mostly fixing bug... And I've been using Supercross 3D for testing. Looking at the source code I can understand why it runs so slow. Ok the Jaguar it's very slow at texture mapping but the code could be better.

For now I've seen the following things.

• The code it's about 117KB, 120,016 bytes to be precise and it's stored at the end of the cartridge.
• The game it's locked to a minimum of 4 vbls per frame for PAL systems and 5 vbls for NTSC ones, this means that it will run at maximum speed of 12,5fps and 12fps respectively.
• There are one block of DSP code, I suppose that it's the sound engine.
• There are eleven blocks of code for the GPU (maybe one or two more, I haven't finished the disassembly)
• One of the GPU blocks it's used just to set the Object Processor List Pointer, this one never it's loaded into the GPU internal RAM, it runs from ROM.
• There are about 20KB (21, 184bytes) of dead code or unused data, they are spread around the code and most of them end with a $4E75 (rts opcode) but they are never referenced or called.
• Short branches are almost never used.
• It waits for the bitter to be idle in several places, but IMO if you are using the 68000 you don't need to wait because it has lower priority (68000 < blitter), so if the blitter it's busy the 68000 will be stoped. The only advantage of not having a cache.
• There are some link/unlink opcodes, also some routines push values into the stack, jump somewhere, load the values from the stack to the registers and jump again to do the actual work. I think that some parts are written in C and others in assembler, and this kind of routines are used to jump from C to ASM.
• There are some parts of the game that depends if the system it's PAL or NTSC, but it reads the hardware register each time that it needs to instead of using a flag.
• The game runs in 8bits mode with colors in CrY format (not 100% sure).

And now some codes snippets. All of them are actual code (it's full of them).

move.w (a0),d0

addq.w #1,d0

move.w d0,a3

move.w a3,-(sp)

jsr l01e3e0e

At least it uses quick add, I think that this is used to increment the lap count and print it.

move.w #0,l01b72d8
move.w #0,l01b72da
move.w #0,l01b72dc
move.w #0,l01b72de
move.w #0,l01b72e0
...

What about using a data register and post-increment addressing?

move.l a1,-(sp)
move.l #l01ece80,d3
move.l d3,a1
jsr (a1)

Because jsr l01ece80 it's too easy.


By the way, I've found two bugs in my assembler when I was looking at the disassembled code to write this post.

Squeezing Part II

Let's start with the sound effects.

The game uses 23 sounds effects, let's have a look at them with Audacity.

• sample1.wav: 8,000 Hz 9,250 bytes 8 bits
• sample2.wav: 11,025 Hz 10,803 bytes 8 bits
• sample3.wav: 11,025 Hz 9,257 bytes 8 bits
• sample4.wav: 11,025 Hz 2,192 bytes 8 bits
• sample5.wav: 22,050 Hz 31,364 bytes 16bits
• sample6.wav: 11,025 Hz 7,834 bytes 8 bits
• sample7.wav: 11,025 Hz 6,807 bytes 8 bits
• sample8.wav: 11,025 Hz 4,442 bytes 8 bits
• sample9.wav: 11,025 Hz 7,436 bytes 8 bits
• sample10.wav: 11,025 Hz 4,535 bytes 8 bits
• sample11.wav: 11,025 Hz 6,834 bytes 8 bits
• sample12.wav: 22,050 Hz 14,040 bytes 8 bits
• sample13.wav: 11,025 Hz 6,925 bytes 8 bits
• sample14.wav: 11,025 Hz 17,407 bytes 8 bits
• sample15.wav: 11,025 Hz 1,922 bytes 8 bits
• sample16.wav: 11,025 Hz 5,409 bytes 8 bits
• sample17.wav: 11,025 Hz 3,288 bytes 8 bits
• sample18.wav: 8,000 Hz 14,460 bytes 8 bits
• sample19.wav: 22,050 Hz 20,748 bytes 8 bits
• sample20.wav: 11,025 Hz 20,876 bytes 8 bits
• sample21.wav: 11,025 Hz 15,898 bytes 8 bits
• sample22.wav: 22,050 Hz 14,444 bytes 8 bits
• sample23.wav: 11,050 Hz 16,110 bytes 16 bits

That's 252,269 bytes for the sounds effects.

As you can see, each sample has different resolution and frequency, this is quite common with home-brew games. I'll convert all of them to a 8bits 8,000Hz, signed sample. Maybe I can use a higher frequency if I've some free space to improve the sound quality. 

After conversion and packing the data I've 87,730 bytes, that's 34,7% of the original space or 65,3% space saved. If I need some extra space I'll use ADPCM encoding to reduce each sample to a 50% before compression.

Classic Kong Demo GPU version

I've recoded the sprite engine (part of it) into the GPU, I hope that it'll fix all the slowdowns.

Now it's time to fix that ugly clouds.

Download Classic Kong Demo GPU version

PD: Yes I've used the same image. XD

Classic Kong Demo

Demo version of the first level

I still have some issues to fix, also I need some feedback from NTSC users.

Download Classic Kong Demo

Squeezing Part I

Here I'm going to comment the development of a new Atari Jaguar game.  It's a project that I got in mind from a long time ago.

The game it's not original, it's a conversion from other platform, I have all the assets and the source code that needs to be rewritten because it's not C.

The biggest issue it's that the folder with the executable, graphics and sounds takes 10,7 MB, 10,559,675 bytes to be precise, remember that the all graphics asserts are packed.

The game must fit into a 4MB cartridge, without dropping any sound, music or graphics.

Classic Kong

Coming soon for the Atari Jaguar.

Ported from SNES version by Bubblezap.