Temple Runner - Help! (Batari Basic DPC+)

[TidusRenegade]

Hi everyone, I'm looking for a bit of help if possible

 

I decided to rewrite my Escape from Kukuku Temple game (including a much needed name change!) to create Temple Runner, which has been coming along nicely but I'm having a lot of problems with it running on actual hardware.

 

The problem seems to be with the number of lines exceeding 262 so I decided to do a whole clean up of my code and move bits around to dramatically reduce the number of bank changes (hence why in the attached source code you will see blank banks that used to contain stuff! - its a bit of a mess at the moment). This reduced down the number close to 262 but not under and I ran out of ideas of how to further optimise the code to reduce the number of lines. I added an extra drawscreen in the LevelLayout routine which gets the lines to a decent number but does cause a bit of screen jump between screens.

 

Big thanks to ZeroPage who has been doing some testing on actual hardware for me but he is still finding that despite all the optimisations it is still causing a crash on real hardware. Unfortunately it seems to run fine in Stella (although the number of lines does exceed 262 between the title screen and the first screen - not sure why?!) so its been hard to debug further and I'm running out of ideas.

 

Can anybody help on this please?

 

Hopefully I'm just missing something obvious which will allow me to optimise my code, remove the additional drawscreen and have it running nicely at 262 lines.

I'm guessing the alternative is to start butchering the code to remove game elements - screens etc.

 

Thanks in advance for any help with this

 

Ross (TidusRenegade)

Temple Runner t0.15.bas

Temple Runner t0.15.bin

Edited October 13, 2018 by TidusRenegade

[+stephena]

Can you also provide a binary; I don't have BBasic installed.

[TidusRenegade]

Done added to the original post

[iesposta]

Can you zip the Titlescreen Folder?

I can help more if I can compile the game.

I took out the Titlescreen, but I can't get a good compile.

 

Sometimes I have found this to be the problem. If fixes bouncing and line count (if you're not doing a ton of things per game loop which will just go beyond the cycles the processor has).

Before EVERY "drawscreen" in bB DPC+, you should set the fractional data queues:

   rem Re-writing it this way saves 7 bytes
   rem Below should be done before EVERY Drawscreen
  DF6FRACINC = 255: DF4FRACINC = 255
  DF0FRACINC = 128: DF1FRACINC = 128: DF2FRACINC = 128: DF3FRACINC = 128 ; Column 3.
   rem draw screen
  drawscreen

.

.

.

Some tips to avoid huge waste of processing (which causes bad line count):

 

A huge tip that saves ROM and processor cycles is to string same value variables on one horizontal code line.

The tradeoff for being a bit harder to read, is the ROM saves add up a lot, and the compiled assembly is faster if coded this way. (Long story)

batari Basic allows around 12 per line if I remember correctly. You can't do the whole alphabet=0 on one line. It won't compile. I've tried.

  gosub Quiet
  rem initial variables reset
  PlayerFrame=1: LevelNo=1: SpeedMult=1: SubLevelNo=1: BackLoop=1: P0Direction=1:  LevelLoad=1
  LivesNo=4
  Falling=0: Jumping=0: NoArrows=0: NoBats=0: Bat1Direction=0: Bat2Direction=0: BatFrame=0: NoRocks=0: Killed=0: GameOver=0: Interim=0
  rem reset score
  score=0

.

.

.

Don't "gosub label bank6" for something small. A gosub to another bank and back costs lots of processor time and ROM.

For the times you do code a gosub to another bank and back, use "return otherbank" at the end of the code.

"return" is okay if your gosub is in the same bank. May small subroutines -- especially for code that's duplicated over and over -- ends up at the end of the current bank.Q

For example in one bank you have a lot of quiet sound code.

If you make it a subroutine and "gosub Quiet" it will save 37 bytes, but it takes a bit more CPU time. Do this if you want ROM back.

Quiet
  AUDV0=0: AUDC0=0: AUDF0=0: AUDV1=0: AUDC1=0: AUDF1=0
 return
 

You probably can get away with just volume=0 in AUDV0=0: AUDV1=0 and don't worry about the channel or frequency being zero, or I have been kicking around keeping the volume and note where they are, and setting "AUDC0=0: AUDC1=0" because when that works, you are not changing volume register to 0 which can add noise by moving the speaker to rest (at 0) and the next note has to push the speaker out (at the next notes volume).

Try a short program of just setting the AUDV0=0 and/or AUDV1=0, to AUDV0=12: AUDV1=12, every other frame, and loop that through a drawscreen. You get a tone!

[TidusRenegade]

Thank you so much for all the detail in your response - I will try some of those changes now and see if they improve things

 

I've attached my title screen folder

 

titlescreen.zip

[TidusRenegade]

Thank you so much, adding the DFFRACINC lines right before the drawscreen has got rid of all the screen jumping problems!

 

I should also added ZeroPage's notes from testing on real hardware:

 

 

When finishing level 3 it resets to the title screen! After playing through it the second time at the end of level 3 the game flashes the screen a couple of times and then goes to black and doesn't come back. I reloaded the game and it did the exact same thing. Reset after level 3 and then crash after level 3 on the second playthrough. Seems like there's something that's different between a cold start and after finishing the game once. Maybe there's some random information in memory that's not zero'd out on first run?

 

I can't figure out from the code what would be causing this and I can't replicate it in the emulator

[iesposta]

Thank you so much, adding the DFFRACINC lines right before the drawscreen has got rid of all the screen jumping problems!

 

I should also added ZeroPage's notes from testing on real hardware:

 

I can't figure out from the code what would be causing this and I can't replicate it in the emulator

Forgot to add that I think there is a gosub without a return (or return otherbank), and I think that same code that is first called with gosub, is later called with a goto.

 

Every gosub must have a return, unless the subroutine is complex and a condition occurs that you dont want to return, you can change the gosub into a goto with the command pop.

If surprise=badluck then pop: goto Label

Not returning from a gosub advances the stack whatever that is, and if it fills completely you have a stack overflow which can crash or reset the program.

 

A gosub can call a gosub (even with goto(s) in the subroutine). But if you gosub down 3 times, you have to return from the last routine to the one that called it, and return from that second subroutine back to the first.

 

I hope that makes sense.

We used pop a couple times in the game I made wih Byte Knight.

Programmers say if you need to use pop, you should figure out how to correctly write a goto.

[TidusRenegade]

Thanks for the continuing responses.

 

Your right on the return otherbank - I had definitely missed that a couple of times - I've added those now. I couldn't find any missing returns though?! It hasn't helped that I've joined a lot of my code together to get the line count down so what was previously multiple routines are now a single routine ... so it can look like there should have been a return there.

 

Do you think the return otherbank could have been causing the real hardware crashes?

 

I've fixed it on the attached. Does anyone have a melody cart on which they could quickly test it to level 3? It would be very appreciated if so (and yes I know, I will buy one at some point!)

 

Thanks again

Ross

Temple Runner t0.16.bas

Temple Runner t0.16.bin