Avant de toucher au code, je me suis toujours demandé comment les programmeurs pouvait gérer autant de sprite ''brique'' sur les micros ou console 8 bits, car en prenant comme exemple le premier tableau d'arkanoid, le nombre de brique est tout bonnement colossale(plus de 70)!
En fait c'est simple, dans un casse brique ''basique'' il n'y a AUCUN sprite à gérer, enfin si il y en a juste deux , la balle et la raquette !

Alors comment cela fonctionne ? Hein ?

C'est tres simple tout d'abord il faut considérer la balle comme un carré dont on va nommer les cotés pour l'exemple comme suit :

     A
   -----
D |     | B
   -----
     C

Ensuite on va créer une table avec des chiffres qui vont représenter les briques(8), les murs(9)et la zone de tout les dangers(0).

{
999999999999999999999,
977777777777777777779,
977777877777778777779,
977777877777778777779,
977777778777877777779,
977777778777877777779,
977777788888887777779,
977777788888887777779,
977778887888878877779,
977778887888878877779,
977888888888888888779,
977888888888888888779,
977888888888888888779,
977877888888888778779,
977877877777778778779,
977877877777778778779,
977777788777887777779,
977777788777887777779,
977777777777777777779,
977777777777777777779,
977777777777777777779,
900000000000000000009
}

Apres le principe est aussi simple que le fonctionnement d'un kuk.

Tu vas tester dans la table le déplacement des valeurs qui composent ABC et D, si celles ci rencontrent un 8 alors tu mets à jour ton tableau en remplacant le 8 par un 7 pour faire disparaître la brique, et tu lances ta routine pour effacer ta brique sur l'ecran.
Pour cette routine il suffit d'avoir un buffer avec une sauvegarde du fond sans les briques, et de recopier les coordonnées du fond correspondant aux coordonnées référentielle de la brique dans ta table sur le buffer ecran.

Et pour la gestion des collisions de la boulette avec la brique on fait comment ? Hein ? On fait comment ?

Et bien c'est encore plus simple. Si ce sont les valeurs qui composent D et B qui ont effacées la brique, il s'agit forcement d'une collision verticale et il te suffit donc d'inverser la valeur de déplacement sur l'axe des abscisses de ta boulette.
A contrario, Si ce sont les valeurs qui composent A et C qui ont effacées la brique, il s'agit forcement d'une collision horizontale et il te suffit donc d'inverser la valeur de déplacement sur l'axe des ordonnés de ta boulette.

Bref voilà pour la gestion des briques et de ta balounette sur celle ci, AUCUN sprite et AUCUNE gestion de collision hardware ne sont nécessaire.

Et pour la gestion de la boule sur la raquette ?
Et bien on utilise à peu près le même principe que pour les briques.
Il faut créer une table avec ''n'' élements, ''n'' correspondant à la largeur de ta zone de jeu. Ensuite il faut simuler la raquette par une suite de chiffre(8) que tu mettras à jour à chaque déplacement de ta raquette.
{
77777777777777788888888777777
}
Pour les collisions même principe que pour les briques. Tu dois juste prendre en compte quelques notions supplémentaires, comme la vitesse et le sens du déplacement de ta raquette en fonction de l'angle et la vitesse d'arrivé de la baballe sur celle-ci pour pouvoir lifter ou ralentir le projectile.

Bref pour résumer, tu n'as pas besoin des collisions hardware pour gérer un casse brique ni d'une tonne de sprite.

Vala mr RizGâre !

Au fait... programmer un casse brique c'est sympa à faire... mais quand tu n'as pas de contrôleur analogique type souris, trackball ou rotary control pour déplacer la raquette, c'est nettement plus pénible de régler le gameplay ! Bref le paddle c'est pas trop fait pour ce genre de jeu...

Templetonnant non ?