Arkanoid - Page 1

Voilà je me lance dans un autre projet, Arkanoid sera un jeu de casse briques sur TI89-TI92+ et V200 proposant une multitudes de bonus, d'options, modes et un Gameplay assez symaptique.

Je compte me baser sur 2 versions différente d'arkanoid:










Le jeu ne sera pas une copie conforme, tout les niveaus seront repensé et divers bonus et options seront différent. Par exemple la possibilité d'avoir plusieurs balles (un maximum de 10) et de tailles différente...

Pour des raisons de taille d'écran, le jeu utilisera un scrolling basé sur la balle en cours ou la balle plus près de la raquette, le jeu aura une taille d'écran virtuel de 320x200 pixels.

J'utiliserais la librairie PolySnd et donc Arkanoid sera un des premiers jeu à posséder du son.

Tu es sûr que ça ne posera pas de gros problème de gameplay d'être en 320x200 ? Ca risque d'être chaud, surtout quand on voit à quel point bave l'écran des TI... Surtout que tu n'as pas besoin d'une pure résolution (si tu utilises 2x moins de pixels que sur les shots, c'est tjs très lisible...)

Bonne chance

c surtout que si y a 10 balles, l'écran risque de scroller comme un fou s'il se concentre sur la balle la plus proche du pad
Le mieux est de se concentré sur le pad, je pense, comme dans Monster Break Out.

Sinon, une idée de bonus bien sympathique, ce serait de déplacer le pad en haut, bas, gauche, droite

Le pb c'est qu'il faut aussi un scrolling vertical

c surtout que si y a 10 balles, l'écran risque de scroller comme un fou s'il se concentre sur la balle la plus proche du pad
Le mieux est de se concentré sur le pad, je pense, comme dans Monster Break Out.
Sinon, une idée de bonus bien sympathique, ce serait de déplacer le pad en haut, bas, gauche, droite

J'ai fait des tests et l'écran de la TI est bien trop petit pour recevoir un tel jeu, de plus avec un double buffering et 10 balles, l'écran ne bave pas. Ce qui me fait le plus peur c'est sur TI89.

Bonne chance

Merci.

Tu es sûr que ça ne posera pas de gros problème de gameplay d'être en 320x200 ? Ca risque d'être chaud, surtout quand on voit à quel point bave l'écran des TI... Surtout que tu n'as pas besoin d'une pure résolution (si tu utilises 2x moins de pixels que sur les shots, c'est tjs très lisible...)

Oui en effet quand il y aura plusieurs balle, autant scroller suivant le pad.
Pour le bonus, ça ma l'air peu utile.

planter dans les cite, je crois

Pour le bonus, t'as jamais essayer de jouer à un casse brique à l'envers ou avec le pad à gauche ou à droite ???
tu devrait essayer

planter dans les cite, je crois

lol, en effet, j'avais pas vu.

Pour le bonus, t'as jamais essayer de jouer à un casse brique à l'envers ou avec le pad à gauche ou à droite ??? tu devrait essayer

J'ai déjà essayé, mais tu me donne une idée, un bonus qui fait une rotation du jeu.

Oui je te dis bonne cahance aussi car ya du boulot enfin un bon turbo break out sur V200

Oh tu sais le masse de boulot ne me dérange pas.
Le plus dur reste sans aucun doute de réaliser le moteur du jeu, le reste sera de la rigolade.

Préviens nous dés que tu as une beta
Pour ma part je suis volontaire pour les test sur V200 AMS 2.07 :-)

OK, mais je viens de commencer le projet, donc il faut attendre pour la bêta.
Pour l'instant ça avance bien, j'ai réalisé la gestion des fichiers externe contenant les sprites du jeu et les sons, aujourd'hui je vais m'attaquer au fonctions en assembleur de scrolling et d'affichage de sprites dans une zone de 288x238 pixels, en effet j'ai réflechi et il semble qu'une zone de cette taille soit parfaite.

