Jump to content
  • entries
    650
  • comments
    2,606
  • views
    870,345

Warlords Status Update

Sign in to follow this  
Guest

2,363 views

I'm down to 8 RAM variables to decipher and have 108 labels renamed1 with 214 to go. A couple interesting finds:

  1. each player's paddle is only read every 4th frame. There's a couple subroutines, that I named SmoothXmotion and SmoothYmotion, that are used to smooth out the motion over the 4 frames between paddle readings. As a test I changed subroutine to NOP the smoothing and the motion was very jerky.
  2. Paddle usage had me confused for a little bit:
    1.  
    2. Paddle 2(INPT1) controls either the purple shield or the blue shield depending on the number of players.
    3. The Green Player uses Paddle 3(INPT2) - but is only human controlled during a 4 player game. Instead, paddle 4(INPT3) becomes active during a 3 player game.

1 labels generated by distella are of the format LMMMM where MMMM is the memory location of the ROM. Renamed labels are more human understandable - such as StartOfFrame instead of LF047.

 

Warlords_Source.zip

Sign in to follow this  


11 Comments


Recommended Comments

Guess it probably makes sense that they don't read all the paddles every frame, though I have come up with a technique to do precisely that.

 

Hopefully you'll figure out what some of the ball status things do. It looks like $EB ties in with them somehow.

Share this comment


Link to comment

I'll have to check your routines out when I'm ready to hack - even if I can't check all 4 paddles, reading 2 per frame would be much better.

 

With a few exceptions, I've pretty much been working from the top down. Last night I was working on the section I'd previously labelled PositionFireball(based on the STA BallY line). After the work last night, I don't think PositionFireball is an appropriate label and will most likely be changing that this week. I think I'll find the real PositionFireball routine in the overscan section.

 

Any input on the graphics.h? I found using 0s and 1s to be to difficult to see the shapes.

Share this comment


Link to comment
I'll have to check your routines out when I'm ready to hack - even if I can't check all 4 paddles, reading 2 per frame would be much better.

 

Reading two paddles per frame, if were always the same two, would not be too bad. But sometimes reading 1&2 and sometimes reading 3&4 would be a major pain in the tusch.

 

Actually, reading one paddle per frame does allow a nice simplifying trick (see "reading paddles in your spare time" in my blog) but reading all four is actually not too horrible.

 

In any case, I would not expect to change how Warlords reads paddles without doing a complete rewrite of the game. I think such a rewrite could be a very good thing, since replacing the kings with squares would allow for three balls to be bouncing around the screen simultaneously without flicker. Such a change would probably push the game beyond the realm of a 4K cart, but would so much improve gameplay I think it would most certainly be worth it. BTW, I'd make the "catch" rule specify that you could catch a ball and hold it as long as you wanted unless/until another ball hit your paddle, in which case that ball would bounce and the ball you were holding would be released.

Share this comment


Link to comment

The way the smoothing routine works it wouldn't matter as long as this frame I read 2 paddles, next frame I read the other 2 paddles, then the 3rd frame I'm back to the first 2 paddles and so on. That way each paddle's read every other frame instead of every 4th.

 

It's definitely going to an 8K - the 4K is used except for a couple bytes.

 

I'm leaning towards using playfield to draw the king shapes. Currently the kings are drawn by modifying the missile width - so there's 2 TIA updates. I think if I change it to toggle the SCORE bit of CTRLPF then the king shape would be the right color plus it's still only taking 2 tia updates. (of course there will be new tia updates to conrol the missile fireballs...)

Share this comment


Link to comment
I think if I change it to toggle the SCORE bit of CTRLPF then the king shape would be the right color plus it's still only taking 2 tia updates. (of course there will be new tia updates to conrol the missile fireballs...)

 

I hadn't thought of using SCORE that way, but that would seem like an excellent approach especially since those writes would be in parts of the scan line where you wouldn't really be wanting to do much anyway (the real burst of activity would be in hblank).

Share this comment


Link to comment
I hadn't thought of using SCORE that way, but that would seem like an excellent approach especially since those writes would be in parts of the scan line where you wouldn't really be wanting to do much anyway (the real burst of activity would be in hblank).

 

If you can afford the temporary storage, there are plenty of cycles available if you do that. If you want single-line positioning of your projectiles and want them to be 3 or 4 scan lines high, and if you want the rows of bricks to be four scan lines high, I think the most cycle-efficient way to do things is to use a 4lk where each line "starts" with:

 ldx #ENABL
 cpy bally3a; On first scanline, bally3a; next line bally2a; then bally1a; then bally0a
 php
 cpy bally3b
 php
 cpy bally3c
 php

 

This requires using 12 bytes to hold slightly different versions of the three ball positions but is very cycle-efficient. The memory for the castles should be interleaved so that the same loop index can be used for those accesses as everything else.

 

BTW, if you want the bricks to be 6 scan lines high and the balls three scan lines high, you could reduce the memory requirement for the balls to 9 bytes. The brick data would have to be stored one byte per six addresses. In that case, interleave the left and right player's brick data together, and interleave the top half of each person's castle with the bottom half.

Share this comment


Link to comment

I suspect free space won't be an issue - redoing the way the bricks are stored will free up 32 bytes, plus there's 2 unused bytes already. Triple fireballs will use up some of that, as well as giving the fireballs more degrees of motion.

Share this comment


Link to comment

I gave up deciphering the source in order to work on my own version. I'm sure I'll do some more delving into Warlords' source if I need some insight.

 

That said - I fired it up in Stella and did a trap on INPT0. It reads it from scan line 59 thru 206, but not every scan line.

 

59-91 is every 4th scan line

91-131 is every other scan line

skips 5 scan lines

136-178 is every other scan line

178-206 is every 4th scan line.

Share this comment


Link to comment
That said - I fired it up in Stella and did a trap on INPT0.  It reads it from scan line 59 thru 206, but not every scan line.

 

I did a couple of blog entries on reading paddles. The approaches, used together, might be suitable for a Warlords-style game.

Share this comment


Link to comment
59-91 is every 4th scan line

91-131 is every other scan line

skips 5 scan lines

136-178 is every other scan line

178-206 is every 4th scan line.

That's...insane. :cool:

 

Wacky.

Share this comment


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