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

Demo Message


SpiceWare

702 views

Added a DEMO message that blinks during Attract mode. I had to also flicker the message due to fireballs disappearing when they travelled beneath the HMOVE lines.

 

blog-3056-1161651292_thumb.png

 

 

I also reviewed the AI routines and don't see anything that would cause the game to be easier than before. Has anybody else noticed this, or is Jacob just getting really good at dishing out some Mayhem?

 

If nobody sees anything issues tonight then I'll give this version to Al as the version for the Expo.

Medieval_Mayhem.zip mm20061023NTSC.bin mm20061023PAL.bin

8 Comments


Recommended Comments

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

Link to comment

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

Link to comment

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

Link to comment

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

 

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.

Link to comment

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

Link to comment

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

 

:ponder:

 

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

 

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.

Link to comment

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.

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