[Done] Tyre Trax

[+Karl G]

I have recent experience with implementing high score saving via the AtariVox, so let me know if you need any assistance with that part and/or testing on real hardware.

[Stephbmx]

Hi, just tried the game, really beautiful!

Works great on my harmony cart

Just one thing, is it normal on the snow level that the color of most obstacles is the same as the road so you don't see them?

[+Muddyfunster]

Hi, just tried the game, really beautiful!

Works great on my harmony cart

Just one thing, is it normal on the snow level that the color of most obstacles is the same as the road so you don't see them?

 

Hi & thanks for testing it and posting feedback.

 

Some of the obstacles are supposed to be bit harder to see (the snowmen, polar bears). Do you think it's too hard like that?, would the "road" benefit from being darker ?

 

Thanks!

 

[Stephbmx]

the snowmen have more "not white" parts so it's ok, but the polar bears are almost invisible on the snow...

Maybe I just need more tries to get used to it, I haven't had time to play it very long... was just my first thoughts

[+Muddyfunster]

I have recent experience with implementing high score saving via the AtariVox, so let me know if you need any assistance with that part and/or testing on real hardware.

 

Thanks Karl. Scratching my head a bit though as i'm near out of variables to use and there are effectively 4 high scores (one for each game mode).

 

I'm thinking I'd have grab the high score at the start of the "course" from the atarivox and compare it at the end. Not sure how i'd display it.

 

I need to work through the code example for this, but even then, i'm not sure it would work in my game setting due to the different courses.

[Lewis2907]

I'm sure you know this, but some variables can be changed to constants and reused if not in use the cleared out before reuse. I did this is Save Earth with the map screen. Hope this helps.

 

I forgot about temps. There are 7, but I recall RT saying stay away from number 7. Temps are obliteratedd after drawscreen is called.

Edited September 25, 2018 by Lewis2907

[KevinMos3]

Just to address some of the great feedback received (thanks to everyone taking time to try the game) :

 

Decided against a jump function, it made dodging the obstacles too easy in a timed game.

 

... the original design for this game was for something of a twitch racer, short play time, competitive skill. This is something I intend to revisit for a potential sequel, maybe an "arcade" mode with score (and jumps)...

 

My thinking on the jumps was to have ramps to hit, rather than just jumping at any time with a button. This could be done in keeping with your intention of a twitch racer. Maybe there could be a line of obstacles that you have to hit a ramp to clear, or a water stream sprite that would slow you down if you miss the ramp, or you could place optional ramps ahead of some obstacles that could be seen as a risk vs reward (ex: do I try to hit that ramp to clear the obstacle and take the chance of missing the ramp, or do I just play it safe and dodge the obstacle?), or maybe you could shave a bit off your time by hitting a ramp just right instead of slowing down to dodge an obstacle in the harder levels.

 

Anyway, it looks great.

[+Muddyfunster]

 

My thinking on the jumps was to have ramps to hit, rather than just jumping at any time with a button. This could be done in keeping with your intention of a twitch racer. Maybe there could be a line of obstacles that you have to hit a ramp to clear, or a water stream sprite that would slow you down if you miss the ramp, or you could place optional ramps ahead of some obstacles that could be seen as a risk vs reward (ex: do I try to hit that ramp to clear the obstacle and take the chance of missing the ramp, or do I just play it safe and dodge the obstacle?), or maybe you could shave a bit off your time by hitting a ramp just right instead of slowing down to dodge an obstacle in the harder levels.

 

Anyway, it looks great.

 

Thanks KevinMos3 that actually makes way more sense now

[+Karl G]

 

Thanks Karl. Scratching my head a bit though as i'm near out of variables to use and there are effectively 4 high scores (one for each game mode).

 

I'm thinking I'd have grab the high score at the start of the "course" from the atarivox and compare it at the end. Not sure how i'd display it.

 

I need to work through the code example for this, but even then, i'm not sure it would work in my game setting due to the different courses.

 

 

