Yes, I probably should. Theoretically, crabcakes should disable hooks when it starts and reenable them when it quits, so that stuff like this doesn't happen.


Also, Aichi, you might want add a limit to the speed at which you can get collision damage. The problem is that if you accidentally ram a wall or a boss, you instantly die. This is especially true if the level 4 boss teleports inside of you

R works as a permanently switcher in my game.

Code: [Select]

(R=0)->RIf R is 0, it gets 1, otherwise it gets 0.
I use it to simulate moving 0.5 pixels per frame and I thought it doesn't matter what R is at the start,
so I didn't initialize it. Thanks a lot for finding that bug. You'll get an entry in the special thanks if you want.
And which shell do you use on the real calc?

I'm not sure why your code didn't work, but anyways, the enemies problem is gone. I also use Mirage on my calc (never going to change.)


But the pause glitch is still there. It appears that the game crashes right as it's about to display "[Del] Exit". You can see the white menu appearing, and right when it's about to display that, it crashes. I tried running it in all 3 shells on my calculator, and it crashed in all of them. But I really have no idea why it doesn't crash on the computer though. The only thing I can figure is that wabbitemu and the computer have slightly different interrupt timings or something like that.

And a poke about + / - for contrast changes.

Edit:
    It also crashes when you beat a level, the white scrolls to the top of the screen and when it gets there, crash.

Well, I'm not having much luck with this. I've run it about 8 times in wabbitEmu and 8 on my calculator both in ram and archive and only once have the enemies appeared.

One possibility that I see is that an area of memory is not properly initialized, but really I don't know.

Also, whenever I pause it on a real calculator, it crashes. The screen turns off and when it turns back on, it looks like 15 rows have been cleared at the bottom.

Sorry to be the bringer of bad news, but I'm looking for the cause. (Although I'm doing it from an asm standpoint which isn't very effective.

Edit:
    This is a good one. It only works in DoorsCS. The moment you run it in Mirage, you have to clear ram in order to make it work again in DCS. This makes it seem like some variable is not properly initialized.

Edit2:
     Found It!!!!!!! When the program starts, you forgot to clear ($89D8). If my guesses as to how axe works are correct, then that should be around variable "R". Someone who knows more than me about axe could probably tell you exactly which one it is though.

And btw, that took way to long to find

Edit3:
     Yes, that should be "R". Axe.inc says so.

Whether or not the enemies show up appears to be related to where it is in the archive. Because if the enemies aren't showing up, a few unarchive/archives later they will.

Edit:
    I don't know what the exact cut off is, but I know that if the program is at $6b71 on a flash page or lower, the enemies work. And $75B9 and higher does not work. So it looks like you have some weird work on your hands that probably isn't related to any code you've written. This is most likely asm related.

Welcome back Jerros!

The solution is actually easier than you think
ld a, $BF
out (01), a

ld a, (keyStates) ;for our case, this is a better option
ld b, a ;than just putting nop \ nop
ld c, 0

;b is what was pressed last loop
;c is what is pressed this loop


in a, (01)

;bits 0 to 4 are:
;graph, trace, zoom, window, y=

rrca
call nc, graphPressed
rrca
call nc, tracePressed
rrca
call nc, zoomPressed
rrca
call nc, windowPressed
rrca
call nc, yEquPressed


ld a, c
ld (keyStates), a

jp anywhere



graphPressed:
push af

set 0, c ;graph is pressed this time
bit 0, b
jr nz, graphIsHeld


;do stuff here for graph is being pressed
;remember not to kill bc

jr graphDone

graphIsHeld:

;do stuff here for graph is being held
;again, don't kill bc

graphDone:
pop af
ret

So the general idea here is just to call a subroutine for each key. That subroutine will handle what needs to be done, and it will return so the rest of the keys can be checked. I also did a clever thing with BC there because unlike getCSC, using direct input like this will report the keys ever frame, not just when they're pressed. So when a key is pressed, checking the state of B, you can see whether it is being held, or is being pressed.

With this routine, you can finally implement both held notes and chords. 

Are there any enemies in the demo level?

Anyways, the game looks great. I can't wait for the release. One suggestion I would have is to make + and - adjust the contrast. Most people have their calculators set up for black on white. So since this game is white on black, it takes a different contrast setting. (Typically down 3) And of course, be sure to restore it when they quit.

I think I also found two glitches.
1. LN + {4,5,6,-} moves right and x^-1 + {sin,cos,tan,^} shoots. I'm not sure whether this is axe or you, but either way it's strange.
2. I don't know if this is a glitch, but when bullets bounce off walls, they don't turn around.

Wow, I am so impressed. I remember back 6 months or so when you posted a help topic and I downloaded the game, I thought that certainly you would never finish the game or that it would just turn out terrible.

But I was wrong. This is the most shocking release I've ever seen. I saw the title and I thought, "That can't be jerros," and sure enough it was. Basically, I am so happy you finally got it to work.

Edit:
   I just watched the whole thing. Do you think you are going to add chords and held notes? Because as far as I can tell, those are the only things you are missing. I've beat TTFAF quite a few times so that was fun to watch.

* Darl181 wonders if there is/will be an updated readme to cover all the awesomeness that's been added over the past month or so

Haha, ok Darl. Next time I do a serious update, I'll add a readme.