La gestion hard des collisions n'est pas triviale à mettre en place (mais pas hyper complexe non plus). Ensuite, elle aura ses avantages et inconvénients.

Avantages :
géré par le système
géré au pixel près quelque soit la forme des sprites
Nickel pour un shoot (si collision balle - vaisseau -> destruction)

Inconvénients :
ralentit un peu la Lynx (bon, d'un autre coté, la gestion à la main sera aussi du temps machine consommé)
concomme de la mémoire (8 ko)
moyen quand on doit savoir ou a eu lieu la collision (exemple casse-brique, en plus de savoir qu'il y a eu collision entre la balle et la raquette, il faut savoir si c'est à droite ou à gauche de la raquette pour les effets, voire au dessus ou en dessous)


Pour ton exemple, on va considérer que la balle est un point et la raquette un rectangle, il faudrait plutôt tester quelque chose du genre :
Si xBalle>xRaquette et xBalle <xRaquette + largeurRaquette
Si yBalle >yRaquette et yBalle<yRaquette + hauteurRaquette
-> changement direction balle
FinSi
FinSi

A adapter bien sur (surtout si la balle est assez grosse), car je pars du principe que le point d'action de ton sprite est au centre en bas de ta balle (j'ai un doute, j'ai déjà parlé du point d'action d'un sprite ?).