SpiceWare's Blog

A handy tool for your research might be SnapzProX 2. I've used it for capturing movies of MacMAME in action to reproduce sprite animation for several games (Ladybug, Juno First, Colony 7). The trick to using it is run MacMAME in a 1x1 software-mode window, so you're not trying to capture the entire dimensions of your monitor. Then, you can frame-step through movies of the game in action and analyze what you need.

Where's the fun in that?

 

Actually, that's a pretty good suggestion - just my budget won't allow that the moment as I spent a bit more on Atari carts off ebay this weekend that I should have

 

 

As an aside - do you have any time to try a Dragon Sprite? The red/yellow blob is both sprites overlapping. I'm thinking it would be slick to use both sprites to make a 2 toned dragon. By using double-pixeled sprites, and shifing each row left/right the image can be quite detailed like in Dolphin - where both the dolphin and the squid are a single 8 bit sprite.

 

At the expense of a little extra work in the movement routine, you might be able to combine to use four bits for the sub-pixel values of the X and Y coordinates of each ball. Also, I don't think you need to keep track of who is holding a fireball; use 3 bits for velocity and five for direction, but have a velocity of zero indicate that the fireball is either being held or is inactive; its position will make it obvious which of those is the case.

 

BTW, you can give yourself a couple extra bits of pseudo-precision without needing more bit storage for your positions by using the two LSB's of a frame counter and having two lookup tables for velocity. Use the first table on every 3 out of every 4 frames, and the second table on the fourth. This will only work well if you have some non-displayed bits of precision, but 4 bits of sub-positioning should suffice.

As an aside - do you have any time to try a Dragon Sprite? The red/yellow blob is both sprites overlapping. I'm thinking it would be slick to use both sprites to make a 2 toned dragon. By using double-pixeled sprites, and shifing each row left/right the image can be quite detailed like in Dolphin - where both the dolphin and the squid are a single 8 bit sprite.

