Projet Arkanoid - Page 1

C'est décidé cette année je me réattelé à la programmation très sérieusement.

J'ai trouvé l'idée du jeu genre Arkanoid plutôt sympa car je pense que ce n'est pas ultra compliqué à réaliser mais malgré tout pour peu que l'on rajoute quelques effets sonores et visuels le résultat peut être sympathique.

Mais voila comme vous le savez déjà je suis plus que novice en prog. il va donc me falloir un peu d'aide.
Ci-joint mon premier essai : Fichier joint : test.o
La balle rebondie sur les murs et la raquette bouge. Whou pas mal !
J'aimerais maintenant que les balles rebondissent également sur la raquette et sur les briques.

Je pense qu'il faut déclarer d'une façon spécial les sprites mais comment ?


Voici mon code :

#include <stdlib.h>
#include <lynx.h>
#include <lynxlib.h>
#include "inc\test.pal"

/* LYNX-specific #defines: */
#define JOY_RIGHT 0x10
#define JOY_LEFT 0x20
#define JOY_DOWN 0x40
#define JOY_UP 0x80

#define BUTTON_OPTION1 0x08
#define BUTTON_OPTION2 0x04
#define BUTTON_INNER 0x02
#define BUTTON_OUTER 0x01

#define BUTTON_PAUSE 0x01

char SCREEN[8160] at (MEMTOP-16320);
char RENDER[8160] at (MEMTOP-8160);

extern char fond[];
extern char b1[];
extern char b2[];
extern char b3[];
extern char b4[];
extern char balle[];
extern char raqu[];

extern char SCBfond[];
#asm
_SCBfond dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBb1[];
#asm
_SCBb1 dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBb2[];
#asm
_SCBb2 dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBb3[];
#asm
_SCBb3 dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBb4[];
#asm
_SCBb4 dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBballe[];
#asm
_SCBballe dc.b $c7,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

extern char SCBraqu[];
#asm
_SCBraqu dc.b $c0,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm


int x,y;
int a,b;
int dir_a;
int dir_b;


// assembler vertical retrace syncronisation routine
void Vsync()
{
#asm
vretrace:
lda $fd0a
bne vretrace
#endasm
}


/**************************************************************************
** **
** **
**************************************************************************/
char main()
{
InitIRQ();
CLI;

SetBuffers(SCREEN, RENDER ,0);

/* set the palette */
SetRGB(pal);
DrawFBox(0,0,160,102,0);
SCBX(SCBfond) = 0;
SCBY(SCBfond) = 0;
SCBDATA(SCBfond) = fond;

SCBX(SCBraqu) = 70;
SCBY(SCBraqu) = 90;
SCBDATA(SCBraqu) = raqu;

SCBX(SCBb1) = 20;
SCBY(SCBb1) = 50;
SCBDATA(SCBb1) = b1;


SCBX(SCBb2) = 20;
SCBY(SCBb2) = 40;
SCBDATA(SCBb2) = b2;

SCBX(SCBb3) = 20;
SCBY(SCBb3) = 30;
SCBDATA(SCBb3) = b3;

SCBX(SCBb4) = 20;
SCBY(SCBb4) = 20;
SCBDATA(SCBb4) = b4;

SCBX(SCBballe) = a;
SCBY(SCBballe) = b;
SCBDATA(SCBballe) = balle;
a =160;
b =98;


for(;
{
DrawSprite(SCBfond);
DrawSprite(SCBb1);
DrawSprite(SCBb2);
DrawSprite(SCBb3);
DrawSprite(SCBb4);
DrawSprite(SCBballe);

a=a+dir_a;

if (a>155) {a=155; dir_a=-1;}
if (a<0) {a=0; dir_a=1;}

b=b+dir_b;

if (b>96) {b=96; dir_b=-1;}
if (b<0) {b=0; dir_b=1;}

SCBX(SCBballe) = a;
SCBY(SCBballe) = b;
DrawSprite(SCBballe);


if (joystick & JOY_RIGHT)
x++;
if (x>147) x=147;
if (x<0) x=0;
SCBX(SCBraqu) = x;
DrawSprite(SCBraqu);


if (joystick & JOY_LEFT)
x--;
if (x>147) x=147;
if (x<0) x=0;
SCBX(SCBraqu) = x;
DrawSprite(SCBraqu);


Vsync();
SwapBuffers();

}
}
}

