I actually don’t calculate square roots. I do what you first said. Pressing up moves you up a pixel, pressing right moves you right a pixel and pressing up+right moves you up a pixel and right a pixel. Mathematically, diagonal movement might be faster than straight vertical or horizontal, but it isn’t really noticeable in the game.

That said, I haven’t written any acceleration code yet that will take the hero to a speed above 1 pixel per frame (for each axis). If I do, and the speed difference is really obvious, I might have to fix it. But for now I’m going to keep it simple.

I did branch testing for directions the way you describe on my first NES project (the 4-way Dragon Warrior-style scroller). It worked just fine for me there. But you’re right, it gets unwieldy the more conditions you have to check for. Anytime I find myself with a lot of compares and branches in my code I try to see if I can find a way to use a lookup table instead. It’s a lot easier to read that way, and easier to tweak values and catch bugs too. I use tables for the movement too (as you’ll see in the next post). I use the hero_direction again as an index into tables that hold values of $00, $01 or $FF (ie, -1). I read from the table and add it to the hero’s coordinates. No branching needed.

Another reason I do it this way is to separate the input handling from the rest of the engine as much as possible. The way it works now, I check the input and set the direction and I’m done. Then the update_hero routine will take care of all the logic stuff for me. Keeps the input routine nice and compact.

Next post will be movement and animations and then the next one will be background collision detection (with video I hope!). Hope you’ll like it.

It does make sense to handle each combination seperately, though, especially when having 8 directions to move into.
Diagonal movement was possible with my simple approach, but it was way faster than horizontal or vertical movement.
E.g.
press down -> input handling function sets y-speed to 1
press right -> function sets x-speed to 1
press up+right -> function sets y-speed and x-speed to 1

When in the last case both should actually be 1*SQRT(2) to be the same speed (as the diagonal of a square is one of its sides multiplied by the square root of two).

Now I’ve probably stolen that bit from your next entry. If not, this might help beginners. It’s clear to me know, but wasn’t back when I started.
(Oh well, I’ve never been that math-savvy anyway) :)

Keep those updates coming!

It’s funny how you did the input, because just today I was messing with how I would know which directions are available for exiting from one screen to the next on that zombie game, and came up with this:

; *********************************************************
; Screen exit types: 0=all_directions, 1=top, 2=bottom,
; 3=left, 4=right, 5=top/left, 6=top/bottom,
; 7=top/right, 8=top/left/bottom, 9=top/bottom/right,
; a=top/left/right, b=bottom/left, c=bottom/right,
; d=bottom/left/right, e=left/right, f=none
; *********************************************************

hehe That’s pretty cool!

That is an interesting way to handle the controls, actually. I’ll have to read that some more, as I’ve always done something pretty different, but is only suited well for 4-direction movement.

test up, if pressed, move sprite up and jump over the other directional buttons routines –
if jump is NOT pressed -
test down, if pressed, move sprite down and jump over other directional buttons routines -
if not -
etc. etc.

Can’t wait to see how you do background collision, because that has been stumping me for a long time, even with people giving me a helping hand haha