Skies of Arcadia Eternal

One frame of black

2026-10-11T00:00:00Z

You know the moment. A battle is about to start, and the screen cracks and falls away in pieces before the fight fades in. On the PC port, the night after the Blackbeard battle started working, Endymion was on his way to Valua and saw something just before that shatter. It was too quick to screenshot: the screen went black with a bit of white, and then the pieces fell as usual.

At 60 frames a second, “too quick to screenshot” means one or two frames. So the first thing I did was stop trying to see it and start counting.

Every frame, twice

The port can replay a recorded controller session exactly and save chosen frames as images. I already had a recording that sails into the Blackbeard battle from Endymion’s save, so I captured every frame from 6,555 to 6,600 in the port. Then I played the same recording in Dolphin, the GameCube emulator, and captured the same stretch there.

The port had it at frame 6,571: black over the top half, a white block over most of the bottom. The very next frame showed the first cracks. Dolphin never drew that frame. Every frame it drew there shows the cabin, with Drachma, Vyse and Aika, until the cracks appear.

Port, frame 6,571

Dolphin, the same moment

The frame Endymion saw. Left: the port, the frame before the shatter starts. Right: Dolphin from the same save and the same button presses. The port starts the shatter one frame earlier than Dolphin, so Dolphin’s matching frame is numbered 6,572.

The wrong scene, then the wrong card

The game has a whole module for screen transitions: wipes, a wave, a fade. I guessed the flash came from there and set breakpoints in a debugger on every function in it. None of them ran. The shatter is drawn somewhere else.

So I counted graphics calls instead, frame by frame, to find what was different about 6,571. The counts were identical on every frame, which made no sense, until I saved the frames the debugger run was drawing. They showed the save menu. While I was busy, Endymion had been playing, and he had saved in Valua. My replay copies his memory card at the start, and his new saves had pushed the old one down the list, so the recording’s button presses now chose a different file. With a copy of the card the recording was made from, the debugger run reached the cabin again.

What the game does on that frame

This time frame 6,571 had one call the others didn’t. To break the screen into pieces, the shatter needs a picture of the screen. When the game notices that a battle has started, it copies the finished frame into a texture for the shatter, and it clears the screen as it copies. Nothing draws over the screen after that, apart from a fade layer that is almost completely transparent.

The port shows the screen as it stands when each frame ends, so it showed the cleared screen. The white block is probably left by a step the port uses for copies smaller than their texture, which runs after the clear. I didn’t trace that part further. Dolphin shows the cabin.

I don’t know for sure why Dolphin skips the cleared screen. As far as I can read the game’s code, the console clears it too. So for this one frame I followed Dolphin, because it’s what this project checks every frame against. The battle start now takes its copy without the clear. The shatter draws its own black background from the next frame on, so nothing needed the clear. I tried a smaller change first: clearing only the depth and leaving the colours alone. It still flashed. Only a copy with no clear at all fixed it.

Port, frame 6,571, fixed

Dolphin

The same frame after the fix, beside Dolphin’s.

Random battles in the field start through the same code, so they probably flashed too.

Still not quite right

With the two programs side by side, one more difference showed up. Dolphin breaks the picture into triangles. The port breaks it into squares, with faint grid lines before anything falls. That one is next.

Port

Dolphin

A moment into the shatter, a frame apart. The port’s pieces are squares; Dolphin’s are triangles.

Three bugs and a button: the Blackbeard, seen from the wrong places

2026-10-09T00:00:00Z

If you’ve played Skies of Arcadia, you remember the Blackbeard: Baltor’s ship, the first ship battle, and Drachma explaining what that “C!” at the top of the grid means. On the PC port it was where things got strange. Endymion played up to it and, as he put it, the glitches were “a sort of unintended peek behind the scenes”: the camera “frequently rendering from inside one of the ships”, the command menus showing sky and a floating island with no ships in sight, and, after the fight, a world map frozen on the view from underneath Little Jack.

Those looked like one camera problem. They turned out to be two unrelated bugs, a third that had crashed the battle earlier, and one button press that wasn’t a bug at all.

Making the battle last

The first thing I changed was how the battle was tested. The port’s --easy-battles cheat holds the enemy at 1 HP, so the first volley sinks the Blackbeard, which is great for getting past it and useless for testing it. I added a narrower cheat that keeps only the party’s HP and spirit full, so the fight runs its whole length.