Soi tu décides de le coder toi même, soit tu utilises le moteur de collision qui positionne à un registre nommé "tilt" ou équivalent

vince (./2) :
Soi tu décides de le coder toi même, soit tu utilises le moteur de collision qui positionne à un registre nommé "tilt" ou équivalent

Bien sur ! C'est exactement ce que je me suis dit... Et puis je me suis malheureusement réveillé !
Non mais sans rire vince tu sais que mes connaissances en prog et surtout en prog lynx frolent le néant alors sans un petit bout de code en exemple je comprendrais pas grand chose.
J'ai vu l'exemple de kari (ou mathias) que tu avais un peu épluché c'est déja bien trop brut et complexe pour moi.

2/3 petites choses en passant sur la gestion des collisions en hard :

points positifs :
- ça marche au pixel prêt, c'est super pour les formes alambiquées
- c'est plutôt "facile" à mettre en place (j'y reviendrais plus tard)
- ça évite d'alourdir le code

points négatifs :
- ça bouffe 8 ko de RAM (bah oui, c'est un buffer écran supplémentaire)
- ça ralentit un peu le tout (mais là, faut comparer avec un algo à la main)


Maintenant, pour ton projet en particulier, j'avais justement voulu tester le buffer de collision sur un casse-briques il y a quelques années et je n'avais pas continuer l'expérience car :
- pour les briques, il me semblait plus efficace de chainer les sprites briques pour gagner (beaucoup) de temps machine. Ce n'est pas qu'on en ait besoin de tant que ça, mais c'est assez spectaculaire de chainer les sprites (j'avais un exemple perdu depuis sur un niveau de plate forme à la Mario ou non chainé, ça ramait comme pas possible, et chainé, c'était trop rapide) pour ce genre de chose (et vachement pratique au niveau algo, on affiche le premier et la bécane se débrouille toute seule, suffit juste de positionner le flag affiché ou non sur chaque brique quand elle disparait)
- MAIS (car il y a avait un mais - et c'est là que je reviens sur les guillemets du "facile"), le buffer de collision entre la balle et les briques lorsqu'elles étaient chainée ne fonctionnait pas. Je ne sais plus par contre si j'avais fait le test avec des sprites chainés ayant la structure complète (c'est à dire ne récupérant pas une partie des infos du sprite initial, ce qui permet de gagner de la mémoire). Bref, c'est à voir...

Pour tes collisions à la main, vu que ta raquette, tes briques, et même ta balle (ou presque) sont rectangulaires, il "suffit" de tester l'intersection des 2 rectangles. Après, une fois la collision détectée, c'est plus au niveau de la gestion des rebonds qu'on commence à s'arracher les cheveux (dans quel sens repart la balle, à quelle vitesse, avec quel effet...)

Si je retrouve ce bout de code de gestion des collisions, je vais voir ce que je peux en faire.
Mais de mémoire, il faut déclarer dans le contrôleur du sprite qu'il sera géré par le buffer de collision en précisant un plan. Puis, tester si une varibale indique qu'il y a eu collision et reparcourir la liste de sprites pour voir lesquels sont en contact.

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 ?

En fait, le tableau de briques puis la transposition des coordonnées de la balle dans le tableau pour tester les collisions, c'est ce que je fais dans tn.
Par contre, sur Lynx, contrairement à un ordi, il est sans doute préférable de passer par la liste de sprites chainés plutôt qu'une manipulation de la mémoire vidéo...

Et pour la raquette, il me semble préférable de gérer au pixel, plutôt que déplacement case de tableau par case de tableau, quitte à gérer une accélération quand on maintient une direction pour "simuler" rotary et trackball... mais ça revient quasiment au même si ton n fait 160 environ...

Pour un arkanoid, il ne faut pas oublier de gérer les monstres également, avec déplacements au au pixel comme la balle, et non à la case de tableau.

Merci à vous. Même si je ne comprend pas forcement vos discution et toutes vos explications du premier coup je suis toujours sur le... coup.

et tu utilises quelle chaine de compilation pour ton code ?

Qui moi...?

oui, toi ^^

Oh, un petit arkanoid en projet, sympa ca

Des heures de boulot en perspective ^_^

Salut FagEmul. Il me semble avoir vu ton nom quelque part sur le forum prog lynx... Je dois aussi avoir quelque part une rom avec un t'ris pour lynx abolument magnifique et il me semble bien que tu en es l'auteur.

FagEmul (./11) :
Des heures de boulot en perspective ^_^

Ho oui !

vince (./10) :
oui, toi ^^

Ha merde j'èspérais que la question était pour un autre ! Heu je passe pour un con si je demande : "c'est quoi une chaine de compilation ?"

je reformule : ton fichier C, tu l'utilises avec quelles librairies (si y'en a) et tu fais comment pour en faire un .o ?

