Jump to content

TROGBlog

  • entries
    47
  • comments
    219
  • views
    125,209

The Battle of Midway v0.17


TROGDOR

1,239 views

With the Atari movie coming up, I've had some motivation to do more coding. I took another look at The Battle of Midway this weekend, and here are the results.

 

tbom17xy3.png

More entitlement.

 

tbom17.zip

New Features:

tbom16.asm 7/13/08

- Removed unnecessary procedural subroutines, freeing up some ROM and cycles.

- Expanded the ROM out to 8k. VSync and Overscan are in bank1, Kernels are in bank2.

- Displays title with fade-in effect and player's plane.

- Integrated include files into the main .asm file.

 

tbom17.asm 7/14/08

- Added score display in playfield graphics.

- Added scoring: Bombing the ship 10 points, hitting the enemy Zero, 50 points.

- Added sound effects for crashing airplane.

- Added player life count, and game end when all lives are lost.

- Resets the bomb and bullet when they hit.

 

To Do:

Remove HMOVE artifact from title screen.

Multiple vectors for AA fire.

Time-based high-res physics engine for Zero.

Proper physics engine for player plane, to allow for engine stalling.

AI to control Zero flight patterns.

AI targeting for AA fire and Zero fire.

 

Known Issues:

- None so far.

 

Game Controls:

- Press fire to start the game.

- Left and right control the pitch of the plane. (As in aviation pitch. Ironically, it does also change the pitch of the plane's engine, to represent stress on the engine.)

- Fire button fires the machine guns. The machine guns will overheat if you hold the button too long. I'll probably pull the overheat feature, since it eats a byte of RAM and doesn't add much to the game.

- Pressing down on the controller will drop the bomb.

 

Development Notes:

One benefit of having all these open projects is I'm getting tons of code reuse. Building 8k ROMs is second nature now, and it only took about half an hour to expand this ROM from 4k to 8K. I also dropped in the score display code from Hunt the Wumpus and from Stellar Fortress to compare them. For now, I'm going to use the Stellar Fortress playfield score display, but it may change back to player graphics before I'm done. My main concern when displaying the score is using as little of the screen realestate as possible, so I try to keep it in 5 scanlines. Either implementation will allow me to display a 7 digit score and a one digit life count.

 

I had wanted to clear up that HMOVE artifact before posting this, but it's proving troublesome. This is my first attempt at using a cycle 73 HMOVE, which is that much harder when trying to implement it with a 48 bit display. The pixel movement wasn't happening as expected, and the title came out completely garbled. I have two questions about this:

 

- When it says HMOVE at 73 cycles, does that mean the HMOVE write starts at the 73rd cycle, or ends at the 73rd cycle?

 

- I'm guessing that all the move registers have to be set to 8 to prevent any motion. This makes the HMCLR register useless in this mode.

 

So I punted for now, and just displayed the title with the artifact.

 

As a demo feature, the game will randomly pick one of the two enemy capital ships when you press the reset switch, so you'll see the battleship Yamato more often.

 

Here's the cartridge label mock-up I posted some time back:

 

tbomlable1oi9.jpg

2 Comments


Recommended Comments

When it says HMOVE at 73 cycles, does that mean the HMOVE write starts at the 73rd cycle, or ends at the 73rd cycle?

I'm guessing that all the move registers have to be set to 8 to prevent any motion. This makes the HMCLR register useless in this mode.

 

The HMOVE instruction has to end at cycle 73 (or 74) for this trick to work, which means that you have to do the sta HMOVE on cycle 70 or 71. This will move the sprites left by 8 pixels, so you will need to set the HMPx registers to 8 unless you want this movement. However, you can also use other combinations of HMOVEs and offsets if these cycles are inconvenient. There is a handy table at the end of the advanced programming guide which shows the movement generated by the different HMOVE/cycle combinations.

 

Chris

Link to comment

Thanks Chris. I figured out what I was doing wrong. After trying various values, I finally got wise and opened up the Stella TIA debugger. I've never had to use the TIA panel before, but this time it proved essential for finding the bug. The sprites were strobed in the right locations and the HMOVE was executing at the correct cycle, but I noticed the HM values for P0 and P1 were both 0, even though I had just written an 8 to both registers. Well, that's the problem. I wrote an 8. What I needed to write was an $80, because the HM registers only use the upper 4 bits. Once I changed that value, everything fell into place, and I now have a title screen with no artifacts. Thanks again. :ponder:

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...