Friday, 23 April 2021

Rocket to me, baby!

Some eye candy today. I've now got the rockets launching and following their pre-described path. Every 64 interrupts the code scans the ground-based objects to see if there are any rockets likely to hit the player (within a hard-coded window towards the left side of the screen) and if so, launches the first one it finds.

There are a maximum of 4 in-flight objects at any one time, and that includes rockets, ufos and even fireballs. Yes, hard to believe that there are only ever 4 fireballs on the screen in stage 3, and that they cause so much trouble!

Rockets launching

Each so-called 'in-flight' object has a table that describes their flight path, which is used to apply a delta to its position every interrupt. Not surprisingly, the path table for the rocket consists of a single entry that moves it up the screen.

Rendering the ceiling and the floor

It's interesting that you don't notice the imperfections in the game until you're debugging a transcode. The rocket sprites actually overwrite the progress bar before disappearing - confirmed on MAME.

You tend not to notice the gaudy palette when you're playing...

Next up is to add the routines to handle ufos and fireballs, and also to render the base (a ground-based object). Aside from the fuel gauge, which is currently not updated, that'll be about all I can do before adding the player ship and handling collision detection & explosion to round out the demo.

All that will leave handling of player controls, bullets and bombs, things exploding and game mechanics suchs as coin-up, scoring, high score updating etc. If I had to take a guess, I think I'm approaching the halfway point in the transcode. It's hard to estimate at this stage because the ASM-to-C code line ratio varies considerably with the code itself.

Thursday, 22 April 2021

Completely floored!

No eye candy today but some progress; rockets, fuel tanks and so-called 'mystery' objects are rendered as they appear and then deleted as they scroll off the screen. Interesting to note that they simply disappear as soon as they hit the edge of the visible area of the display, as confirmed in MAME. There is also a maximum of 8 ground-based objects on the screen at any one time.

I've also implemented the routine that switches landscape meta-data as you reach the end of the level. As a result, the demo now scrolls through the entire game, looping endlessly on the BASE level. I've currently only implemented the routine to decode (and render) the floor, so next task is to implement the routine to decode the ceiling.

I was thinking once that's done, I should put together some code that renders all 6 levels into a bitmap.

Wednesday, 21 April 2021

Scrollin' scrolling' scrollin'...

 A couple of days ago I implemented the landscape scrolling and, much to my amazement, it actually worked first time - at least until the end of the first stage.

In the last few days I've been working on getting the so-called ground-based objects rendering. There was a bit of infrastructure to implement and also a minor re-architecture on some of the structures in RAM (simplfying them) but after fixing a bug this morning I've got the rockets rendering.

Too bad I can't upload a video of the scrolling landscape

Getting the rest of the ground-based objects rendering should now be straightforward, as they're all handled using a common object structure.

In fact looking at the disassembly it looks like most of the variables have been defined in the C code, so hopefully that'll be the last tweak of the structures.

The next few days will likely involve just working through the routines to create the rest of the ground-based objects and then 'animating' them which I am assuming is how the rockets are launched. Since the code simply operates on the existing structures, it should be a matter of cranking the handle.

Saturday, 17 April 2021

Land(scape) ahoy!

Now up to the demo proper. The initial landscape is drawn (hard-coded routine, not part of the landscape data), the stage indicator on the head-up display is rendered, and things are about to start moving! As I suspected, the demo will comprise much of the remainder of the code, which is a good thing.

The demo is about to start...

At this stage there's still lots of variables being added as I go and a little re-architecting as I learn how the variables are accessed, keeping in mind that in some cases the type of variable is optimised for the C code if it does not appreciably affect the code. Scott has defined structures in his disassembly and I'm staying true to his design as far as possible. It helps self-document the code and also helps the transcode which, I must say, has been going particularly smoothly.

A note on the structure of the Scramble code as a whole:

The main routine is a busy loop that waits for tasks to be written onto a circular queue by the NMI routine. If there is nothing on the queue, it will periodically call a few non-time-critical routines, such as blinking text, drawing the fuel gauge, drawing a column of landscape that is just about to be scrolled onto the screen etc.

The NMI, 60Hz driven off the vertical blanking interrupt, does all the heaving lifting. It's one big state machine that Scott refers to as 'scripts' that control high level program flow and subsequently the low level mechanics of the game logic, controller inputs, and video hardware updates.

Quite a neat design, and one that could be applied to any number of early arcade games. Scott has mentioned that Galaxian is very similar, and I'm hoping that's the case as it would make a transcode similarly straightforward, especially as it's running on the same hardware.

Things should really start to get interesting now. Without <F10> I'm going to have to patch the code to run the demo immediately after start-up so I don't have to sit through the attract mode every time...

Friday, 16 April 2021

Waiting for the demo...

 Transcoding is progressing nicely. The three attract mode screens (challenge, high scores and score table) are now complete, and the game cycles through to start the demo. The sequence and timing of events and colours and graphics all match what's happening in MAME (graphics corruption aside).

I've been tweaking the architecture as I go, improving a few things that I really should have done from the start. All hardware accesses are now done via 'osd_XXX' functions so the core Scramble code should be highly portable.

Starting to get to the fun bit now; the demo, which I'd think would comprise most of the functionality of the game itself. It's early days yet but the code is translating nicely to C and if it remains this straightforward, it'll be the easiest transcode I've done thus far. Given that Galaxian (same hardware) is supposed to be very similar software-wise, I'd be tempted to work on that next while it's all fresh in my mind.

Thursday, 15 April 2021

Somewhat attractive so far...

 Not a lot of time so minimal progress, but something to show for it.

So far the code has been straightforward to transcode. I think that'll be the case for quite a while yet, as I work through the attract mode scripts and underlying functionality.

I'm not quite sure what the 'corruption' is on some of the tiles. Right now it's irrelevant to the process.

EDIT: I've just noticed a few issues with the above, namely the bottom half of the display is not in colour. I'll look into that. I also notice on MAME that '1UP' and the score & high score are displayed, even before the attract mode starts. I'll have to look into that as well!

Wednesday, 14 April 2021

On a high!

 Very quick update as it's late... implementing the script processing and now it clears the rectangles and prints "HIGH SCORE" in attract mode.

There's a bit of jumping around in the code, but on closer inspection it can be unravelled into a single function... at least that's how it appears so far. So again, as yet, no gymnastics.

In the early stages of implementation - especially with script-driven logic - there's a lot of time spent setting up variables, creating tables and adding stub functions and their prototypes, so progress is slow.