So what is the speed, then? Would speed be "96"? I'm trying to figure out how to calculate the initial velocities.
Let's simplify 96 to 3.
object = 10,10 (x,y)
bullet = 5,2
length = sqrt(3²+0²)
length = 3
xVel = (10-5)/3*...3? -> 5/1 xVel = 5
yVel = (10-2)/3*3 -> 8/1 yVel = 8

If i change speed to one:
xVel = (10-5)/3*1 -> 5/3 xVel = 1 2/3
yVel = (10-2)/3*1 -> 8/3 yVel = 2 2/3
I don't quite get what values i'm supposed to be using.

EDIT: Maybe i've got it now, i'll test it out tomorrow and see.

Do you need it to clip? I can post the clipped sprite routine i've got though it's much more dependent on SMC (and much larger). It's also probably not very optimized.
To give you an idea, this is what it looks like (this is for a 24x24 sprite):
bossY = $+1
ld hl,TERRE_Y*256 ;la coordonnée y du boss
call subMapYHL ;hl (bossY) - map Y
ret c ;si le carry est armé, le boss est hors de l'écran
ld a,h
cp 64 ;plus de 8 et le boss est hors d'écran
ret nc
ld e,a ;sauver coordonnée Y
ld b,0
bossX = $+1
ld hl,$0400
ld a,l
rlca
rlca
rlca
and $7 ;a = xOff
ld c,a ;sauver xOff dans c
ld a,h
ld hl,xCoord
sub (hl) ;bossX-mapX
jr nc,xNotNegative
;pour une explication, voir dessous
ld d,a ;sauver a dans d. a = combien d'octets (pas de pixels!) on est de le bout gauche de l'écran
add a,BOSS_W
ret m ; ... le sprite est hors d'écran
ld b,a ;
add a,a ;*2
add a,b ;*3 (parce que chaque ld (xxx),a occupe trois octets)
ld (clipLeft),a ;SMC: changer où va sauter le jr
xor a ;valeur qui va remplacer spriteByteX
ld b,$FF ;plus tard nous chargeons b dans d. $FF est parce que c'est un numéro (16bit) négatif
clipLeft = $+1
jr $ ;avec du SMC on va sauter
ld (spriteByte3),a ;SMC: change the ld (hl),a to a nop (HEX $00)
ld (spriteByte2),a ;
ld (spriteByte1),a ;
ld a,d
ld d,0
jr noWorkToDo
xNotNegative:
cp 13 ;s'il est complètement hors d'écran, quitter
ret nc
cp 10 ;s'il est partiellement hors d'écran, clipper
jr c,noWorkToDo
push af
;###########################
;# je vais expliquer cette partie-ci parce qu'elle m'a vraiment frustré
;#  cette partie s'occupe du "clippage" des sprites hors d'écran
;#  si le sprite va s'afficher dans la 11ème colonne (ou la 10ème commençant de zéro)
;#  une partie va être hors d'écran. il faut la clipper.
;# si le sprite s'affiche dans la 10ème colonne, il y a un octet qui ne s'affichera pas
;#  la 11ème, il y'en aura 2, et la 12ème, 3.
;# regarder la liste au-dessous du "jr $". si nous voulons effacer le dernier octet du sprite
;#  il nous faut sauter "ld (spriteByte2),a" et "ld (spriteByte3),a". donc, on nécessite savoir 12-a
;#  puis, nous multiplions ça par 3 (chaque instruction occupe 3 octets) et changer où "jr" va sauter.
ld b,a
ld a,12
sub b ;essentiellement, a=12-a
ld b,a
add a,a
add a,b ;a*3 (parce que chaque ld (xxx),a occupe trois octets)
ld (clipRight),a ;SMC: changer le jr
xor a ;valeur qui va remplacer spriteByteX
ld b,a
clipRight = $+1
jr $
ld (spriteByte2),a ;SMC: change the ld (hl),a to a nop (HEX $00)
ld (spriteByte3),a ;
ld (spriteByte4),a ;
pop af
noWorkToDo:
ld d,0
ld l,e
ld h,d
add hl,hl ;y*2
add hl,de ;y*3
add hl,hl ;y*6
add hl,hl ;y*12
add hl,de ;y*13
ld de,megaGbuf+BOSS_W ;86EC+2 (nous dessinons de droite à gauche, les sprites des boss occupent 2 octets, 16 pixels)
add hl,de
ld e,a
ld d,b
add hl,de
ld a,c
ld b,a
ld c,BOSS_H
desBossBoucle:
push bc
ld d,(ix)      ;sprite
ld e,(ix+1)
ld c,(ix+2)
xor a
cp b ;si b = 0
jp z,spriteAligne
srl d \ rr e \ rr c \ rra \ djnz $-7   ;rotate sprite
spriteAligne:
or (hl) ;HL = endroit dans gbuf
spriteByte4 = $
ld (hl),a ;charger a
dec hl
ld a,(hl)
or c
spriteByte3 = $
ld (hl),a ;charger c
dec hl
ld a,(hl)
or e
spriteByte2 = $
ld (hl),a ;charger e
dec hl
ld a,(hl)
or d
spriteByte1 = $
ld (hl),a ;charger d
inc ix
inc ix
inc ix
ld de,13+BOSS_W
add hl,de
pop bc
dec c
jp nz,desBossBoucle
ld a,LDHLA
ld (spriteByte4),a
ld (spriteByte3),a
ld (spriteByte2),a
ld (spriteByte1),a
ret

