That is contrasted with 64 different renderings of the player ship in the arcade game. However again, at this resolution, it'd be pointless to attempt to render that many different bitmaps.
One interesting thing to note is that the player ship direction is stored as a single byte, the value varying the full range of 0-255 to represent 360 degrees. Each tap of the rotation changes the direction by +/-3, which means that coming full circle, you don't actually end up at 0 again, but rather at 255 or 2 first time 'round, and 254 or 1 next time. Not terribly important, because your direction is effectively right-shifted by 2 bits to determine which ship to render - IOW each tap of the rotation button does not necessarily change the ship rendering.
In the IIGS case, the direction needs to be divided by 24, which is equivalent to right-shifting by 4 and 5 and adding the results, although the resolution of the operation needs to be increased (easily done in 16-bit mode using the XBA instruction) to get all 24 outcomes.
Unfortunately identifying the ship in the display list is practically impossible. Rather than work out how/where to patch the arcade code, as a quick hack I simply added a routine at the end of the DVG emulation code to (always) render the player ship. Fortunately the arcade code always ends the display list with a CUR command corresponding to the center of the screen, so at least it's always rendered there and the game can be 'played' (more-or-less) as long as you don't use the thrust button!
 |
| Player ship is now rendered... sort of... |
I should add that I'm yet to implement the 'thrust' indicator on the player ship; Norbert hasn't supplied me with any rendering details for this but from a quick look at his emulator video, it looks like a single pixel is illuminated for each bitmap - I just need to work out exactly which pixel!
That really just leaves the player ship explosion, another list of component vectors patched by the arcade code as it is copied to the display list. Again, there won't be any way to identify it in the display list, so I'll likely extend my quick hack to detect when the ship is exploding and render it there; enough to ensure my rendering algorithm is correct.
And that should be everything that needs to be rendered! From that point on, it's a matter of producing pixel-shifted bitmaps where required, updating the rendering routines to use them, and then finally optimise it all to eliminate the flicker and get it running at full frame rate. There'll be some use of the IIGS interrupts to throttle the frame rate, and of course hooking up proper keyboard/joystick/paddle controls and adding a fancy menu. Unlikely it'll all happen before WOzFest, but I should have a decent demo by then at least!?!
I discovered that oddity of ship rotation when playing with an asteroids emulator. It explained something that I'd sorta noticed when playing the game but thought I was imagining it. It seemed like sometimes you could fire straight to the right and left but sometimes you couldn't line up for a straight (parallel to the X axis) shot.
ReplyDeleteAt the time the cause wasn't obvious and since I was paying for the games I wasn't inclined to experiment. The rotation changing in steps of 3 modulo 256 makes it clear. Only every 3rd rotation of the ship will it line up precisely with the X axis in one direction. And you'll never be able to say, fire straight right and then turn around and fire straight right.
Is there any retro game you haven't tinkered with??? ;)
ReplyDeleteHaving crazy thoughts again - if I transcoded Asteroids to Z80 do you think the Model 4 at 4MHz would be up to the task of rendering it on the hires board at 512x192 at a half-decent frame rate? Max asteroids is 27, plus player ship, saucer, up to 6 shots in total plus the text. I think I've answered my own question; if Lode Runner struggled with 5 sprites...
Regardless, I think I'm going to co-transcode to C whilst I'm doing the 6809 version, which is exactly what I did with Knight Lore. The code is well structured and would lend itself quite nicely to being translated to C. From there it would be trivial to port to the Neo Geo and Amiga, and possibly other similarly-capable hardware.
I really should have persisted with my no-wait-state hires board clone... :(
DeleteHeh, hazard of the job having shipped many SKUs of Atari, Midway and other emulators.
DeleteThere's some vague hope on the TRS-80 if you optimize your drawing to happen in the vsync. A big asteroid is mostly empty space. Still, it'd be tough to get decent performance.
Although it seems absurd on the face of it, I wouldn't rule out a lo-res display. It wouldn't look great (even at 160 x 72), but the gameplay would be wonderful.
Hmmm, thinking about hires, the text would cost nothing as the text screen could take care of that. Heck, you could even go truly hybrid with, say, the ship, shots and saucers done hi-res and the asteroids with text-mode graphics.
Hmm... hybrid mode is an interesting proposition... didn't think of that! I just need to convince myself that the effort of porting to Z80 is going to be worth it in the end. Since I've got 6809 and C ports planned before then, encompassing - potentially - 4 more platforms, I'll likely be pretty burned out on Asteroids by then. :( But food for thought!
ReplyDeleteBurned out on Asteroids?! Bite your tongue. :-)
Delete