Jump to content

TROGBlog

  • entries
    47
  • comments
    219
  • views
    125,209

The Battle of Midway v0.10


TROGDOR

1,115 views

Hi all,

 

I haven't posted in a while, but I've been doing some work behind the scenes.

 

I got bogged down in the Stellar Fortress code, working on more kernel tweaks and hacking at the AI. Normally I enjoy AI coding, but implementing AI on an 8 bit system with a few bytes of RAM left is painful. So I decided to take a break from that game and revisit The Battle of Midway.

 

tbom105sm.png

 

The first thing to point out is that after using it for 2 years, I've finally bid a fond farewell to PCAEWin. I installed Stella 2.2 when it was released, and was very impressed with the integrated debugger, so that's become my emu of choice. I particularly like the red highlighting for register and memory deltas. It also provides more crisp screenshots, so no more fuzzy screenshots in my blog.

 

The second thing to point out is that I've finally stopped being a miser with my precious source code. post-2572-1086209859_thumb.jpg

This release contains a zip of the full source and the binary.

 

 

And on with the update description:

 

Features:

tbom09.asm 6/12/06

- Complete rewrite of the kernel. Now uses 2LK, to remove the on-screen sprite shifting.

 

tbom10.asm 6/12/06

More improvements to the kernel:

- Ball and both missles now have full resolution.

- Both player sprites have full resolution. Used sprite buffering to provide full resolution with 2LK.

- Removed artifacts from player sprites in the ship area of the screen.

- It's now 262 scanlines proper.

 

Known Issues:

- Bomb only falls to the right.

- The bomb loops strangely when dropped near the left side of the screen. (Some kind of boundary condition error I'm sure.)

- There's an inexplicable HMOVE bar in the upper left side of the screen.

 

Development Notes:

Necessity is the mother of invention. I made an interesting discovery between versions 9 and 10. In version 9, I reworked the kernel to 2LK. My intention was to use VDEL to shift both sprites, both missles, and the bomb to provide full vertical resolution. My first disappointment was finding that there are no VDEL registers for the missles! Then, after lurking through some posts on VDEL, I discovered that the sacred stealla.pdf's description of VDEL behavior is inaccurate, and I couldn't get it to provide the full resolution for the sprites either. Blah.

 

So at the end of version 9, I had a half-resolution version of the game. The on-screen sprite shifing was solved, so I was happy about that, but I really didn't like seeing the half resolution motion of all the movable objects. It was too jerky.

 

In version 10, I set out to resolve this. First, I squeezed the 2LK to allow update of the bomb and both missles on every scanline. Not too hard. At that point I decided I was stuck with the jerky half-resolution motion of the planes. But, because of the way I implemented the 2LK, I was now seeing artifacts at the top of my plane sprites. The sprites are 8 lines tall, but the 2LK was overflowing to a 9th scanline, either before or after the sprite, and that was being drawn to the screen.

 

To fix this, I buffered the plane graphics data with a line of zeros on at the start and end of each sprite animation. Now, here's the amazing part. As soon as I did this, the planes suddenly went to full vertical resolution!! It was totally unexpected. My 2LK processes 2 scanlines of GRP0 in the first line, and 2 scanlines of GRP1 in the second line. Adding the extra zeros into the graphics data provided a perfectly meshed offset, so that the planes moved smothly from one scanline to the next. I'm still relatively new at kernel coding, but I've never seen this technique mentioned in any kernel discussions, so I'm wondering if this is new? Or did I just reinvent the wheel? In either case, I'm very happy with the result.

 

I suspect there's a more efficient way to achieve full vertical resoltion in the player sprites using the VDEL buffers, but I'd have to see a 2LK code example to understand it.

 

For comparison, here's a binary of the older version 9 of TBOM. You'll see the jerkiness I was complaining about.

 

 

2 Comments


Recommended Comments

I'm SO glad you're still working on this game. I've been waiting for it since you started talking about it :)

 

Keep up the good work!

Link to comment

Hi ~llama. Thanks for the interest in the project. This game will see the light of day eventually. In fact, another major update will be coming in a few minutes. :)

 

I'd like to submit something for the 2006 minicomp, but time is getting tight.

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...