jeu de combat - Page 11

redangel17:
Si tu veux un jeu de combat avec des sprites je te conseil celui de flashZ
mais dans le mien j'essaye un concept different avec des formes plus simple..

Cela semble un peu vide comme decor mais j'ai prevus d'ajouter pas mal d'effet.
L'esprit de mon jeu est l'utilisation de l'affichage vectoriel grâce auquel j'espere obtenir de belles animations...quand j'aurais du temps pour programmer.

Remarque: l'un des avantages de l'affichage vectoriel est que grâce à un editeur PC de ma création,n'importe qui pourra creer des animations facilement et les regarder/jouer avec sur sa calculatrice.

nouvelle adresse pour tester:
http://membres.lycos.fr/gaelgiraudeau/dev/xiaoxiaoshow/DISTRIv0.60.zip

Elynx :
redangel17:
Si tu veux un jeu de combat avec des sprites je te conseil celui de flashZ mais dans le mien j'essaye un concept different avec des formes plus simple..

J'avais compris ça. Je n'ai pas contredis le principe de ton jeu. Je l'essaierai avec plaisir.

merci beaucoup. : )

merci aussi pour votre patience. : )

Quand même!

"Ce site ou cette page n'existe pas"

oups...
le lien est sur la page:
http://membres.lycos.fr/gaelgiraudeau

la gestion des collisions n'est pas encore parfaite.
Elle sera ameliorée avec une fonction FastTestLine qui va peut-etre etre ajouté a extgraph.

Tiens, je n'avais pas fait le rapprochement, et j'ai manqué ton post sur le forum de TIGCC/TICT cette semaine.
Vu que ça a l'air plus facile à faire qu'une fonction de test des collisions qui gère deux hauteurs différentes, je ferai peut-être FastTestLine en premier. En attendant, tu peux utiliser la routine qu'utilise Martin Huber (mhubi), elle n'a pas l'air si mal.

merci d'avance.
J'essaye avec la routine de mhubi pour voir ce que ça donne.

Maintenant que mes 2 années de prépas sont finies je peux enfin reprendre ce projet.
Et j'ai deja un nouveau probleme:
dans une fonction j'ai besoin d'annalyser précisement ce qui est affiché à l'ecran.
Pour se faire, je me positionne au debut de l'octet qui m'interesse:

BYTE *ptr;
ptr=LCD_MEM;
ptr+=(y*(is89?20:30)+(x>>3));

puis je recupere les données:

*ptr

c'est là que j'ai constaté que cette valeur change sans que ptr change, ce qui pose probleme!

exemple:

void _main(void)
{
clrscr();
short x=0,y=0;
BYTE *ptr;
ptr=LCD_MEM;
ptr+=(y*(is89?20:30)+(x>>3));
printf("%i,%li\n",(int)(*ptr),(long)(ptr));//là VTI renvoie 0,19456
printf("%i,%li\n",(int)(*ptr),(long)(ptr));//là VTI renvoie 56,19456 au lieu de 0,19456
printf("%i,%li\n",(int)(*ptr),(long)(ptr));//là VTI renvoie 56,19456 idem
while(!kbhit());
}

Je comprends pas pourquoi ça ne marche pas!
Quelqu'un peut m'aider, svp?

