Woah, happy birthday Omni!

Wow, that's really neat. I don't have a use for that at the moment but I bet I can find one in some old, slow code.

How did you go about making the routine generator? I assume there are some simple rules it follows.

It looks through all the numbers 1-65535 to find some good code.
If the number is even, it essentially uses the code for n/2, but with an `add hl,hl` tacked on to the end. Otherwise it is odd and it first tries a shift-and-add algorithm (basically the classic, generic multiplication, but unrolled and with branches removed as we know which path it takes in advance). It registers whatever code it came up with, then it checks if it is faster or smaller to multiply by the factors (for example, it is faster to multiply by 27 by doing *3*9 or *9*3), so it finds all of the factors and checks for anything more efficient.

There are other tricks, too, like checking if it is faster to "negate" (i.e., *65535 is the same as *-1), and if there is a *(2^k-1) with k>3, it uses a subtraction. And it collapse things like 8 `add hl,hl` into `ld h,l \ ld l,0`, and has some pre-populated routines in the table.

It doesn't really know anything about the instruction set, so it can't do any fancy optimizations

That is probably the simplest and fastest method and shouldn't slow it down much, but there might be order-of-operations issues, so you might need:
If (A>(X-8)) and (A<(X+8))
Alternatively:
If (A-X>-8) and (A-X<8)
But for Axe, that can probably be optimized to:
If A-X+7 < 15
(This is taking advantage of "negative" numbers actually being really large, so you don't need to make sure A-X+7>=0. If it was "smaller" than zero, it would actually be around 65000 which is not less than 15 )

You have the Fix 4 inside the loop so after the first iteration, it starts drawing directly to the LCD again. If you move it outside the loop (after the End), then it should work.

Also as general forum etiquette, you can Modify your post instead of double- (or triple-) posting (Double posting is when you post twice in a row. General rule of thumb is that after a day since the last post it is okay to double-post.)

Wow, it has been over a year since I last updated this thread!

I've added support for IEEE-754 binary32 floats here!
What is really nice about this is that compilers like fasmg have built-in support for these floats, and there are a plethora of existing tools to work with them.
I've rearranged the project a bit and I am working on making the code more agnostic (so not relying on spasm's unique features). I've added a lot of conversion routines, especially for f32 and f24 floats.

I took an unplanned path with the f32 floats and ended up making addition, subtraction, multiplication, division, and square roots work entirely within registers and the stack, so no external RAM was required. I haven't taken the time to do a speed analysis of these, but I'm thinking they are a little slower than the single routines. I expect that multiplication and division are slower, and hopefully addition and subtraction are faster.

I don't think I can do an OnlyFans; I'm just not ready for that kind of responsibility :|

I think what I would suggest is what you are already trying to do. For irregular collision boxes, I set a "collision buffer" the size of the screen (1bpp), and in that buffer I set the pixel on if it's a collision point, else off. Then when I am drawing the tile, so draw it's collision sprite to the collision buffer.

I have no idea how to do this on the 68k calcs