Sure - I'd be glad to work on one. I took a look at Dolphin and think I've figured out how to design something like that, although I don't know how well it will work for the dragon, since you're still limited by any part of the dragon along a horizontal line being only 8 pixels wide. So his head or tail would have to be higher or lower than the rest of him to get any extra length. (That's assuming both sprites completely overlap each other.)

 

If you can live with flicker, it might work better to use two sprites, adjacent to each other, and flicker between two sets of them for the extra color.

 

How many frames do you want? Should I match the arcade animation as closely as possible?

 

This is, as best as I can tell, all of the frames for the dragon. There seem to be 12 unique frames, and the exact order they're played in is a little hard to figure out, but this is pretty close:

 

At the expense of a little extra work in the movement routine, you might be able to combine to use four bits for the sub-pixel values of the X and Y coordinates of each ball.

I've actually had this in the back of my mind in case I need to come up with more RAM.

 

Also, I don't think you need to keep track of who is holding a fireball; use 3 bits for velocity and five for direction, but have a velocity of zero indicate that the fireball is either being held or is inactive; its position will make it obvious which of those is the case.

That's clever, thanks for the insight

 

BTW, you can give yourself a couple extra bits of pseudo-precision without needing more bit storage for your positions by using the two LSB's of a frame counter and having two lookup tables for velocity. Use the first table on every 3 out of every 4 frames, and the second table on the fourth. This will only work well if you have some non-displayed bits of precision, but 4 bits of sub-positioning should suffice.

Interesting - I'll have to think this one through once I've fully woken up

As an aside - do you have any time to try a Dragon Sprite? The red/yellow blob is both sprites overlapping. I'm thinking it would be slick to use both sprites to make a 2 toned dragon. By using double-pixeled sprites, and shifing each row left/right the image can be quite detailed like in Dolphin - where both the dolphin and the squid are a single 8 bit sprite.

Sure - I'd be glad to work on one. I took a look at Dolphin and think I've figured out how to design something like that, although I don't know how well it will work for the dragon, since you're still limited by any part of the dragon along a horizontal line being only 8 pixels wide. So his head or tail would have to be higher or lower than the rest of him to get any extra length. (That's assuming both sprites completely overlap each other.)

Thanks! The effect might work better if the sprites V from each other. Have the head red, wings red/yellow and the tail yellow. Red/Yellow isn't absolute either (especially when considering the PAL palette). Maybe dark green for the head, dark/light for the wings and light green for the tail would work better.

 

If you can live with flicker, it might work better to use two sprites, adjacent to each other, and flicker between two sets of them for the extra color.

I can live with it - just thought it might be fun to try something different.

 

How many frames do you want? Should I match the arcade animation as closely as possible?

 

This is, as best as I can tell, all of the frames for the dragon. There seem to be 12 unique frames, and the exact order they're played in is a little hard to figure out, but this is pretty close:

 

Wow - that was quick to get the animated GIF. Used the SpapzProX to do it?

 

You can take artistic license with the dragon, especially considering the limitations of the 2600. 12 frames is probably fine, as I have plenty of ROM space for it. I do notice, however, that the 12 frames does not include a fireball launch towards the upper players, so you might need a few more.

I can live with it - just thought it might be fun to try something different.

I'll still play around with the horizontal shifting idea. It's an interesting concept. Brilliant, really, when you think about the tools they had to deal with at the time.

 

Wow - that was quick to get the animated GIF. Used the SpapzProX to do it?

Well... I did at first, then I realized that for some reason, SnapzPro only captures MacMAME when using OpenGL. Which is fine for general capturing, but not for pixel-accurate capture (OpenGL always stretches the image, even at "actual size"). With software mode, all I got was a black screen. Funny, since that used to work fine. I'm guessing some OS update or other broke it. Anyway, I still captured a reference movie with SnapzPro, then for the pixel-accurate stuff, I just hit F12 as fast as I could, and I eventually ended up with all the frames I needed. Supposedly, there's a movie capture feature in MAME now, but as far as I know, it hasn't migrated to MacMAME yet.

 

You can take artistic license with the dragon, especially considering the limitations of the 2600. 12 frames is probably fine, as I have plenty of ROM space for it. I do notice, however, that the 12 frames does not include a fireball launch towards the upper players, so you might need a few more.

Maybe I haven't played the arcade game enough yet, but it always seems to shoot the fireball down. For the 2600 version though, I can "fix" this.

I've only run single player games and it always launchs down, but I figured that was because it always launched at a human player and I was on the bottom. Guess a test by having 4 human players is in order.

BTW, you can give yourself a couple extra bits of pseudo-precision without needing more bit storage for your positions by using the two LSB's of a frame counter and having two lookup tables for velocity. Use the first table on every 3 out of every 4 frames, and the second table on the fourth. This will only work well if you have some non-displayed bits of precision, but 4 bits of sub-positioning should suffice.

Interesting - I'll have to think this one through once I've fully woken up

 

Let me offer a couple of examples. Suppose you want to move something by one pixel per frame. Use a value of '1' on both your '3 in 4' adder and your '1' adder. Starting at position 0, the positions would be

 

= = 0,1,2,3,4,5,6,7,8

 

If you wanted 1.25 pixels/frame, use a value of '1' for your 3/4 adder and '2' for your 1/4. Your positions would be:

 

= = 0,1,2,3,5,6,7,8,10

 

If you want 1.5 pixels/frame, use a value of '1' for the 3/4 adder and '3' for the 1/4 adder. This time:

 

= = 0,1,2,3,6,7,8,9,12

 

Note that there's a pretty big a 'hiccup' every fourth pixel. When moving 1.25 pixels/frame, one extra pixel every fourth frame is inevitable. But having two extra pixels every fourth frame looks ugly compared with one every two frames.

 

On the other hand, if you're using fractional positions, this sort of thing becomes a non-issue. Even if you're only dividing coordinates by 4, you're only looking at a discrepancy of a half pixel.

 

Incidentally, two more notes:

 

-1- If you want to move 10.75 pixels per frame, use '2' for the 3/4 adder and '1' for the 1/4 adder. Using '1' and '4' would work, but would produce jerkier results.

 

-2- Changing the adder may cause a slight discrepancy in the object's position. If the adder is only changed when the object's course is clearly disrupted anyway, this is not a factor. But if it's going to be changed on a regular basis, it should only be changed on frames that are multiples of four. Otherwise if the object's speed were 1.5 for 3 frames out of four and then 1.75 for the fourth, then 1.5 for three frames, etc. the object would only move 1 pixel per frame even though it should move faster than that.

You can take artistic license with the dragon, especially considering the limitations of the 2600. 12 frames is probably fine, as I have plenty of ROM space for it. I do notice, however, that the 12 frames does not include a fireball launch towards the upper players, so you might need a few more.

Maybe I haven't played the arcade game enough yet, but it always seems to shoot the fireball down. For the 2600 version though, I can "fix" this.

Turns out the dragon never launches the fireball "upward" - but that's only because he flies upside down when he's going to launch at a top player.

 

Of course, this is a cocktail cabinet game(at least the color version is), so the dragon wouldn't appear upside down to the player being fireballed. The dragon also appears to always launch the fireball at whichever human player "came online" first.

Wow, supercat, that's pretty interesting. Where'd you learn all this stuff?!?

Wow, supercat, that's pretty interesting. Where'd you learn all this stuff?!?

 

Here and there. There are some other variations on the concept, but the approach I suggest is probably the most straightforward and it should be quite usable for your purposes here.