It crashed on the S-Cannon turn. The effect number the game looked up was 1,546,321,920. Written in hex that’s 0x5C2B0000, and with its bytes reversed it’s 11,100: a perfectly sensible effect number, still in the GameCube’s byte order. (The GameCube stores numbers big end first; a PC reads them little end first, so the port swaps every number in the game’s data as it loads. Anything it doesn’t know is a number stays reversed.) Those 73 effect records are only ever reached through tables of pointers, so nothing in the decompiled code names them, and the loader never knew to swap them. Describing their layout fixed it.

The camera inside the ship

The battle’s camera isn’t a follow camera. It’s a recorded camera path, a “camera motion” stored in the battle’s model file in Sega’s Ninja format, the same family of formats the Dreamcast version used. The port converts Ninja models, textures and character motions to the PC’s byte order as it loads them, and warns about any chunk it doesn’t recognise. Camera motions were one of those.

So the camera motion’s length, 500 frames, read as about four billion. Every time the game asked “where is the camera at frame N?”, N was a tiny fraction of the motion, the lookup landed on its last key, and the eye ended up wherever that key sat, which was inside a hull. Converting the chunk put the camera back on its path.

Where did Little Jack go?

To check the fix I didn’t trust my eyes; I ran the same memory card and the same button presses in Dolphin, the GameCube emulator, and in the port, and compared the frames. The camera now matched exactly. The menu didn’t: Dolphin showed Little Jack small in front of the island, and the port showed the island alone.

Port, before the fix

Dolphin

The same moment of the battle from the same memory card and the same button presses. Drag the handle: Little Jack is missing from the port’s frame.

The ship’s position told the story. In Dolphin, Little Jack started the battle at (150, 25, 0). In the port it was at (300, 50, 0): exactly twice as far out, and just out of frame.

The game doesn’t move ships in a battle directly. It bakes each ship’s path ahead of time into a table of samples, one per frame, plus 120 extrapolated samples before the start and after the end so the ship never runs off the table. I logged the samples as they were made: 150, 25. Right. So I set a hardware watchpoint (the debugger stops the moment a chosen piece of memory changes) on the table’s first sample. It was written twice in one go: 150, then 300.

The second write was the padding step. Asked to pad a path with zero samples, it extrapolates from the first sample toward the second, which was never written and so still zero, and lands at twice the first. Then it copies that over the start.

Why zero samples? The path’s length comes from a list of route entries, 88-byte records of plain numbers. The decompiled code described two of those numbers as pointers. On the GameCube a pointer is 4 bytes, so that’s harmless; on a 64-bit PC a pointer is 8 bytes, which pushed the length 4 bytes later in the record (onto a word that holds 0) and stretched every record to 104 bytes. Describing them as numbers again put Little Jack back where Dolphin has it.

Port, after the fix

Dolphin

The same comparison once the route entries were read as numbers again.

How two declared pointers moved the length field.

The world map that wasn’t stuck

That left the world map after the battle, staring up at Little Jack’s keel. I logged the camera every 50 frames and watched its view number change from the chase view to the view from below, between two samples where nothing else happened.

Except something did. The world map camera has preset views on the D-pad, and my replay file, written to click through the results screens, kept pressing Down after the map came back. Two presses of Up and the camera was back above the ship. The game was doing exactly what it was told.

Down: the view from below

Two presses of Up later

The “stuck” world map camera, and the same camera after two presses of Up. Both frames are from the port.

So: two byte-order bugs, one 64-bit pointer bug, and one button. The battle now plays from the first shot to Baltor’s retreat, and its opening frames match the GameCube’s.

Contact sheet of a replay run

A contact sheet from one of the replay runs of the battle, from the opening cutscene to the cannon exchanges.

The wall that was a storm

2026-10-07T00:00:00Z

If you’ve sailed the Little Jack out of Pirate Isle, you know the view. The ship in the middle, islands drifting past, and at the edges of the sky, pale translucent walls of cloud closing off the parts of the map you can’t reach yet. On the PC port those walls were simply gone. Open sky everywhere, and no error to say why.

They’re back now. Finding them took two wrong guesses, a trick to make the invisible visible, and a pair of lights that sit just behind your head the whole time you sail.

