ç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.
arf j'ai cross-édité (sur un détail )
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..



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 !
( j'ai encore cross-édité )
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 ?

ç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.
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..
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.
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.
.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
=> je preconise aussi l'astuce du mode texte

Sinon ton Flacdo c'est une claque graphique tout de meme ! top
.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).
(pour les images, je les avaient faites sur PC avec Iview)

Cool, faudrait que j'essaie alors smile
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...).
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é..

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.
bha non ça revient au même..
Voilà, donc je peut difficilement faire mieu (mais c'est quand même très jouable).
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 )
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')
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.
>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

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).
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..
Je ferai ça plus tard, parce que franchement c'est pas si lent que ça sur 84+ et Silver édition...
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
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..
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...
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
Bien, l'origine pourrait être au même endroit si Ymax=0 et Ymin=-62...