SpiceWare's Blog

This has got to be the shortest blog entry I've ever seen. Anyway, how do I control my thingee? I've tried everything and nothing works. I'm using Stella, BTW.

Paddles! Just tell the emulator to emulate them. Read emulator manual for details.

I haven't looked at this for a while, but the game is coming along nicely! The AI adds a lot to the game, though they do seem to be able to move very fast? I did notice a few screen rolls when 3 balls were on the screen, so I think there is a bit more optimisation required. However, the game seems to be getting close to completion now?

 

Chris

This has got to be the shortest blog entry I've ever seen.

Yeah, I haven't had much feedback lately, so I've been feeling like I've been taking to myself. Course school is starting up and then there's Ladybug.

 

Anyway, how do I control my thingee? I've tried everything and nothing works. I'm using Stella, BTW.

1. start Stella
   
2. load Medieval Mayhem
   
3. hit TAB, a menu will pop up
   
4. select Game Properties
   
5. on the CARTRIDGE tab set SOUND to STEREO
   
6. select the CONTROLLER tab
   
7. change both controllers to PADDLES
   
8. hit OK
   
9. hit EXIT MENU
   
10. restart the emulator for the change to take effect. Under OS X use APPLE R, under Windows and Linux use CONTROL R. You'll get a message "New Console Created" when it restarts.
    

Stella will remember the settings so you only have to do this the first time you try each release of MM.

I haven't looked at this for a while, but the game is coming along nicely! The AI adds a lot to the game, though they do seem to be able to move very fast? I did notice a few screen rolls when 3 balls were on the screen, so I think there is a bit more optimisation required. However, the game seems to be getting close to completion now?

 

Chris

Thanks!

 

I haven't done any fine-tuning of the AI players yet, it is planned. Currently each player moves at a different speed with 1(gray) being slowest and 4(purple) the fastest, so the game is hardest if you play as the gray shield and easiest if you play purple. Hmm - I should probably change that order I also plan to make the speed dependant upon the max speed of the fireballs plus how many fireballs are in play.

 

Did the roll happen when all 3 fireballs hit something? If so then I'll need to increase the "skip fireball processing" check. The fireball loop is basically:

for fb = 2 to 0 step -1
 if fb = 0 then
if hadcollision(fb) and INTIM < 9 then exit for
 end if
 gosub collision(fb)
 gosub move(fb)
next

 

Because the fireballs rotate, if processing of fireball 0 is skipped this round, it will be fireball 2 next round and will be processed. I figured an occasional 1/60th second delay of a fireball wouldn't be noticed. This never happens for PAL users.

 

Game itself is getting pretty close to being done. I've got a couple big parts left though - I need to revamp the main menu to scroll up/down so I can add the missing settings. I also have the dragon routines to do once the graphics are ready. I'm hoping to have everything done early October for a code freeze, then I'll add the easter egg while play testing is going on. The easter egg is basically going to be a credits screen listing those who've helped(code suggestions, helpful feedback from playtesting and so on). I'll be dropping notes to people at that point to confirm (or get) their real names for the listing.

I think I found my time - the routines to determine the fireball to track are based on a^2 + b^2 = x^2. To simplify the process, I have tables holding pre-calced ^2 values and don't worry about taking the square root of the results of a^2 + b^2.

 

The numbers are so big I was using 16-bit math. There are up to 9 (3 living AI players, 3 fireballs) additions followed by up to 6(3 living AI players, M0 vs M1 followed by either M0 vs BL or M1 vs BL) compares to determine which fireball to track.

 

Last night I modified the formula to use a^2/100 + b^2/100 = x^2/100. The a^2/100 values are stored in a single byte per value instead of storing low/high bytes per value for a^2. After that I modified the 16-bit additions and compares to use 8-bit additions and compares. Results are extremely promising - I haven't seen a single instance of incorrect scan line count since the change.