I was doing laundry again today, so I brought my calculator and wrote a routine for animated tilemaps (variable speed animating), that uses masked sprites. Since I didn't want to write out a custom LCD updating routine, I ended up using a bcall (EF6A48, whatever it is actually called). I also am using an OS getkey routine (EF4447) and both are slowing it down quite a bit Basically, when I get around to cleaning it up with better, faster routines, this will be quite a bit faster o.o As it is, on an actual calc it handles grayscale very nicely (I used an animation scheme of two properly dithered tiles). Here is a screeny, showing the masked nature of the tiles, as well as the variable speed of the animations

I figured I would share since this topic is what inspired it If I find the courage to convert this to a scrolling tilemap, (and if we go with using an app for some codes like this), I'll be sure to update y'all

That version in the screenie updates the LCD every single frame, even if nothing has changed. The grayscale tiles update every frame, the ones in the middle-ish of the map update every 5 frames and the ones on the outer edge update once every 16 frames. I'm pretty sure speed won't be an issue, and even if I add the variable speed to the Axe version, it will only add a thousand cycles or less (still keeping it >60FPS). I am still trying to figure out a more clever and efficient method for this, though. It will be particularly difficult to smooth scroll the map with masking and a player sprite on it

Yeah, my hope is that we can come up with pretty efficient algorithms that will only slow things down a little. My guess is that at this rate, the most major slowdowns will cause the animation to slow to about 40FPS with a bunch of activity on the screen.

That version in the screenie updates the LCD every single frame, even if nothing has changed. The grayscale tiles update every frame, the ones in the middle-ish of the map update every 5 frames and the ones on the outer edge update once every 16 frames. I'm pretty sure speed won't be an issue, and even if I add the variable speed to the Axe version, it will only add a thousand cycles or less (still keeping it >60FPS). I am still trying to figure out a more clever and efficient method for this, though. It will be particularly difficult to smooth scroll the map with masking and a player sprite on it

I forgot that grayscale would be updating every frame regardless...  wasn't thinking lol. Even if it slows down to 40, that's still fine. A lot of games slow down when a lot of things are being updated on screen.

I modified the source to the animated, masked tilemap routine and it is now 43 bytes larger. I am not sure how much faster this is, but WabbitEmu says it is about 150% faster. Basically, instead of using bcall(4744h), I used direct key testing which cost an extra two bytes but is much faster, and instead of using bcall(_GrBufCpy) (EF6A48), I used a custom LCD updating routine which I believe should be pretty fast and I can make it even faster since it is inline code.

Anyways, see below for what it currently looks like (I took about a 1 second screenshot, so it is on a loop). Now if I can get it to handle scrolling, that would be awesome, but I am pretty sure I will have a difficult time with that. I might be able to get a movable sprite on there, though. Also, the grayscale looks better on an actual calculator.

AMASK is for the most part hexadecimal with some labels (it is meant to be compiled with prgmASMCOMP) and prgmMASKEDTM is the assembly program.

EDIT: I rewrote the program to draw the tilemap while updating the LCD and doubled the speed to about 73 FPS according to WabbitEmu. It is also 27 bytes smaller At some point I should make actual tiles for this.

I have some sprite movement started I don't have actual player sprites, so I just used an 8x8 sprite. I am working on making the data for some sample 16x16 sprites, but once I actually have the data in there, it won't be difficult to add in 16x16 player sprite movements.


EDIT: Also, I need to come up with a less distracting animation

Yeah, it doesn't support scrolling yet. For all of the things I am thinking about adding, it will probably have its speed cut in half. I think the easiest way to have the sprite display and the LCD updating interleaved will be to have 8x8 tiles, but we can use those to form 16x16 tiles. I am working toward creating a movement engine that features pixel based collision with bottom layer of sprites (the mask) and there will be a buffer holding damage zones for when enemies are on the screen, or anything that can cause damage. So for those, I will need two 768-byte buffers  (plotSScreen and saveSScreen) and then AppBackUpScreen can hold all sorts of special info about where monsters are, open menus, and all that good stuff. I am planning to insert a 14*64 byte buffer using bcall(_InsertMem) at the end of the program to work as a buffer for the screen instead of using plotSScreen and this should really help with scrolling.