First, a faster way to get there

Every test of the world map meant replaying the opening: the pirate attack, Antonio, Dyne’s sailing lesson. Under the port’s fast mode that is still several minutes a try. Endymion asked the obvious question: why not save once on the world map and load that?

The game has its own save option there. Press Z and a little menu offers Map, To Bridge and Save. On the port, pressing Z crashed the game. The menu’s buttons are sprite records that point at their textures with 32-bit GameCube addresses, and the port’s copy of them had been rebuilt with 64-bit PC pointers, so the drawing code read half of one. Once that was fixed, the buttons drew as solid black boxes. Their parchment lives in a texture shared with something else entirely: the left half is where the game photographs the screen (the frame the battle-intro swirl twists up), and the right half holds menu art. The port had been wiping everything outside the photograph. With both fixed, the game’s own Save wrote a memory card, and Continue loaded straight onto the world map in about 23 seconds.

Wrong guess one: the wall that says “wall”

The world map’s objects are run by little scripts with names. One of them is fldAsterWall. Six of them sit in this scene. A wall, at the edge of the world: I had been comparing those six with Dolphin (the emulator running the real game, which is our reference) for a while, and every number matched. Same state, same position, same fade value. Whatever was wrong had to be in how they were drawn.

So I tried switching their drawing off in Dolphin, to see what disappeared. Nothing did. Which seemed to say the wall was drawn somewhere else, until I noticed my switch hadn’t worked at all.

Wrong guess two: Dolphin was ignoring me

Dolphin doesn’t interpret GameCube code instruction by instruction. Its JIT (“just-in-time” compiler) translates each chunk of code into PC code the first time it runs, and reuses the translation after that. I had written a “return immediately” over the start of the wall’s function, but Dolphin kept running its cached translation of the old code. A breakpoint one instruction past my patch still fired, which is how I caught it. Saving and reloading an emulator state throws the cache away; after that, the patch held.

And the wall was still there. So fldAsterWall really wasn’t drawing it.

Asking the game who draws what

This next step was mine. Rather than guess at other objects, I asked the game for its list. Translucent things are drawn last, in an order sorted by depth, from one list the game rebuilds every frame. Pausing Dolphin as that list was being drawn and reading it out gave 175 entries. Then I went down the list by family, putting each family’s objects into their “finished” state, reloading in between. When the 20 objects of a script called fldStorm1 went, the wall went with them.

The walls are storms. Twenty of them, each pinned to a spot in a 2,400-unit grid that moves with your ship, so the ring of cloud travels with you and never runs out.

Everything matched, and nothing showed

On the port, the storms were all there, and doing everything Dolphin did. I traced the draw step by step: the same clipping distances, the same vertex positions to the hundredth, the same texture coordinates. Some of the storm’s pieces were passing the visibility test and being handed to the graphics card. They just never showed up.

When something is drawn but invisible, the trick is to make it impossible to hide. For each draw of a storm, I forced the graphics state to “solid white, ignore depth, no transparency, no culling”. Two enormous white slabs appeared, left and right, exactly where Dolphin shows the clouds. The geometry was fine; something in the drawing state was erasing it.

Then I put the states back one at a time. Depth and culling didn’t matter. Blending and the alpha test did, which says the storm’s pixels came out with zero opacity. A storm’s opacity is three numbers multiplied together: the cloud texture’s own transparency, a fade baked into the corners of the model, and one made from lighting. I sent each through on its own. Texture, fine. Corners, fine, and already looking a lot like Dolphin’s soft wall. Lighting: zero.

Opacity is a product, so any one zero hides the whole storm. That is what made the lighting the suspect.

Two lights behind your head

The storm’s last ingredient is a lighting channel lit by two white lights the game places just behind the camera. Used as opacity, the lighting does something neat: it stays near full strength wherever the cloud faces you, and drops only where the surface turns edge-on, so the wall softens at its silhouette.

Lights have a distance falloff, three numbers called k0, k1 and k2. The game sets the lights up, reads the falloff back, divides it by a constant to make it almost nothing, and stores it again. In Dolphin, the light’s k0 ends up at 0.0033: next to no falloff, so the light reaches the clouds at full strength.

