Jump to content
  • entries
    657
  • comments
    2,699
  • views
    899,818

Research


SpiceWare

1,261 views

I've decided to play Warlords in MacMAME today to get some ideas on how the game dynamics should work. An example of what I'm researching is what happens when a fireball is released:

 

blog-3056-1144025288_thumb.png

 

A fireball is only released perfectly straight (up or sideways) when you are nearest an edge of the screen. When you're at the corner of your castle you'll release at 45 degrees. Anything between will be released at a different angle depending on how far you are from the edge. I still need to take some notes on how the fireballs bounce off things.

 

I'm also down to 5 non-contiguous bytes of free RAM so I need to free up some RAM before I can do anything else(dragon sprite, sound effects and so on). One change will be to revamp the fireball routines. Currently each fireball takes 10 bytes of RAM: 2 for x position, 2 for y position, 2 for x direction/speed, 2 for y direction/speed and finally 2 more for the "odd/even scanline" values used by the Kernel to make the fireballs bigger(see the picture in 3 fireballs for the smaller fireballs). I cannot change the 6 for the x-y positions, but I can change the 4 bytes for the x-y speed/direction to be a 1 byte value for a lookup table. The byte will be formatted like this:

76543210

7 - 1 = fireball captured, 0 = fireball moving

654 - 8 speeds

3210 - 16 directions

 

I'll need 1 additional byte to track who holds which captured fireball. By making these changes I'll free up 8 bytes for other use.

12 Comments


Recommended Comments

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.

Link to comment

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.

 

s_Dolphin_1.png

Link to comment

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.

Link to comment
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:

 

warlords_dragon.gif

Link to comment
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 :_(
Link to comment
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:

 

warlords_dragon.gif

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.

Link to comment
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. :_(

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

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