Posté le 02/02/2007 à 21:33 Membre depuis le 15/03/2005, 3470 messages
ça marche avec le pxl-test corrigé ? (je teste évidemment pas.. .. )


Oui, ça marche.
Comme souvent ce n'est pas bien compliqué... une fois qu'on a compris wink


> T*(1-pxl-test(62-(W+2DW+DX*A),X+2DX+DW*A))->T

Faut déjà connaitre chaque fonctions et chaques valeurs des variables, etc... 'fin bon, après c'est peut être plus rapide.
Posté le 02/02/2007 à 21:35 Membre depuis le 09/07/2003, 21783 messages
arf j'ai cross-édité (sur un détail )
Posté le 02/02/2007 à 21:39Edité par very le 02/02/2007 à 21:55 Membre depuis le 09/07/2003, 21783 messages
Deeph (./30) :
Comme souvent ce n'est pas bien compliqué... une fois qu'on a compris wink.gif


> T*(1-pxl-test(62-(W+2DW+DX*A),X+2DX+DW*A))->T
Faut déjà connaitre chaque fonctions et chaques valeurs des variables, etc... 'fin bon, après c'est peut être plus rapide.


-La bricole (inutile ?) avec le T, ça peut façilement se comprendre: au début il vaut 1, le '1', c'est la valeur 'y'a pas collision':
.si pxl-test renvoie 0 (donc résultat négatif), on fait (1-0)*1->t, donc il reste à 1
.si pxl-test renvoie 1 ( collision ! ), on fait 1*(1-1)->t, donc il vaut 0 à ce moment là, et comme on fait à chaque fois (1+truc)*t->t, si t vaut 0 à une étape, il restera toujours nul.. ( machin*0 = 0 cheeky )

Si il y a collision, on annule les 'déplacement' (on 'remplace' DX par DX*0, idem pour DW), sinon, on fait rien (puisque *1 )

-Le 2*DW et 2*DX, ça se comprend bien aussi: tu teste deux cases 'en avant' de ton sens de déplacement. (et ça me gène pas de mettre chacun de son coté, car quand l'un est non-nul, l'autre est nul. ). regarde dans chacun des tests que t'avais au début, ça correspond exactement à ça smile
-Le Dx*A et DW*A, c'est du bricolage opportuniste: regarde sur ton shéma, pour vérifier la collision, tu te place 2 cas en avant du sens de déplacement, et 'défile' les case de l'autre direction (si tu te déplace vers le haut, tu va regarder trois cases alignés horizontalement). C'est pour ça que les expression soit 'croisés' (et que je l'ai mal écrit au début..). Donc si DX fait +/-1, tu va bien faire défiler les Y. De plus, que ça fasse 1 ou -1, tu t'en fout, car (DX*A) va soit valoir -1,0,1 soit 1,0,-1.. ça prend le même valeur, et l'ordre on s'en fout..( tant qu'il est conservé le long de la boucle..)
En gros, on ruse sur le fait que ça vaille 0 ou +-1 pour annuler/valider le déplacement dans un sens, et on joue sur la symétrie de la boucle pour simplifier encore...

je sais pas si t'a tout suivi... n'hésite pas à formuler des questions si tu veux..



Posté le 02/02/2007 à 21:44 Membre depuis le 15/03/2005, 3470 messages
cheeky maintenant je comprend un peu mieu, mais j'aurai jamais eu l'idée de faire comme ça (mwa avec mes vieux 'If:Then:End' cheeky)...