Space Game has 3 different game modes (the default "Save Earth", "Infinite Play", and "Easy Mode), and it saves high scores from all 3 modes. If you do it the way I did it, you will need 3 persistent variables to hold a high score, but not any more than that.

 

In the case of no AtariVox present, those 3 variables hold the current high score for the current mode until the Atari is powered off. Everytime a game ends, it checks the final score of that game against the currently stored high score, and replaces it with the new one if it is higher. If it is not higher, it will switch between displaying the last score and the stored high score about every 2 seconds (with the high score being a different color).

 

Code-wise, the switching back and forth is done by using temp variables to swap what is stored in the 3 high score variables that I defined, and the 3 built-in score variables. E.g. put the values of the built-in score variables in temp1, temp2, and temp3, put the values of the saved high score variables into the built-in score variables, and the values of temp1-temp3 into the saved high score variables.

 

In the case of an AtariVox being present, it first checks for a high score being stored for the default mode, and if so, it loads that into the high score variables I defined, and displays that score on the title screen using the high score color. After playing a game, it will check the high score normally as it would without the AtariVox, but then writes it to the AtariVox to save as a new high score for that mode.

 

In the case of switching modes, every time it switches, it looks for stored high score for that mode, and displays it if found. New high scores will be saved to that mode.

 

I hope that gives you a rough idea at least. I'll post some code from Space Game later to see if that helps, too.

[+Karl G]

I'm sure you know this, but some variables can be changed to constants and reused if not in use the cleared out before reuse. I did this is Save Earth with the map screen. Hope this helps.

 

I forgot about temps. There are 7, but I recall RT saying stay away from number 7. Temps are obliteratedd after drawscreen is called.

 

I know the docs say to avoid temp7 in a bankswitched program, but I don't think it is actually harmful to use it so long as you know that the value will be wiped out anytime you do a bankswitch. It certainly won't mess up bankswitching in any way to put something there.

[+Karl G]

Here is the first part of the code I use for the cart version of Space Game that gets run at power on, right after the AtariAge splash screen. This routine first checks for the existence of an AtariVox by trying to read a byte from the area reserved for Space Game. RevEng's AtariVox driver puts a return code of $FF in the temp1 variable if the AtariVox/SaveKey is not detected. In this case, I set a bit (SaveKeyBit7) to 0 to indicate it was not detected, and return.

 

If the AtariVox/SaveKey is detected, I set the same bit to 1, then look at the value that I read from the device. If the value read is $FF, then that means this area of memory is uninitialized, and I go to a separate routine to initialize the memory (set all of the bytes I use to 0).

 

Finally, if the device is detected and doesn't need to be initialized, I put the first byte I read in the first variable I set aside to store the high score, and read the other two bytes, putting those in the other two reserved high score variables.

 

More code to come, but I thought it might be easier to parse if I broke it up a bit like this.

SubCheckHighScore
   drawscreen
   temp2 = AVoxReadByte(skbase, $80)
   if temp1 = $FF then SaveKeyBit7{7} = 0 : goto ___return_from_high_score bank1
   SaveKeyBit7{7} = 1
   if joy0up && joy0fire then FirePressedBit0{0} = 1 : goto SubClearSaveKey
   if temp2 = $FF then drawscreen : goto SubClearSaveKey
   HighScore1 = temp2 : drawscreen
   HighScore2 = AVoxReadByte(skbase, $81) : drawscreen
   HighScore3 = AVoxReadByte(skbase, $82) : drawscreen
   goto ___return_from_high_score bank1
/* End SubCheckHighScore */

[+Karl G]

Here's the routine that initializes the appropriate part of the AtariVox/SaveKey if needed. It gets called from the SubCheckHighScore routine if it detects the space is uninitialized, and it gets called if the user chooses to clear high scores (in the case of Space Game, the user can do this by pressing the joystick button while pushing up right at power-on).

 

This is pretty straightforward, but I should note that I am clearing out 9 bytes here that are needed to save the scores of all 3 game modes. I was allocated 64 bytes for the Space Game cart (probably that's the minimum), and I'm leaving the other bytes alone in case I want to use them in future games, instead of requesting a new block.

 

SubClearSaveKey
   temp2=AVoxWriteByte(skbase,$80,0):drawscreen
   temp2=AVoxWriteByte(skbase,$81,0):drawscreen
   temp2=AVoxWriteByte(skbase,$82,0):drawscreen
   temp2=AVoxWriteByte(skbase,$83,0):drawscreen
   temp2=AVoxWriteByte(skbase,$84,0):drawscreen
   temp2=AVoxWriteByte(skbase,$85,0):drawscreen
   temp2=AVoxWriteByte(skbase,$86,0):drawscreen
   temp2=AVoxWriteByte(skbase,$87,0):drawscreen
   temp2=AVoxWriteByte(skbase,$88,0):drawscreen
   HighScore1 = 0 : HighScore2 = 0 : HighScore3 = 0
   goto ___return_from_high_score bank1
/* End SubClearSaveKey */

[+Karl G]

Here's the routine that actually writes the high score. I set the MemOffset variable to the second part of the base address I was given, which works for the default mode (Save Earth). I add 3 if it is in the second mode (infinite Play) and add 6 if it is in the third mode (Easy Mode). I use my variable when doing the writes so that the score is saved to the correct place based on the current game mode.

 

That's it for now, but let me know if you need any assistance with any of this.

 

SubWriteHighScore
   MemOffset = skbase2
   if InfinitePlayBit1{1} then MemOffset = MemOffset + 3
   if EasyModeBit7{7} then MemOffset = MemOffset + 6
   drawscreen : temp2=AVoxWriteByte(skbase,MemOffset,HighScore1)
   MemOffset = MemOffset + 1
   drawscreen : temp2=AVoxWriteByte(skbase,MemOffset,HighScore2)
   MemOffset = MemOffset + 1
   drawscreen : temp2=AVoxWriteByte(skbase,MemOffset,HighScore3)
   return thisbank
/* End SubWriteHighScore */

[+Muddyfunster]

Karl.that's great, really appreciate the help. I read about using Stella to fake AV highscore read/write, not sure how that works but I'm going to give it a look so I can at least test using the guide code you provided.

 

3 variables, I can probably just about muster

[+Karl G]

Testing in Stella is the easy part. You can set the controller for port 2 for you ROM to AtariVox, and it will emulate the EEPROM.

[+Muddyfunster]

if the driver puts $FF into temp1, I guess it cant be used with Spiceware's sound driver which also uses temp1?

 

http://atariage.com/forums/topic/213203-sound-effect-driver/?hl=%2Bsound+%2Bdriver&do=findComment&comment=3776679

 

going to experiment on this now.

Edited September 27, 2018 by Muddyfunster

[+Karl G]

I really doubt you would have any reason to call his sound driver in the midst of reading from or writing to the EEPROM.

[+Muddyfunster]

So far I've spend about 8 hours trying to make some progress with the AtariVox code. ($%&$£%!!)

 

Right now, the check to see whether an AV is present seems to be not working. I launch Stella with -rc atarivox and I check Stella, yup Atari vox is showing in the right controller, my code behaves as though an Atari Vox is present. So far so good.

 

If I start Stella without the -rc atarivox option, my code still behaves as though AV is present.

 

conclusion : something wrong with my code to validate whether AV is present or not. I've tried to work through the example in the AV driver thread and also your examples above as they make sense to me (I'm using $3010 as my base from the scratch pad area).

 

My validation code is called right after dimming the vars for the rom, is just a simple goto to check for the presence of the AV :

avcheck
 rem read from the scratch pad i'm using to test, to see if it fails or works and sets the temp1 value.
 
 temp2 = AVoxReadByte($30,$10)

 rem if $ff is returned, then no AV present, set bit6 to off and go to start/restart, else set bit 6 to on and go to start restart.

 if temp1 = $FF then _bit6_savekey{6} = 0 :goto reset bank1 

 _bit6_savekey{6} = 1
 
 goto reset bank1

Later on I have code to check for bit6's status with the idea of ignoring various pieces of code if no AV is present.

 

My setup function (called when a game is started from the title screen) checks on the status of bit6. if it's on, then it calls a subroutine to grab that game numbers' hi-score and store it. Finally I have a piece of code in my game over screen to check on bit 6 and skip the high-score routine if the bit isn't set.

 

Nothing works right because I think the validation is wrong and I don't know why.

Edited October 1, 2018 by Muddyfunster

[+Karl G]

I think it may not be the code, but may instead be Stella saving your setting for the right controller to be an AtariVox (at least until the next compile). When testing for no AtariVox, try launching with "-rc joystick" instead of "-rc atarivox" and see if you get the same result.

[+Muddyfunster]

Thanks Karl, I tried that and recompiled, relaunched with that -rc joystick option, exact same result. I checked manually and Stella reports a joystick (as expected).

 

If my code is ok, I really have no clue what's wrong.

[+Karl G]

Well, there could be an error with the bit of code that checks your bit value. Are you familiar at all with the Stella debugger? You can launch your ROM with the -debug option to go straight into the debugger, then type the following in the console:

 

break avcheck

 

This will have it pause once it gets to your avcheck label. Type "run" to get it to run until it hits that point, then hit the "step" button to have it step through your code, seeing if it detects the AtariVox in each case. You can also add more labels to your code before recompiling to make it more obvious what section of the code you are in for clarity. E.g.:

avcheck
 rem read from the scratch pad i'm using to test, to see if it fails or works and sets the temp1 value.
 
 temp2 = AVoxReadByte($30,$10)

 rem if $ff is returned, then no AV present, set bit6 to off and go to start/restart, else set bit 6 to on and go to start restart.

 if temp1 = $FF then _bit6_savekey{6} = 0 :goto reset bank1 

avox_not_detected
 _bit6_savekey{6} = 1
 
 goto reset bank1

Also, if you want someone to take a look at your code, I'm willing to look and see if I can figure out the issue.

[bogax]

So far I've spend about 8 hours trying to make some progress with the AtariVox code. ($%&$£%!!)

 

Right now, the check to see whether an AV is present seems to be not working. I launch Stella with -rc atarivox and I check Stella, yup Atari vox is showing in the right controller, my code behaves as though an Atari Vox is present. So far so good.

 

If I start Stella without the -rc atarivox option, my code still behaves as though AV is present.

 

conclusion : something wrong with my code to validate whether AV is present or not. I've tried to work through the example in the AV driver thread and also your examples above as they make sense to me (I'm using $3010 as my base from the scratch pad area).

 

