SpiceWare's Blog

Seems about the same to me - I think he's just getting better. It didn't take me too long to figure out a way around each of the enemies. The trick is executing it consistently.

I like the DEMO text, but I'm not so keen on the flicker. It would be better if you could just remove the HMOVE bars, as there isn't any sprite shifting going on while this text is displayed?

 

Chris

Could you put the Demo text at the bottom where the scores are (since there doesn't need to be any scoring kept during the demo?)

Just noticed a bug when looking at the demo mode. If one of the players on the right holds the ball for too long, the ball wraps around the edge of the screen and starts destroying the walls on the left side. This doesn't seem to happen for players on the left.

 

Chris

Maybe I'll bump up the AI players a notch on the Medieval levels.

 

Have you viewed it on a real Atari? I find the flicker slightly annoying in Stella, but it looks fine on the console. Removing the HMOVE bars may be an option, I can check into it when I implement the final dragon as the demo message uses the dragon routines. Redoing it without HMOVE would also give the time to make all 3 fireballs visible while the message was displayed.

 

Moving DEMO to the score line is an idea - though I have a to-do of leaving the scores from the last game displayed during demo mode.

 

Yeah, the fireballs do wrap when held. It happens during the game too. Is it really taking bricks out on the other side? The wrapping should be in the same row as the shield when they're facing up/down.

 

Hmm - just saw a demo game where an AI player won the match in less than 75 seconds. The score for that player then freaked out until the game went back to the menu. Good thing the digits aren't in page $FF else I'd probably had another incident of mysterious resets of the system.

Yeah, the fireballs do wrap when held. It happens during the game too. Is it really taking bricks out on the other side? The wrapping should be in the same row as the shield when they're facing up/down.

 

I though that it removed bricks on the other side, but I can't seem to recreate the problem. It is definitely wrapping though. It should be easy enough to fix by removing the ball when the coordinate is over (or under) a certain value?

 

Chris

I noticed it "wraps" on the left too, but it wraps to the right side of the left players so it looks like there's 2 flareups going towards the right.

 

It should be easy enough to fix by removing the ball when the coordinate is over (or under) a certain value?

 

Chris

 

 

in flareup routine: if fireball X > 158 then fireball Y = 100

 

This will stop the fireball from drawing for the current frame and Y will be reset by the captured-fireball routine on the next frame. The capture-release routines don't allow a release when the fireball is in a flareup position. They originally did and it was really bad if the flareup was behind your shield when you released the fireball.

 

I think values of 97 thru 127 would work to hide it. If bit 7 of the Y position is on the fireball is considered inactive and I believe it would just disappear.

I was hacking Paul Slocum's Music Kit 2.0 yesterday in preparation for main menu/ background music that I plan to be adding this weekend once moderntimes99 sends me the source for the music.

 

So far I've ripped out the "light show" code and analyzed the RAM usage. It appears I need to have 3 bytes of RAM that are preserved between calls to songPlayer and 4 bytes of RAM that can overlay my other scratch RAM variables. Stack usage is 5 bytes of RAM, though that can be reduced to just 2 by using 1 additional scratch RAM instead of a PHA/PLA and by inlining songPlayer instead of JSR'ing to it.

 

If this is correctly, I'll also be able to play music during the attract mode as I have 1 unused byte of RAM while the game is running and I can repurpose the 2 sound effect RAM bytes during attract mode.