J'ai un petit souci pour réaliser la fonction capable de copier une partie de 240x128 pixels de l'écran virtuel (288x238 pixels) vers les 2 buffers des niveaux de gris (GetPlane (0) et GetPlane (1)).

Dans ma fonction il faut que je réalise une boucle, j'arrive à me placer au début de l'octet qu'il faut mais comment copier une ligne avec les bon pixels dans les autres buffers à 0,0?

nt les deux bouts move.l d3,(a1)+ ; et affiche

Voici ce que j'utilise pour scroller 32 pixels :	move.l	(a0)+,d3 ; met le premier long de la source dans d3
	lsl.l	d0,d3 ; scrolle vers la gauche
	move.l	(a0)+,d4 ; prend le long suivant
	rol.l	d0,d4 ; rotationne vers la gauche
	and.w	d2,d4 ; efface la partie haute (d2 = 0xFF << d0)
	or.w	d4,d3 ; joi

En fait, au moment où on prend le deuxième long et qu'on le met dans d4, on peut le sauver dans d5 aussi pour le réutiliser pour la suite (mais là je n'ai pas mis le code entier parce qu'il prendrait trop de place).
Voilà, si quelqu'un a un code plus efficace, je suis preneur (pour l'instant, je n'ai rien vu de plus rapide, même pas genlib).

Tu dois pouvoir faire ça avec quelques move.l et lsl.l
Plus précisément, tu obtient l'adresse du word du début de la ligne et l'indice du bit qui correspond au pixel (dans le word bien entendu), que tu transformes en un compteur de décalage.
Ensuite, tu lis un long a l'emplacement actuel dans le buffer, et tu lui appliques lsl.l avec le compteur de décalage calculé précedemment. Il ne te reste plus qu'a faire un swap et un move.w (avec postincrement) vers l'emplacement de destination. Tu incrémentes le pointeur de la source de 2 et tu ansi de suite jusqu'à atteindre la fin de la ligne.
EDIT: post croisé

geogo> 238 n'est pas divisible par 8, c'est normal ?
[edit] et de toute façon, ça me paraît assez énorme comme hauteur.
[edit2] mais comme c'st une hauteur, en fait on s'en fout que ce soit divisible ou non par 8

Sasume :
nt les deux bouts move.l d3,(a1)+ ; et affiche

Voici ce que j'utilise pour scroller 32 pixels :	move.l	(a0)+,d3 ; met le premier long de la source dans d3
	lsl.l	d0,d3 ; scrolle vers la gauche
	move.l	(a0)+,d4 ; prend le long suivant
	rol.l	d0,d4 ; rotationne vers la gauche
	and.w	d2,d4 ; efface la partie haute (d2 = 0xFF << d0)
	or.w	d4,d3 ; joi

En fait, au moment où on prend le deuxième long et qu'on le met dans d4, on peut le sauver dans d5 aussi pour le réutiliser pour la suite (mais là je n'ai pas mis le code entier parce qu'il prendrait trop de place). Voilà, si quelqu'un a un code plus efficace, je suis preneur (pour l'instant, je n'ai rien vu de plus rapide, même pas genlib).

Ok je vais m'appuer la dessus, théoriquement je ne devrais pas avoir de problèmes à partir de ça.

Tu dois pouvoir faire ça avec quelques move.l et lsl.l
Plus précisément, tu obtient l'adresse du word du début de la ligne et l'indice du bit qui correspond au pixel (dans le word bien entendu), que tu transformes en un compteur de décalage.
Ensuite, tu lis un long a l'emplacement actuel dans le buffer, et tu lui appliques lsl.l avec le compteur de décalage calculé précedemment. Il ne te reste plus qu'a faire un swap et un move.w (avec postincrement) vers l'emplacement de destination. Tu incrémentes le pointeur de la source de 2 et tu ansi de suite jusqu'à atteindre la fin de la ligne. EDIT: post croisé

Ouai je comprend mieux maintenant. Tout ce fait à base de compteurs et de décalages bien sûr.

