Trouble with the Titlescreen Kernel

[+Muddyfunster]

For the last 2 weeks I've been trying to figure out why my game (Tyre Trax) is misbehaving.

 

I didn't realise that I had a real problem until I got my Harmony Cartridge and was able to test on real hardware. After completing every 2nd race (without fail) the program either resets (back to the title screen - game 1, not the last game executed) or crashes. In Stella it usually just "resets" back to the title screen so I had it as a minor bug I need to look into as I finish up. In reality, on real hardware (for me at least) it crashes every 2nd play through.

 

I thought it might be something in my latest version, but no, it's in every version I've compiled going back to September or so.

 

I added a skip function so I can jump to the end of the race, receive the trophy and back to the title screen. No problems.

 

Play through 1 race : no problem

Play through 2nd race, issue seems to be on transition from the end (trophy) screen to the title screen. (it resets the cart like it was just inserted and switched on, or it freezes up).

 

I've rebuilt the titlescreen thinking that I'd maybe introduced some bug along the way, no joy. I've even gone back to a plain default out of the box titlescreen, no joy.

I've removed the custom sound driver, no effect.

I've removed the custom score graphics file used in the timer, no effect.

 

Only time anything changes is if I remove the title-screen kernel call, then problem goes away and the game plays flawlessly every time (but no title screen obviously..)

 

I'm pointing the finger at titlescreen kernal by process of elimination, but I understand its likely something my code is doing to upset it, and it's not really the title screen at fault all, I just don't know enough about what to look for in Stella's debugger to know what could be causing a problem that I can identify.

 

If anyone here with more experience can help I'd appreciate it. I've attached my last binary. If anyone wants to check the bB code, let me know.

 

The binary attached has the detection removed for hitting the river so you can just drive in the water and zoom to the end of the level for testing.

 

I hope someone can guide me on the problem otherwise I'll end up having to scrap the title screen and code something simple in it's place to get the game completed.

 

/fingerscrossed.

 

 

tyre_trax_n_v201o.bas.bin

[+Lewis2907]

My guess would be variables being reused or reset (not executing properly). I had a similar problem in one of my programs. Just a thought, yours is probably more complicated though as your program is longer and more complicated that I was working on. Hope this helps in problem solving the issue.

[+Muddyfunster]

Thanks Lewis, That's something I haven't checked yet.

 

I do reuse a variable, but it's in two sections of code that never touch, so I figured that would be safe to reuse.

[waderain]

I had this happen and it turned out to be a bank switch problem. I would go into the correct bank but didn't have the correct return making the game restart.

[+Gemintronic]

I usually use the titlescreen editor in VisualbB. I hit the preview button and while the emulator is running I scrape up the temporary "titlescreen" folder and put it into my proper project folder.

 

I put the title screen event and title music playback engine and data in bank 1. Bank 2 is the main game. Bank 3 has general routines (that can afford the bankswitch CPU cycle penalty) and game win / game over events. The titlescreen.asm is loaded in bank 4.

 

This 16k layout is more than just personal preference: it has saved my arse many, many times.

[+Lewis2907]

Thanks Lewis, That's something I haven't checked yet.

 

I do reuse a variable, but it's in two sections of code that never touch, so I figured that would be safe to reuse.

[+Lewis2907]

From what I recall the variable carries over unless changed before it's used again. Example

 

dim save = a

dim game_over = a

 

Unless changed before use or something in that nature. "a" is keeping the same value. My work around was using const save = 1.

 

Also the temp 1 to 7 can be used as well, but the value is "obliterated" per RT site once drawscreen is used. That caused me some issues as well. So I started to use const and bits (I'm still learning more about there use and limitations).

 

Hopes this helps from what happened to me or gives you another angle to look at the program, thanks.

Edited December 1, 2018 by Lewis2907

[+Karl G]

My first guess would be a gosub that never returns when you restart a game, causing the stack to build on each iteration, overwriting other stuff.

 

My second guess would be bank-switching related like waderain suggested - using the wrong return can cause weird problems.

 

I can take a look at the source if you remain stuck, though it will be a few days before I'll get a chance to look at it.

[+Muddyfunster]

Thanks for the feedback guys, I at least have some new leads to check out.

[Lillapojkenpåön]

That has happened to me when using on goto

 

on a goto _0 _1 _2 _3 _4

 

and the code that made shure the a variable goes from 4 to 0 was skipped under certain circumstances resulting in a number that had no label

 

it could happen even if you just used if thens

 

if a = 0 then goto _0

if a = 1 then goto _1

if a = 2 then goto _2

if a = 3 then goto _3

if a = 4 then goto _4

 

if it's not one of those numbers it will fall through to whatever is underneath it which can result in crash and resetting to titlescreen

[+Muddyfunster]

Thanks for the suggestions. I've spent hours checking through my code (the audit Goto/.Gosub in Vbb is very useful).

 

I found a couple of pieces of code that I'd moved from one bank to another and they had the wrong "return", using "RETURN THIS BANK" instead of "RETURN OTHER BANK".

 

I corrected that but the problem still persists.

 

I only use "ON..GOTO" once and that looks fine (swapped it to multiple IF statements just to check and same result).

 

I don't think the issue is code falling through because of a condition not being met.(but i'm no expert on this).

 

Going to check again this evening with a fresh pair of eyes.

 

I corrected that but the problem still persists

[+Karl G]

Try commenting out the "gosub titledrawscreen" line from your titlescreen loop so that you will be running all of the associated code without actually calling the titlescreen code itself. See if you can reproduce the problem still. This may narrow the cause a bit.

 

Edit: re-reading this, I see that's what you already tried.

[Coolcrab]

I wouldn't mind taking a look at the code if you want. Can't promise anything as this is more advanced than my stuff, but I'm relatively good at spotting errors.

[+Muddyfunster]

Try commenting out the "gosub titledrawscreen" line from your titlescreen loop so that you will be running all of the associated code without actually calling the titlescreen code itself. See if you can reproduce the problem still. This may narrow the cause a bit.

 

Edit: re-reading this, I see that's what you already tried.

 

Yep,

Worst case is I have to remove the title-screen kernel and code a replacement. It will be disappointing because the title-screen kernel is just so damned good, but not the end of the world.

[+Karl G]

 

Yep,

Worst case is I have to remove the title-screen kernel and code a replacement. It will be disappointing because the title-screen kernel is just so damned good, but not the end of the world.

 

I'm sure it's something fixable. To clarify my first guess, I am wondering if when you return to the title screen after completing a game if you are ever doing a goto from within a routine from which you did a gosub. In that case, the return from the gosub is never hit, and the return address remains on the stack. That would explain why it only happens after a game has been played, and not when you first start the game.

[+Muddyfunster]

understood

 

I have a single scenario where a subroutine can determine that the game is "over" and calls the game end code. Before that happens i'd need to call a POP to remove the return address before executing the end code. Going to try that now.

[+Muddyfunster]

Well KarlG has saved me from bB induced insanity.

 

I added a POP to cancel the gosub and BOOM it just worked. I just ran the game and had played through 15 times and not so much as a blip.

 

Thanks for the suggestions, & a big thanks (again!) to KarlG. I learned something new so I'm happy, even happier that my game is working

Edited December 5, 2018 by Muddyfunster