Just curious, will you have the option to skip the intro at the beginning of the game?

Looks pretty nice. Also I like that boss

Just as an head up since you are new to the era of TI programming where animated screenshots are legion in calculator program showcases (as back when you were very active, no animated screenshot tool actually worked at all): In reference to one of the screenshot of the game you posted (that showed an incredibly long text intro) It's generally a good idea in a screenshot to skip directly (or within the first 5 seconds) to the actual gameplay or graphical intro stuff (if any), so that we do not have to wait half an hour for the text portion of the intro to finish. Otherwise, some people will not bother waiting and they will think that all there will be in your game is text. Since it's gonna be updated in the future, it might be a good idea when you upload your updated file in ticalc.org archives to tell the staff to remove that screenshot from the archive page, to prevent people from fearing they have to go through a very long intro before starting the game.

It's ok though. At least you didn't wait 10 minutes into the screenshot before actually starting the game.

I'm very impressed with the darkness effect!  I've seen kinds of raycasted shadow based systems before, but imo those systems have always been a bit sluggish.  Yours, while it doesn't cast shadows, is nice and fast and I think is the best overall way ^^

I'm curious how you did that, is it just a large mask masked over your tilemap? I dunno how your tilemapper works, but i guess you could even update only the center part of the screen. It looks great and in my opinion much more elegant (and probably much less of a headache to code ) than those clunky blocks you often see. It's essentially a little radar

• Based on the player y position on screen, calculates if any full horizontal lines (12 bytes of $FF on gbuf) are required at the top / bottom of the screen (outside the bounds of the circle).
• For each horizontal line on gbuf that incorporates the actual circle "mask", it generates a 23 byte-long line, which consists of 8 x $FF bytes, followed by the 7 bytes (56 pixels) of correlating data from the circle image data, and followed by a further 8 x $FF bytes. Having this buffer then covers all possibilities of the player x position on screen.
• Based on the player x position on screen, calculates which section of the 23 byte buffer is required, bit shifts that particular portion accordingly, and then applies it to the horizontal line on gbuf by "or"-ing it with each of the 12 bytes.

Looking awesome.