Hmm je suis pas certain de comprendre ton code, mais je pense que tu pourrais remplacer le (is89?20:30) par un 30 (Car la taille d'une ligne du buffer écran ne dépend pas du modèle de la calculatrice ^^)
Ensuite, si tu écris sur l'écran, ben évidemment que ce que tu lis change...

Oui mais ses printf n'ecrivent pas sur l'ecran (si il n'y a que ça comme code et qu'il y a pas d'ITs qui ecrivent)

Et son is89?20:30 n'influe pas sur la lecture faites avec le second et troisieme printfs..

Heu si ses printf n'écrivent pas sur l'écran ils écrivent où ? (cc)

A oui tiens, j'avais pas reflechi pour le (is89?20:30) merci!

parcontre ça ne change rien au probleme:
Je regarde un octet en particulier avec:

printf("%i,%li\n",(int)(*ptr),(long)(ptr));

or j'en met 2 à la suite, donc je n'ecris rien a l'ecran entre temps;
pourtant le resultat change!

GoldenCrystal :
Heu si ses printf n'écrivent pas sur l'écran ils écrivent où ? (cc)

Tu sais que tu es pas con ?


Elynx: tu regarderait pas (un peu) dans la zone ou le texte est affiché ?

Edit: je suis vraiment trés con!!
merci beaucoup Godzil!

Oui mais reflechi deux secondes, Printf affiche a l'ecran, tu es bien d'accord ?

Ton code lit le premier octet de l'écran, qui est vide a la premiere lecture (avant le premier printf)

Mais ton printf affiche un truc a l'ecran, et que ce passe t'il a la lecture suivante ?

merci encore godzil, j'avais repondu sans avoir vu ton post #315

Non remerci Golden, sans lui j'aurait pas fait le rapprochement ^^ (mais c'est vrai que l'erreur est tres bete, tellement bete qu'on n'y pense meme pas ^^)

Petit conseil, pour afficher l'@ d'un ptr utilise %p (normalement sa l'affiche en hexa en plus)

merci aussi GoldenCristal.
Si j'avais pas d'erreur à la con comme celle la j'avancerai plus vite dans mon projet...

t'inquiete, tout le monde fait ce genre d'erreur, plus ou moins bete, mais souvent tellement grosse qu'on ne les vois pas (pasque justement trop grosses ^^)

"Vu que ça a l'air plus facile à faire qu'une fonction de test des collisions qui gère deux hauteurs différentes, je ferai peut-être FastTestLine en premier"
ExtGraph 2.00 Beta 5-devel, disponible pour beta-test avec quelques autres programmes sur http://p080.ezboard.com/ftichessteamhqfrm10 , contient des fonctions du premier type, mais pas le deuxième... Je pense toujours que FastTestLine est plus facile à faire...

Personnellement, je trouve que lire l'écran n'est pas une bonne idée pour tester les collisions.
Ce qui est à l'écran, c'est simplement une interprétation du jeu. Elle pourrait varier (si par exemple tu adaptes ton jeu pour une autre plate-forme).

ouai mais c'est parfois très pratique.
Je sais vu que je j'utilisais au début une technique similaire pour bomberdude ():
J'avais fais une sorte d'écran virtuel qui ne servait qu'a détecter les collisions. Puis j'ai réalisé que l'écran virtuel n'avait pas besoin de faire la taille de l'écran... puis que je n'avais pas besoin de tous les pixels... bref j'ai fini avec un petit tableau (chaque case représentait 16x16 pixels )

Toi tu peux aussi faire un tableau, où chaque cases correspond à une zone de 2x2 pixels par exemple. Les collisions sont moins précises mais c'est plus rapide à détecter.

Je sais pas si c'est clair...

jfg -> c'est trés clair et plutot malin mais adapté à l'affichage avec sprite (methode sprite);

Pour simplifier j'appelle methode flash (comme les animations ".swf" du meme nom) le systeme d'affichage vectoriel que j'ai mis en place.

Je suis entrain de tester la methode de detection suivante:
grace à la methode flash je ne trace dans l'espace virtuel (qui n'a pas forcément la taille d'un ecran) que
les objets vectoriels qui sont proche de la zone à tester(ça m'évite ainsi de tout retracer à chaque fois)

Là j'utilise des fonctions de detection surfacique grace a ma FastTestHLine sur cet espace virtuel.

Voici un screenshot pour vous monter que mon projet est en pleine activitée.



Comme vous pouvez le voir j'ai fini par resoudre le probleme que j'avais au tout debut de mon projet, à savoir comment tracer des traits épais arrondis sur les bouts.

Mon projet avance vite en ce moment, et j'espere sortir quelque chose de jouable bientot...

" tracer des traits épais arrondis sur les bouts. "
tu fais comment finalement ?

C'est vraiment impressionnant que ça ne rame pas avec le zoom