Par contre, le dernier programme à toujours les touches inversée et est plus lente que la version avec une 'If' (comme quoi smile). Donc bon, je vais faire avec la version 'If' (que je comprend déjà mieu)... Merci !
Posté le 02/02/2007 à 21:50 Membre depuis le 09/07/2003, 21783 messages
( j'ai encore cross-édité )
Posté le 02/02/2007 à 21:53 Membre depuis le 09/07/2003, 21783 messages
Deeph (./33) :
Par contre, le dernier programme à toujours les touches inversée et est plus lente que la version avec une 'If' (comme quoi smile.gif ). Donc bon, je vais faire avec la version 'If' (que je comprend déjà mieu)... Merci !

pour corriger de manière brutale: X-DX->X:W-DW->W grin (je vois pas trop d'ou ça vient.. ça inverse les 4 touches ?)

'le' dernier, c'est quand j'ai supprimé les if pour les touches, ou après lorsque j'ai supprimer (pour faire beau) le if du pxl-test ?

Posté le 02/02/2007 à 21:56 Membre depuis le 15/03/2005, 3470 messages
ça inverse les 4 touches ?


Oui (mais bon, le code est quand même très lent sur TI 83+ normale...).
'le' dernier, c'est quand j'ai supprimé les if pour les touches, ou après lorsque j'ai supprimer (pour faire beau) le if du pxl-test ?


C'est le 'tout dernier', donc celui où tu as enlevé le 'If' du pxl-Test.
Posté le 02/02/2007 à 22:03 Membre depuis le 09/07/2003, 21783 messages
Arf oui, avec ça, ça devrait aller:

31→W:47→X
Line(46,39,48,39
While 1
Pt-On(X,W,2
Repeat K
getKey→K
End

int(K/24)*int(26/K)*(K-25)->DX
int(K/25)*int(34/K)*iPart((29.5-K)/4.5)->DW
1->T
For(A,-1,1
T*(1-pxl-test(62-(W+2DW+DX*A),X+2DX+DW*A))->T
End
Pt-Off(X,W,2
X+DX*T→X
W+DW*T→W
End


Note sur l'usage calculatoire du getkey: ça peut être très performant si l'on a d'autre conditions à implémenter sur le déplacement (me souvient notamment que sur un jeu de voiture à défilement vertical, ... ). Je l'ai sorti plus pour montrer qu'il existait autre chose que des If (et c'est parfois très avantageux !), mais bon c'est vrai que là avec des if si simples smile
(mais bon, le code est quand même très lent sur TI 83+ normale...).

y'a une grosse différence avec la version 4*if ?
Sinon, très lent, pour une bout pareil, ça me parait louche...
le pxl-test, c'est pas ça qui ralentie aussi ?

Si tu veux gagner en vitesse quitte à perdre de la taille, on peut , au lieu de faire une boucle sur pxl-test, dérouler la boucle en faisant la somme: il suffit de tester (directement) si elle est nulle. Mais bon pas sur que ce soit hyper significatif..
Posté le 02/02/2007 à 23:28 Membre depuis le 15/03/2005, 3470 messages
le pxl-test, c'est pas ça qui ralentie aussi ?


Surement, mais je vois pas comment tester des collision autrement que par des pxl-Test (et les matrice ne sont pas asser grandes pour du 94x62, et je me vois mal assigner des valeurs à chaques cases de la matrice cheeky).
y'a une grosse différence avec la version 4*if ?


Pas sur une Silver édition (ou 84+), mais sur la TI 83+ 'normale', on voit tout de suite la différence.
Posté le 03/02/2007 à 12:15 Membre depuis le 15/03/2005, 3470 messages
Deeph (./38) :
le pxl-test, c'est pas ça qui ralentie aussi ?


Surement, mais je vois pas comment tester des collision autrement que par des pxl-Test (et les matrice ne sont pas asser grandes pour du 94x62, et je me vois mal assigner des valeurs à chaques cases de la matrice cheeky).
y'a une grosse différence avec la version 4*if ?


Pas sur une Silver édition (ou 84+), mais sur la TI 83+ 'normale', on voit tout de suite la différence.


edit : V'là une nouvelle screen :



J'ai refait le menu (et ajouter l'option 'Options' cheeky). Le mouvement est à cette vitesse sur TI 83+ normale mais sur Silver édition, c'est bien plus rapide.
Posté le 03/02/2007 à 15:06 Membre depuis le 09/07/2003, 21783 messages
.Pour accélérer, tu peux faire des mouvements de plus d'un pixel..
.souvent, c'est l'effacement/redessinage qui prends bcp de temps: optimise à fond cette partie là; tu n'a besoin d'effacer que 4 pixels et d'en rallumer que 4 également.
.Quitte à avoir une forme qui ressemble un peu à rien, regarde si ça pourrait pas convenir avec l'instruction text( et un caractère quivabien.;( genre le petit rond..)
.Puisque tu fais du basic étendu, je pense vraiment que si y'a qqch à coder en asm, ce serait bien ça smile
Posté le 03/02/2007 à 17:35 Membre depuis le 09/02/2005, 13736 messages
=> je preconise aussi l'astuce du mode texte

Sinon ton Flacdo c'est une claque graphique tout de meme ! top
Posté le 03/02/2007 à 19:02 Membre depuis le 15/03/2005, 3470 messages
.Puisque tu fais du basic étendu, je pense vraiment que si y'a qqch à coder en asm, ce serait bien ça smile


Faudrai déjà que je sache faire ça cheeky.
.Quitte à avoir une forme qui ressemble un peu à rien, regarde si ça pourrait pas convenir avec l'instruction text( et un caractère quivabien.;( genre le petit rond..)


Oui mais dès qu'on s'approche d'un mur, il s'éfface, c'est due au fait que le caractère dépasse un peu.
Sinon ton Flacdo c'est une claque graphique tout de meme ! top


C'est bof, hein, la plupart du temps c'est du 'menu(' (pour les images, je les avaient faites sur PC avec Iview).
Posté le 03/02/2007 à 20:18 Membre depuis le 09/02/2005, 13736 messages
(pour les images, je les avaient faites sur PC avec Iview)

Cool, faudrait que j'essaie alors smile
Posté le 03/02/2007 à 20:54 Membre depuis le 15/03/2005, 3470 messages
Voilà un lien pour le télécharger :

-Ici pour l'exe;

-Ici pour le pack complet.

Enfaite, il faut faire ses images avec Paint (ou autre) et ensuite, les convertir en image pour les TI 82/83/83+ (c'est très pratique, mais maintenant je fait ça en ASM, donc bon...).
Posté le 03/02/2007 à 21:16 Membre depuis le 09/07/2003, 21783 messages
Deeph (./42) :
.Quitte à avoir une forme qui ressemble un peu à rien, regarde si ça pourrait pas convenir avec l'instruction text( et un caractère quivabien.;( genre le petit rond..)

Oui mais dès qu'on s'approche d'un mur, il s'éfface, c'est due au fait que le caractère dépasse un peu.

est-ce vraiment nécessaire de se rapprocher à 1 pxl-près d'un mur ? ne peut-tu pas bloquer juste avant ?
ça peut valoir le coup de faire un compromis sur des choses comme ça pour gagner en fluidité..

Posté le 03/02/2007 à 21:34 Membre depuis le 15/03/2005, 3470 messages
Heu à mon avis en voulant arreter chaque fois le point avant le mur, je risque de rendre le code plus long et donc là ce sera encore plus long et lent.
Posté le 03/02/2007 à 21:48 Membre depuis le 09/07/2003, 21783 messages
bha non ça revient au même..
Posté le 03/02/2007 à 22:23 Membre depuis le 15/03/2005, 3470 messages
Voilà, donc je peut difficilement faire mieu (mais c'est quand même très jouable).
Posté le 03/02/2007 à 23:07 Membre depuis le 09/07/2003, 21783 messages
Si !!
le 'bha non ça revient au même', c'est pour les test (au pire tu va tester 5 case au lieu de 3..), mais en ce qui concerne l'affichage, tu devrait gagner vraiment beaucoup, au final, je pense que t'a vraiment à y gagner.
Ecoute au moins mastercalto si tu ne veux plus m'écouter wink ( demande-lui de faire SF6 avec ta méthode et tu va voir grin )
Posté le 03/02/2007 à 23:17 Membre depuis le 15/03/2005, 3470 messages
Mouais mais franchement là j'ai pas trop envi de refaire le code de l'affichage alors que j'ai déjà due tout refaire dans le jeu... 'J'essairai' peut être cette autre méthode dans la semaine si j'ai d'autres heures de perm' (ce qu'est très probable cheeky)... (Ou alors si vous voulez m'aider, vous pouvez toujours poster votre code, parce que le mien ça risque encore d'être du style 'If:Then:End')
Posté le 04/02/2007 à 10:30 Membre depuis le 01/12/2005, 413 messages
Deeph (./42) :
.Puisque tu fais du basic étendu, je pense vraiment que si y'a qqch à coder en asm, ce serait bien ça smile


Faudrai déjà que je sache faire ça cheeky.


c'est pas difficile, tu mets les coordonnees dans X et Y, tu fais un prog asm qui affiche un sprite aux bonnes coordonnees en recuperant ces donnees.
Je peux t'aider si tu veux.
Posté le 04/02/2007 à 10:32 Membre depuis le 09/02/2005, 13736 messages
>Deeph, merci pour le pack smile

Sinon pour l'affichage en basic etendu, xLib c'est la librairie ultime hein (suffit de voir les RPG de Kevin...), ou :

73460.gif

Posté le 04/02/2007 à 10:42 Membre depuis le 15/03/2005, 3470 messages
c'est pas difficile, tu mets les coordonnees dans X et Y, tu fais un prog asm qui affiche un sprite aux bonnes coordonnees en recuperant ces donnees. Je peux t'aider si tu veux.


Je sais déjà faire ça, mais a n'avancera à rien de le faire en ASM puisqu'il faudra quand même vérifier les collisions en Basic.
merci pour le pack smile


De rien smile.
Sinon pour l'affichage en basic etendu, xLib c'est la librairie ultime hein (suffit de voir les RPG de Kevin...)


Je sais bien, mais je voudrai utiliser seulement ma Lib, et puis c'est déjà très bien comme ça (je ferai peut être un Sims 2 avec Xlib, mais ce sera pas avant que j'ai finit celui-ci).
Posté le 04/02/2007 à 11:35 Membre depuis le 09/07/2003, 21783 messages
Deeph (./53) :
c'est pas difficile, tu mets les coordonnees dans X et Y, tu fais un prog asm qui affiche un sprite aux bonnes coordonnees en recuperant ces donnees. Je peux t'aider si tu veux.

Je sais déjà faire ça, mais a n'avancera à rien de le faire en ASM puisqu'il faudra quand même vérifier les collisions en Basic.

Mais si, tu gagnera déjà tout le temps que tu perd à afficher/effacer, et parfois c'est ça qui ralenti tout en basic...
Pour tester, c'est simple: retire la partie effacer:afficher du code, et regarde si ça rame autant..
Posté le 04/02/2007 à 11:50 Membre depuis le 15/03/2005, 3470 messages
Je ferai ça plus tard, parce que franchement c'est pas si lent que ça sur 84+ et Silver édition...
Posté le 05/02/2007 à 01:38 Membre depuis le 04/02/2007, 16 messages
Deeph (./8) :

Le personnage est représenté pas un carré (donc 'Pt-On(Y,X,2' ), et je voudrai tester les collisions avant qu'il n'avance.

Voici une petite image pour illustrer :

pton2gy3.png


Tout d'abord, cela ne fonctionne pas puisque dans Pt-On(Y,X,2), X devrait prendre la place de Y (puisque selon TI, la synthaxe officielle est Pt-On(X,Y[,argument]), le contraire de pixel-on(Y,X))

Ensuite, pour le code, les For() ne sont utiles que lorsque leur taille totale est plus petite que la taille du reste des instructions à faire ou que le nombre à faire est trop grand.

Le code suivant implique que 0<X<96 et que 0<W<62
0->Ymin:0->Xmin:62->Ymax:94->Xmax
AxesOff:GridOff
ClrHome
31->W:48->X
Lbl 1
while 1
Repeat K
getKey->K
End
If K=25 and not(pxl-Test(X-1,W+2)+pxl-Test(X,W+2)+pxl-Test(X+1,W+2
Then
Pt-Off(X,W,2
W+1->W
End
If K=34 and not(pxl-Test(X-1,W-2)+pxl-Test(X,W-2)+pxl-Test(X+1,W-2
Then
Pt-Off(X,W,2
W-1->W
End
If K=24 and not(pxl-Test(X-2,W+1)+pxl-Test(X-2,W)+pxl-Test(X-2,W-1
Then
Pt-Off(X,W,2
X-1->X
End
If K=24 and not(pxl-Test(X+2,W+1)+pxl-Test(X+2,W)+pxl-Test(X+2,W-1
Then
Pt-Off(X,W,2
X+1->X
End
Pt-On(X,W,2End
Posté le 05/02/2007 à 08:47 Membre depuis le 09/07/2003, 21783 messages
Tu n'a pas lu les deux pages Fallen Ghost ? ( ta corrrespondance pt/pxl foire là, pourtant on a tout expliqué pas très loin )

Sinon, tant qu'a y aller comme ça, ça peut se factoriser aussi..
Posté le 05/02/2007 à 13:51 Membre depuis le 04/02/2007, 16 messages
Voici la documentation officielle de TI:
Pt.On(x,y[,mark])
Pt.Off(x,y[,mark])
Pt.Change(x,y)

Pxl.On(row,column)
Pxl.Off(row,column) Pxl.Change(row,column)


Je vois pas ou je me suis planté...

Puis le fait est que lorsque l'on fait pt-on(X,Y,2), (X,Y) correspondent au pixel blanc...
Posté le 05/02/2007 à 14:42 Membre depuis le 09/07/2003, 21783 messages
Il ne suffit pas d'inverser les X et Y pour passer des échardonnées pt aux coordonnées pxl, l'origine n'est pas la même (ni le sens de l'axe vertical), cf ./16 , ./18 smile
Posté le 05/02/2007 à 15:10 Membre depuis le 04/02/2007, 16 messages
Bien, l'origine pourrait être au même endroit si Ymax=0 et Ymin=-62...