Ok. En fait j'utilise une archive que m'avait filé Fadest dans mon tout premier cours de programmation . Je pense que la librairie c'est NEWCC65 et pour en faire un .o je tape juste "c test" dans le dos et cela me créé automatiquement un .o.

Il utilise le kit classic pour compiler.

Par contre, pourquoi avoir mis deux fois

SCBX(SCBraqu) = x; DrawSprite(SCBraqu);

Alors qu'une seul fois suffit normalement.

FagEmul (./15) :
Par contre, pourquoi avoir mis deux fois

SCBX(SCBraqu) = x; DrawSprite(SCBraqu);

Alors qu'une seul fois suffit normalement.

J'avoue ne pas toujours savoir ce que je fais. quand j'arrive à manquer de place j'essai de nettoyer un peu mes codes mais si j'ai la place et que ça marche je laisse tel quel. Essayer de programmer un vrai jeu va justement (j'éspère) à mieux comprendre chaque instructions de code.

Il en est ou cet arkanoid ?

Le fichier .o en téléchargement n'est là aussi plus disponible...

jean-philippe> Je me suis lancé dans la conception d'un casse brique, on échangera ainsi nos impressions et expériences...

une petite question: il y a combien de casse-brique sur la LYNX ?

philippe

beauregard (./19) :
jean-philippe> Je me suis lancé dans la conception d'un casse brique, on échangera ainsi nos impressions et expériences...

Tu n'arrêtes plus ! Un shoot un casse brique...
Malheureusement je vais pas avoir grand choses à échanger avec toi Tout ce que j'ai fait sur le projet est sur cette page.

beauregard (./19) :
une petite question: il y a combien de casse-brique sur la LYNX ?

Il n'y a que Block out 3d d'officiel et dans les jeux hombrew il y a eu pas mal de Tetris, une sorte de Columns jamais terminé par son auteur qui s'appelle Puzzle 2000 et clicks réalisé par Matthias Domin visible ici :
http://www.mdgames.de/lynx_eng.htm

En vrai casse-brique, je crois qu'il y a juste le mini-jeu sur la Lynx Reloaded, non ?
Sinon, en triturant la définition, Tetrisnoid et Columnsnoid peuvent rentrer dans la case

Fadest (./21) :
Sinon, en triturant la définition, Tetrisnoid et Columnsnoid peuvent rentrer dans la case

tes concepts ovniesques de jeux sont totalement inclassables.

Un casse brique figure dans les jeux de "salle d'attente" d'Electrocop pendant qu'on hacke la serrure d'une porte