Yes I read your post the first time, though after much testing I could not see the "freezing". Now I do, By freezing I thought you meant locking up, What I see happening is you animations stopping, I don't consider that freezing, espeicially considering I had over looked that bug.L4E_WakaMol-King wrote:Jim e wrote:Under what function does this getkey loop occur? I can't even find a link to that. Rather Im seeing other bugs, but not this pausing bug.There is no endless getkey loop in my code that I can find... but that is what seems to be be happening because when the game "freezes" you can still run it if you hit any key over and over. The fact that it is caused by a getkey loop is speculation on my part.L4E_WakaMol-King wrote:In its current state, the game works fine.
If I add in a line of code at the beginning of the game to modify one particular memory address (a variable), the game "freezes."And by freezes, I don't actually mean freezes... it goes into some kind of strange pause mode and only works if I continually press any key.Code: Select all
ld a,0 ld (BOB_CASTING),a
If I replace that line of code with one that modifies any other memory address (a different variable, for example), the outcome is the same... still freezes the game when you run it.So, I wrote a piece of code so that every time I press ALPHA, the value of that memory address (BOB_CASTING) is displayed. The value is 205 as long as I don't modify it at the start of the program like I am trying to do.Code: Select all
ld a,0 ld (BOB_TALKING),a
Taking that into consideration, I changed the line of code in the start of the program to read:Still freezes.Code: Select all
ld a,205 la (BOB_CASTING),a
If I write a piece of code to modify that variable somewhere else in the game (on ALPHA keypress, for example), the game works just fine, even after (BOB_CASTING) is set to 0.
I have checked and re-checked to make sure that no variables are overwriting one another. That's not the problem.
I have also checked every one of my bcall(_getkey) statements, since the "freezing" seems to be stuck in some kind of getkey loop. None of them even get accessed until certain keys are pressed... so I don't think that is the problem either.
Also, see the comments in loom.z80 for a second description of the bug.
Well I meant replacing getkeys with getcsc and some extra code, but to fix dwedits fix, equate appbackupscreen to $9872.The appBackupScreen thing? Yes... and it generated a ton of 'Forward Reference' errors. I know what that means, but since ion.inc is included before any references to appBackupScreen are made, I shouldn't be getting those erros . The reason that I use appBackupScreen instead of just $9872 is for portability.Jim e wrote:Did you try dwedits fix?
Well okay its obvious that something is going wrong in the idle call. I look more into it later.