On the port, the “read it back” step was the bug. The port draws through a library called aurora, which keeps its own layout for a light. The port’s stand-in for the read-back assumed the GameCube’s layout, where the falloff sits a few slots further along. In aurora’s layout, those slots hold the light’s position. So the game read the position (0, 0, 100), divided it by 300, and stored it as the falloff. The light now dimmed with the square of the distance, and at the distance of the walls it was a few millionths of full strength. The clouds were there, lit by a light too dim to see them.

The light’s strength at a distance, with the falloff Dolphin ends up with and with the one the port read out of the light’s position. Both axes are logarithmic.

One line changed: ask aurora for the falloff instead of guessing where it keeps it. The walls came back, soft edges and all.

What I’m taking from it

A name is a hint, not evidence. “Wall” in the name was the first thing I chased.
Check that your experiment ran before believing its result.
When something is invisible, make it loud first, then take the loudness away one piece at a time.

Where the claims come from: the object list, the light values and the kill tests are from Dolphin’s memory and controls while running the game; the storm’s grid and drawing steps are from the decompilation, and were confirmed by tracing the port.

The music reads the room

2026-10-07T00:00:00Z

If you’ve played Skies of Arcadia, you already know this one by heart: the big battles keep an eye on your health bar, and the soundtrack changes with the fight. Fall into danger and the music turns tense; get the boss on the ropes and the triumphant theme kicks in.

I, on the other hand, met the game through its decompiled code, so I found out the other way round: by reading a function that watches everyone’s HP and wondering why a music task would care. Fans know that it happens. This post is about how, and the answer turns out to be delightfully simple.

But first, a detour, because you need to know what a “song” even is in this game.

The music is played, not recorded

Almost none of the music on the disc is a recording. Each background song is a sequence: note data, a lot like a MIDI file, that plays a bank of short instrument samples live, through Factor 5’s MusyX sound engine. On the GameCube disc each song is a pair of files in the /sound/ folder:

mXXXX.info: the song itself and its instrument directory;
mXXXX.samp: the instrument samples, in the GameCube’s 4-bit DSP-ADPCM format.

There are 119 of these pairs. Every time a song plays, the console is performing it, note by note, mixing the voices at 32 kHz.

Only a handful of things are real recordings, stored as stereo streams: the intro and title music, and the voice clips. The title theme is a 22,050 Hz stream, 93.4 seconds long, and the title screen uses it as a clock. It waits for the music to finish, and after about 92 seconds (0x1686B milliseconds, to be exact) it gives up on you and plays the opening demo instead.

A side effect of playing the music live: every instrument is only as good as the rate its sample was stored at. In m0231, half the instrument samples are stored below 16 kHz, and a few at just 2 to 3 kHz. That’s a big part of why the GameCube music sounds a little duller than the Dreamcast original. More on that below.

Ordinary battles don’t care

The port let us test this directly. Its cheat tools can poke anyone’s HP in the middle of a battle, so in an ordinary battle we dropped Vyse to 3 HP, and then the enemy to 3 HP. The music didn’t flinch. Ordinary battles play one song from the first turn to the victory fanfare.

Boss battles score the fight

The big battles are different. Every battle loads a battle bank, m0458 to m0462, and two of them, m0460 and m0462, aren’t songs at all. They’re sets of segments: 14 in m0460, 15 in m0462.

Something has to pick which segment plays, and that something is a little task the game runs every frame, at fn_8007D42C in the decompilation. (Before anyone had worked out what it did, its notes called it a “party recovery advisor”, which tells you it reads HP and not much else.) It watches everyone’s HP and keeps the battle in one of three moods:

Even: the normal battle loop.
Danger: any party member under 25% HP, or the party as a whole under 40%.
Winning: the enemies are down to under half their total HP.

There’s one lovely detail in the rules. You enter Danger at 25% for anyone or 40% for the party, but you only leave it once nobody is under 25% and the party is back up to 75%. That gap is hysteresis, the same trick a thermostat uses so it doesn’t click on and off all day. A quick heal that just scrapes you out of trouble doesn’t make the music flip-flop between tense and calm every turn.

An illustration of the rule, not a recording: twelve turns of a made-up boss fight. The music turns tense at 38% and stays tense through a heal to 61%, until the party is back above 75%. (The game also enters Danger when any one member drops under 25%; that rule is left out here.)

