HA! Yeah. After rotating the bits correctly and observing the numbers, I noticed my error. It's one of those situations where I got exactly what I asked for...just asked the wrong question. lol





That's exactly what I'm going to do. I was trying to be fancy by containing everything in one byte and rotating. But proves to be more trouble.

Thanks for all the suggestions. At the very least, I know have a better rotation function.

_________________
Cat; the other white meat.

Wait...

What if I used two bytes?

One byte for the facing direction and one byte for the moving direction?

Then, just make both nybbles the same. Wouldn't the rotate then work out OK?



Then, I can just rotate as normal and mask off either nybble.

I may try that next. If it doesn't work, use some lookup tables.

Thanks!

_________________
Cat; the other white meat.

I reckon you can still do the nibble rotate, with a bit of care. There are two checks and corrections to be made, one for each nibble. But I'm not quite smart enough right now to just write the code!

In order to transform the current facing value to the new facing value without affecting the movement direction, you only need four different EOR operands (#$30, #$60, #$C0, #$90) for clockwise or counterclockwise. The trick is in calculating the desired operand as efficiently as possible. Are you more interested in fastest execution or smallest code footprint? Because the solutions will probably end up evolving differently. One intermediate possibility might look like: [UNTESTED!]

I truncated and slightly overlapped the tables to save space, but this will blindly provide nonsense values for invalid inputs ... garbage in, garbage out.

I know someone here can do better, perhaps much better, but I'm just throwing this out there as an example. If status happens to reside at address $30 or address $30xx, I know how to save two more bytes of ccwtable!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

The EOR idea sounds interesting as well!

My idea of using two bytes seems to be working. The sprite is rotating correctly on screen now.

The numbers I am getting are:



Which translates perfectly to:



Same for moving.

Thanks again everyone for your help.

_________________
Cat; the other white meat.

Just a thought: you want to maintain two pieces of information, each of which has four possible states. You've chosen a one-hot encoding, and now you're looking for ways to manipulate it.

But four states can be encoded in two bits. The whole story fits in a nibble. And a nibble-sized lookup table is only 16 bytes: you can have one table for left rotation and one for right rotation.

If at some point you need a one-hot representation of this packed encoding, again a nibble-sized lookup table, with another 16 bytes, can give you what you want - or a pair of lookups, one to give you the movement part and the other to give you the orientation part.

(I have just spent 64 bytes on lookup tables! But the speed should be good.)

Yeah, my suggested solution was constrained by the structure it was trying to update. In a clean-sheet design, I would probably just use the two low bits of two separate bytes for each attribute and just INC and DEC to rotate.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

For rotating left: And for rotating right: Barrel shifts by more than one bit are a little more involved - here's one way to do a nybble swap:

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

To rotate the bits in each each nibble to the left, how about this:

(welcome Toby! I've seen you over on stardot...)

(thanks, I've seen you in stardot-land too...)