LDHLA = $77 ;$77 est le "opcode" de "ld (hl),a"And this is subMapYHL/XHL, which is used all over the place:
subMapYHL:
ld a,(yCoord)
jr subMapHL
subMapXHL:
ld a,(xCoord)
subMapHL:
push de
ld d,a
ld e,0
or a
sbc hl,de
jr c,endSubMap
add hl,hl
add hl,hl
add hl,hl
endSubMap:
pop de
retThe comments are all in (really bad) French, sorry. It'd be slightly smaller but that's what you'd be dealing with for a clipped routine (at least from me ). It might be easier just to give you my entire tilemapper.

I'm trying to put together a routine that will calculate the appropriate X/Y velocity to go towards an object. What i've got now is really buggy, i think the general algorithm/idea is ok though. My biggest hurdle so far has been handling negative numbers, as none of my routines for multiplication/division seem to like negative numbers. What i'm currently doing is really just adjusting the Y velocity and not bothering with the X velocity. The general equation is something like this:
(object Y - bullet Y)/(object X - bullet X)

The X/Y velocities have 5 bits which act as a decimal place, but this doesn't let me use it. I hacked in the ability to handle negative numbers in the division routine (essentially turning all negative numbers positive, then negating the result afterward), but my multiplication routine doesn't like negatives numbers either.

You're right, either way it'll still be slower. If you are using a 16x16 routine, you will be calling that routine more times than if you were drawing normal 16x16 sprites (essentially the last four rows will be time completely wasted, doing nothing), and calculating the offset every time means a lot more shifting bytes since at least every other tile will be unaligned. But another reason for the slowdown with Sam Heald's Zelda might just be that back then there weren't that many smooth-scrolling games in general.

Again a bit of a bump, but (in the picture) how do you get 126 from (sign-extended) $FE? I believe it should be 254 (like mentioned in the post body).

And i'd be interested in discussing SH3 assembly with anyone else interested

Wow, i played this game when it came out and thought it was awesome (a little short, though). It's cool to see updates to all these great games that helped me get through high school!

Yeah, that's exactly it. If your buffer is 12 bytes wide and you want to draw on the 4th row, you'll need to add 4*12 to the buffer address. The other code i posted above will calculate that for you with e=y, b=x. However, if you can save your position in the gbuf each time you draw a tile, you can save quite a few clocks by not having to recalculate your location in the buffer again.