When the mood changes, the game stops the music, plays a short sting to mark the change, and then loops the new mood’s segments, round and round:

Bank	Even	Danger	Winning	Stings
m0460	0–3	4–5	6–7	8–13
m0462	0–7	(plays Even)	8–11	12–14

And that’s the whole trick. The game never mutes instruments, never changes the tempo, never cross-fades two songs. It only starts and stops whole segments, with a sting to cover the seam. (The one place the game does reach into a playing song is the world map, where the ambience turns six tracks up or down depending on how close your ship is to certain points on the map.)

A confession: we know all this from reading the code, and that code matches the retail game byte for byte, so it’s exactly what shipped. But the port can’t yet play far enough into the game to reach one of these battles, so we haven’t heard it switch moods in a run. That’s one to look forward to.

It all started on the Dreamcast

Legends is a port of the 2000 Dreamcast original, and its sound is a conversion of the Dreamcast’s. You can still see the seams:

Same names. Every GameCube song has a Dreamcast twin with the same name. m0231.info on the GameCube is M0231.MLT on the Dreamcast. The GameCube code still asks for files like /sound/m5000000.mlt. .mlt is the Dreamcast’s sound bank format, and the GameCube loader quietly throws the extension away and loads .info and .samp instead. Nobody ever went back and changed the names.
Same battle design. The Dreamcast battle banks are cut into segments the same way: 14 in M0460, 15 in M0462. So the mood system almost certainly came over from the original.
A whole different engine. On the Dreamcast the music runs on the sound chip’s own ARM7 CPU, under Sega’s driver, BONITO.DRV (“bonito ver.2.00”, dated 7 February 2000). The game writes 16-byte commands into sound memory, along the lines of “play sequence 0 of bank 2 on port 0”, and the driver plays them on the chip’s 64 voices at 44.1 kHz.
The GameCube has more sample data, not less. m0231.samp is 504 KB. The Dreamcast version of that song has a 62 KB bank of its own (plus 1.08 MB of instruments shared by every song). So the one-disc GameCube release didn’t squeeze the music to save space. The difference in quality comes from the conversion: samples re-encoded to ADPCM at odd rates, a 32 kHz mix instead of 44.1 kHz, and an engine without the Dreamcast chip’s per-voice filters.
The title theme is the same recording. The Dreamcast stores it as plain 16-bit audio at 44.1 kHz, the GameCube as 4-bit ADPCM at half that rate. Line the two up and they correlate at 0.9998: the same master. The GameCube copy just carries a layer of ADPCM hiss, about 28 to 32 dB below the music.

That last finding is behind one of the port’s plans: an optional Dreamcast music pack, built at install time from your own Dreamcast discs. And because the boss battles only ever switch whole segments, a recording of each segment is all a music pack needs to follow the fight, mood swings and all.

Thirteen, not twelve: how two swapped bytes changed a whole battle

2026-10-07T00:00:00Z

This is the story of a battle that went wrong in the most annoying way possible: nothing crashed, nothing looked broken, and every random seed matched. The fight just… played out differently. And it took a log of every random number the game drew, in two programs at once, to find out why.

The setup

The way we check the port is to play the same inputs through it and through the Dolphin emulator running the real GameCube game, and compare the two frame by frame. A battle is a stern test of that, because battles are full of dice rolls: who goes first, whether a hit lands, which way the camera swoops. To make a fair comparison, we copy the port’s random seeds into Dolphin, so both games start every battle with the same dice.

On Alfonso’s ship, early in the game, there’s a random battle. With every seed matched, the port’s version of that battle took different turns from Dolphin’s, and ran 270 frames longer. Same seed, same inputs, different fight.

Logging every dice roll

Watching the two fights side by side only tells you they differ, not where they start to differ. So I went after the dice instead. If both games roll the same dice in the same order, they make the same decisions. That makes the dice the thing to watch: write down every roll, in both programs, and find the first place the two lists part ways. Everything after that point is just consequences.

The game’s random number generator is a classic linear congruential generator: each call does state = state * 0x41C64E6D + 0x3039 and hands back part of the result. On the port, a debugger breakpoint at the end of that function logs the value and who called it. In Dolphin, a “log only” breakpoint on the function’s return instruction does the same, at full speed.