geogo> 238 n'est pas divisible par 8, c'est normal ?
[edit] et de toute façon, ça me paraît assez énorme comme hauteur. [edit2] mais comme c'st une hauteur, en fait on s'en fout que ce soit divisible ou non par 8

J'ai cherché longtemps pour trouver une taille en longueur parfaite, 288 est parfait.
Pour la hauteur ce n'est pas important?

OK, je veux bien que tu aies cette hauteur, mais c'est énorme quand même... (et c'est bien 238, pas 288 comme tu viens d'écrire ?)

Tiens, j'ai essayé de faire une fonction de scroll adaptée à ta taille de buffer, je te l'envoie par mail et tu me dis si ça marche correctement ou non (je ne l'ai pas testée et je l'ai écrite rapidement, donc il y a très probablement des erreurs, donc teste sur vti).

Mon écran virtuel fait 288x238 pixels, ça semble énorme comme hauteur mais c'est la seul que j'ai trouvé petit et adapté, il suffit sur TI92+, de 2 écrans pour scroller tout le jeu. Le gros handicap de l'écran de la TI92+ c'est ça hauteur, la longueur est presque parfaite mais la hauteur est très très faible.

Tiens, j'ai essayé de faire une fonction de scroll adaptée à ta taille de buffer, je te l'envoie par mail et tu me dis si ça marche correctement ou non (je ne l'ai pas testée et je l'ai écrite rapidement, donc il y a très probablement des erreurs, donc teste sur vti).

OK je vais tester ça.

Euh attends, je viens de me rendre compte d'une erreur, je corrige et je te réenvoie

BOn j'ai réussit à trouver le nombre de bit à décaler ainsi que l'octet de début de chaque ligne or je suis bloqué, je dois appliqué ta fonction de décalage sur 32 bits 8 fois par ligne et répéter ça 128 fois pour la hauteur.

Or dans ta routine tu met:
lea 36*238(a0),a2
lea 30*128(a1),a3

Et tu créer 2 masques contenu dans d1 et d2.

geogeo
: BOn j'ai réussit à trouver le nombre de bit à décaler ainsi que l'octet de début de chaque ligne or je suis bloqué, je dois appliqué ta fonction de décalage sur 32 bits 8 fois par ligne et répéter ça 128 fois pour la hauteur.

Pourquoi ? Je t'ai envoyé une fonction modifiée qui est adaptée à la taille de ton buffer normalement...

Or dans ta routine tu met:
lea 36*238(a0),a2 lea 30*128(a1),a3

C'est pour obtenir les adresses des plans pour les niveaux de gris (ils sont consécutifs).

Et tu créer 2 masques contenu dans d1 et d2.

Et ?

Pourquoi ? Je t'ai envoyé une fonction modifiée qui est adaptée à la taille de ton buffer normalement...

Oui, mais j'essaye de la réécrire pour comprendre comment ça fonctionne. Les fonctions graphiques m'intresse vraiment.
En tout cas j'utiliserais ta fonction et je t'en remercie.

C'est pour obtenir les adresses des plans pour les niveaux de gris (ils sont consécutifs).

D'accord.

Et les 2 masques sont là pour écrire par dessus le buffers de destination?

J'espère que tu ne pensais pas que la fonction que tu as réalisé ne me convenais pas???
Au contraire elle est parfaite.
C'est juste que j'aurais d'autres fonctions à réaliser et je préfére les réaliser.

Les deux masques servent dans la routine citée en ./14 (même si dans ce que j'ai mi je n'utilise qu'un seul des masques), enfin, vu que tu as la routine complète tu verras à quoi ils servent.
Fais un shéma sur papier, ça sera bien clair.

OK, je vais faire un schéma papier et toucher un peu à tout pour voir ce que ça donne.

Je viens de remarquer encore un pb dans la fonction que je t'ai envoyée : à la fin de la boucle, remplace les 48 par des 6 dans les deux lea (je me suis embrouillé entre pixels et octets).
[edit] Ça venait d'ailleur de ça, les petits parasites en bas de l'écran