It's an interesting idea, i generally give coordinates 2 bytes, where the last 5 bits are used as a fraction. You could use the entire 2nd byte for the fraction, but i like having 256 tiles to work with (vs. 256 pixels) and being able to find the character's position in the map quickly by just reading the MSB. I guess the CSE has a larger screen, too, so you'll need to work with a larger area than i do.

It's essentially the same idea you've got, just instead of varying how often to update the Y coordinate, i update it every frame, but with a fraction. So if i add 32 (%00100000), that moves the character one pixel (the first five bits are fractions, changing them won't change the sprite's position). But if i add 16, it moves the character half a pixel (ie. it takes two frames to move the character one pixel). I might start the velocity at 80 (2.5 pixels per frame) with a gravity of 8 (ie. it would take 10 frames for the player to come to a complete stop, though the last few frames the sprite would update very slowly, giving it a nice arc). I'm not sure how sound the physics are, but it looks nice to me

Also, that wind idea is really interesting. It'd be cool to have gusts of wind pop up from time to time blowing you one way or another.

Your projects are all really inspiring, you never cease to amaze me!

Wow, that looks amazing! It's beautiful! I imagine a mini-golf game has to have lots of interesting math to it. How do you handle edges that aren't vertical or horizontal?

How do you do acceleration? I've never bothered with sine/cosine tables, i generally just give it an initial value and subtract gravity from velocity. Those other modes look pretty wild, a mixture of the moving and disappearing platforms would be great!

Ok, i'm having some computer issues but i'll think about it (as well as converting my code to bits  ) while i try to fix things up. To follow back, you can just compare the bits to where you left off, for example if you've rotated to %10011001, you need to look for a 1, then two 0's, then two 1's, etc. I'll need to look at some more patterns but i believe you can move diagonally following a %10101010 pattern. You'd just rotate the pattern twice, since it's essentially two moves packed in one.

EDIT: So for diagonal movement, instead of checking bit 0 of the pattern, check bit 1. If bit 1 is correct, you can move diagonally.

Ok, i think i get it now. Thanks I just wrote a little program (see the screenshots). But i haven't switched over to using bits, i've got it all set up using one byte per tile per array (using bits has to be a pain, have you written it already?). I also couldn't think of a way to avoid checking bytes that were closed multiple times, so i changed their value to 2 once i processed them. I also ran into an issue with adding values to the closed array and processing them in the same iteration, so i ended up running through the the array first and storing the values (well, pushing them onto the stack) that i needed to process and then processing them afterwards.

Ok... so now that i've actually figured out (mostly) what it is you're talking about, what exactly is giving you trouble? Writing the backtracking portion? Or is that ok, just working with bits is complicating things?

I'm trying to follow but i'm not entirely sure i get it. Rather than using full bytes you're storing 8 entries per byte, no? I'm not sure how you plan to store the direction (0-7), using nibbles/a full byte would take up a lot more room.

The implementation uses three bit-mapped 128 byte buffers to represent a 32x32 map. These buffers are contiguous in RAM.
(listed in order)
b_tilemap: each bit represents whether a tile is walkable or not. 0 = empty, 1 = wall.
b_closed: each bit represents whether this node has been visited or not by the search algorithm

b_nodes: each bit represents the value assigned to the node when it was visited. This value is used for backtracking, and this is why the algorithm is interesting!

This is also the part i don't quite get. How do you determine which value to give it?

When the routine starts, the bit of the starting node in b_closed is set. Each iteration of the search passes over the entire buffer. Every bit in the b_closed buffer is "expanded" into each of the 4 adjacent bits that are not walls in b_tilemap.

So you essentially mark the starting location as closed, then what? Is everything (the four adjacent bits/tiles) marked as "visited"? I'm not sure how you keep track of where active paths are.

Any newly expanded bits that were not already set in the b_closed buffer are assigned a value of either 1 or 0 in the b_nodes buffer. This value is the same for every new bit expanded during the iteration. After each pass, the bit of the goal node is tested in b_closed. If it is set, we know the goal node has been visited, so we can now backtrack from here to the start by following our b_nodes values!

How do you determine whether it's a 1 or a 0?

The assigned b_nodes value follows the pattern 0, 1, 1, 0, 0, 1, 1, 0, etc, changing each iteration to the next value in the pattern. This is the key to this algorithm. At any given index in this pattern, the previous and next indices always have different values. With a reference of the current value and either the next value or the previous value in the pattern, the third value can always be determined

It sounds interesting, but i think an example would be really helpful to see what exactly's going on

For diagonal moves, would it not work just expanding the initial search to the 8 surrounding tiles (and checking the 8 surrounding tiles when tracing back)?

To be honest, i kinda like the tile-by-tile movement. It's got a nice old-school feel to it and makes the engine much simpler

It looks beautiful, AsmBandit. I love all the work you've been doing!

You mean just treat the text as a large sprite? I'm not sure what you mean in the second part, i figured Matrefeytontias was xor'ing a bar over top of them which can be done either way.

Another idea for the menu that might look alright is just putting the menu where the big "X" is, if it'll fit. And when you say 436 bytes (i'm not quite sure where you got that number from, unless you just made that number up. It's not even divisible by 8 ), i'd just like to ask how many bytes the sprites you use in the title screen take up

I don't think the menu's super important anyway, just so long as it works.