Space Rogue

01 · The port

Every routine of the game, checked against the original

The game is a 6502 program of about 47,000 bytes in eleven files that load over each other. The port is the same program written again in JavaScript, one function for each routine the listing names, 599 in all, reading and writing the game's variables at the game's own addresses.

02 · The 3D view

Native resolution and smooth motion

The two switches beside the screen change how the page draws the 3D view, the window above the cockpit's panel, and nothing else. The game runs underneath as it does without them: two copies of it, one with both switches on, keep every byte of memory the same at every frame.

Native resolution

The game draws the view into the cockpit's multicolour bitmap, 126 pixels across and 103 down, each pixel twice as wide as it is tall. Many of its colours are patterns: two of the C64's sixteen colours in alternating pixels, which the screen blurs into a shade between them.

With Native resolution on, the page works the view out again from the numbers the game keeps at each pass it draws: where every object is and which way it faces, where the camera is, and how far the view is zoomed. It applies the game's own rules to them: which objects are in view, which are near enough for a model and which are drawn flat, the order from farthest to nearest, and which faces of each model turn towards the camera. Then it draws the same polygons, the same dots, rings and bursts, and the arrows that point to the target, as sharp shapes at the screen's own resolution. Each pattern becomes the shade the eye mixes from it.

The passes are the 2,686 the game drew in 23,100 frames of play, from power-on and from 23 moments of flight, fights and docking, with the stick, the view and the target changed as the game ran. The game works out each corner with its tables of logarithms and rounds it to a whole pixel. The page works it out exactly, which moves a corner by up to 2.3 pixels.

Smooth motion

The game counts the frames its drawing takes and allows three for each pass. When a picture takes longer, the passes after it leave the drawing out, each paying back three frames, until the game has caught up (frame_skip3, $A470). So everything moves at every pass, and the view shows only some of the passes: in a fight it can change three times a second while the ships in it move nine times.

With Smooth motion on, the page draws the view at the screen's own frame rate, 60, 120 or 144 times a second. It keeps the numbers of every pass, the passes the game drew and the passes it left out, and draws each frame of the screen between two of them: every object and the camera part of the way from one pass to the next, and every turn part of the way round. In the chase and cinematic views the game moves the camera only at a pass it draws. For a pass in between, the page places the camera as the game would have: the chase camera at the same distance behind the ship, the cinematic camera where it was, each turned to face the ship.

The view keeps a little behind the game, so that the next pass is always there to move towards: by the longest gap between the last few passes. The C64's picture is behind the game too, since it shows the last pass drawn while the next one is being drawn, but by less. Over the same 23,100 frames the smooth view showed the game 44 milliseconds later than the C64's picture, on average.

What the game changes at once stays sudden: another view, a jump through a gate, a ship that arrives or is destroyed, and the dust that the game puts back near the camera as you fly on. Without Native resolution the page paints each view in the C64's pixels with the game's own drawing routines, run on a copy of its memory with the positions in between. At a pass the game drew, that picture is the game's own: in 468 such views every pixel of the window was the same.

03 · Differences

What differs from a C64

• No loading time. The 1541 takes seconds over each file; the page has every file of both sides at once.
• No hang at "Old or New Game?". The routine that turns on the bitmap leaves the raster interrupt set for line $150, which a frame never reaches, so about one start in six on a PAL machine stops there for good (Discoveries). The page moves the line back into the frame, as the simulator the port was checked on does.
• Saves stay in this browser. Saving in space writes the game's SAVED file to the browser's storage, and an old game loads it from there. A browser that keeps no storage for the page keeps the save only until the game is started again, and an old game with no save of the player's loads the one on the original disk.
• The manual's word is on the page. Before an old game the game asks for a word from a page of its manual. The page shows the word the game wants under the screen.
• Interrupts between stretches. On the C64 the frame's interrupt can come between any two instructions; on the page it runs between two calls of the main loop. Where the main program reads what the interrupt counts in the middle of a call, the page first moves its clock on by what the call has cost so far, so the count includes the frames the drawing took, as on the C64.
• Keys held for three frames. The game reads the keyboard once a frame, so the page holds a key for at least three frames however briefly it is tapped.
• Sound a frame at a time. The site's model of the sound chip takes each frame's register writes together, in the order the game made them.
• Native resolution. A 3D view of sharp edges and solid shades never appears on a C64. The page draws it from the game's own positions and rules, the same shapes the game draws in its pixels (section 02).
• Smooth motion. A view between two of the game's passes never appears on a C64. The page draws it from the game's own positions, part of the way from one pass to the next, and a little later than the C64 shows its picture (section 02).