SpiceWare's Blog

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.

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.

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.

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

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

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.

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.

Forgive me for not reading the source, but does it read the paddles on every scanline?

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.

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.

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.

 

Wacky.