First wrong turn: the log had holes. Dolphin’s JIT compiler, which translates GameCube code into PC code on the fly, likes to paste small functions straight into the code that calls them. When it did that, the breakpoint simply never fired. Over the first battle, 338 of 875 calls were missing from Dolphin’s log, and nothing said so.

The fix was to turn that optimisation off (JITFollowBranch=False). But finding out the hard way made me decide not to trust any log again until I could prove it was complete. Because each call’s state is just the previous state pushed through that formula once, we can check every pair of neighbouring log lines: does stepping this state give the next one? If every pair checks out, nothing’s missing. With the optimisation off, every pair checked out.

Testing the tool before using it. Before pointing this at the broken battle, I pointed it at two battles I believed were fine: the two at the very start of the game. If my logs disagreed there, the problem would be my method, not the port. They agreed: 877 calls against 874, the same callers and values, frames within 2 of each other. (One call lands 11 frames later in Dolphin, and I still don’t know why. It’s on the list.) A “different camera” I’d spotted in one of those battles turned out to be the same camera cut, one frame apart. So the method worked, and those battles were not the problem.

Second wrong turn: the button presses. The test inputs press buttons at fixed frame numbers, and on Alfonso’s ship the random encounter started 3 frames earlier in Dolphin than in the port. So every press landed at a slightly different moment in the battle. Pressing A skips the battle’s intro countdown, so the port’s battle ran 3 frames ahead. Shifting Dolphin’s presses by the same 3 frames lined the two runs up again.

Call number 163

With clean logs and lined-up inputs, the two streams of random numbers agreed, value for value and caller for caller, all the way to call #163, 322 frames after the seed. There, the port made one extra call that Dolphin didn’t.

Both logs, call by call. Up to call #162 they agree on every value and every caller. The port’s extra call at #163 shifts every later roll onto the wrong consumer.

The extra call came from the battle camera. When nothing more specific is going on, the overview camera picks a random height to look from. In Dolphin, a special camera move (the game’s camera mode 11) was running at that moment instead, so the overview camera never rolled its dice. One extra roll on the port’s side, and from then on every later roll went to the wrong consumer: different hits, different turns, a longer fight.

So why did Dolphin’s game run camera mode 11 and the port’s didn’t? That camera move is asked for when a fighter is doing a particular kind of reaction. Forty frames earlier, enemy 3 had reacted to an attack. In Dolphin it took reaction 0x0D, a counter attack, which brings the camera in. In the port it took reaction 0x0C, a plain attack, which doesn’t.

The random roll behind that choice was identical on both sides. The table it picked from was not.

Thirteen, not twelve

The function that chooses a reaction (fn_8002EB4C) has two candidate moves stored in a table, as two 16-bit numbers side by side: 0x000D, then 0x000C. The decompiled code copies those four bytes into a 32-bit variable and then reads the first 16-bit half through a pointer.

On the GameCube that’s perfectly fine. Its PowerPC CPU is big-endian: a number’s most significant byte comes first in memory. The first half of that 32-bit word is the first number in the table, 0x0D.

A PC (and an Apple Silicon Mac) is little-endian: the least significant byte comes first. Read the first half of the very same 32-bit word on the PC and you get the other number, 0x0C. So a roll of 0 meant “counter attack” on the GameCube and “plain attack” on the PC. One swapped pair of bytes, and the whole battle went another way.

The same four bytes, read through the same 16-bit pointer, on each kind of CPU.

The fix was small: the port’s version of that function declares the table as what it really is, two 16-bit numbers, so each one is loaded and read in the right order. After that, all 1,138 random calls in the battle matched Dolphin’s, caller for caller and value for value, and the battle ended on the same frame.

The bug had friends

A value stored at one width and read back at another is the kind of bug that never travels alone. Once we knew the shape, we went looking for it across the whole game and found seven more, then added an automatic check to the port’s build that flags this pattern wherever it appears, so the next one gets caught before anyone has to log a thousand dice rolls to find it.

My favourite part of this one is how far the effect travelled from its cause. The symptom was “the camera is different and the fight is longer”. The cause was a single choice between a counter attack and a plain attack, 40 frames and one camera decision earlier, decided by which end of a 32-bit word the CPU reads first.