My validation code is called right after dimming the vars for the rom, is just a simple goto to check for the presence of the AV :

avcheck
 rem read from the scratch pad i'm using to test, to see if it fails or works and sets the temp1 value.
 
 temp2 = AVoxReadByte($30,$10)

 rem if $ff is returned, then no AV present, set bit6 to off and go to start/restart, else set bit 6 to on and go to start restart.

 if temp1 = $FF then _bit6_savekey{6} = 0 :goto reset bank1 

 _bit6_savekey{6} = 1
 
 goto reset bank1

Later on I have code to check for bit6's status with the idea of ignoring various pieces of code if no AV is present.

 

My setup function (called when a game is started from the title screen) checks on the status of bit6. if it's on, then it calls a subroutine to grab that game numbers' hi-score and store it. Finally I have a piece of code in my game over screen to check on bit 6 and skip the high-score routine if the bit isn't set.

 

Nothing works right because I think the validation is wrong and I don't know why.

 

I know nothing of what you're doing

don't you want to be testing temp2?

[+Karl G]

 

I know nothing of what you're doing

don't you want to be testing temp2?

 

RevEng's AtariVox driver puts a $FF in temp1 if there's a read error. That's why he is putting the value read (if any) in temp2, but first checking temp1 to check for a read error return code from the driver.

[+Muddyfunster]

PAL60 conversion complete, comparison images on first post. It surprised me how different in some areas the palette can be.

 

Atari Vox support for saving score time is challenging at best (Big thanks Karl G for the help and guidance).

 

Short version is : yes I can get it to work, but to have it work in a final version, would require a complete code reorganization.Jury is out on this one for now.

 

Anyway, some updated screen grabs on post 1 for your viewing pleasure,new title screen, PAL 60 version and NTSC version.

Edited October 9, 2018 by Muddyfunster

[+Muddyfunster]

So, I think i'm complete with this one.

Edited October 12, 2018 by Muddyfunster