Tutoriel et documentation - Wlib

Les numéros de slot commencent à 0, pas à 1

Code:

{1,2} -->Lwlib  // (1 = [strike]1er slot[/strike] indique la chaine dans laquelle sont rangés les sprites, donc Str1, et 2 = le nombre de Sprites )
8:prgmUSEWLIB // pour charger

{2,X,Y} -->Lwlib // [strike]2 = 2eme sprite ?[/strike] Non, 2 = 3e slot... Donc ça va pas, faut commencer à 0, donc 2e sprite = 1. X,Y en pixels ?
10:prgmUSEWLIB // pour dessiner dans le buffer

Sur ta capture:
{0,X,Y->WLIB
10:prgmUSEWLIB
Pour afficher le sprite sur le buffer, à la position (X; Y).

Oui j'ai pensé faire ça, mais comment saurais-tu combien d'arguments passer du coup ?

Mais toutes les fonctions n'attendent qu'un nombre fixe d'arguments non?

Du coup par exemple on pourrait faire:

Code:

"0123456789ABCDEF00FF00FF00FF00FF->Chaine1
{1,2,1,X,Y->WLIB
{8,10,13:prgmUSEWLIB

On sait que la fonction 8 attend 2 arguments, ce sont les 2 premiers dans LWLIB. Ensuite la fonction 10 en attends 3, ce sont les 3 suivants. Pour finir, la n°13 n'en attends pas.

Enfin le plus utile c'est de mettre les sprite-collisions ça c'est facile et pis ça aide pas mal...

J'avoue que je ne suis pas sur de ce dont tu parles

Avec la manière dont j'utilise les arguments, ça marche pas. Ce que je fais c'est que comme ils sont dans une liste au départ, je prends tous les arguments de la liste, je les convertis depuis float en entier, et je les stocke dans une aire de RAM libre. Ensuite j'y accède avec genre RAM, RAM+2, toussa. Dans le cas dont tu parles il faudra à chaque appel de fonction translater les arguments en ordre descendant, c'est beaucoup trop chiant. Je vais plutôt faire comme j'ai dit je pense, comme ça je convertis les arguments à chaque fonction.

translater les arguments en ordre descendant

Heu... Je ne vois pas trop ce que tu veux dire.

Mais je pensais à un truc faisable:
Tu recopies tous les arguments de toutes les fonctions dans une aire de RAM libre.
Tu traites la première fonction normalement (RAM, RAM+2 toussa comme tu dis)
Puis après tu fais tout simplement un petit lddr pour décaler les arguments qu'il reste

Mais bon après je ne sais pas ce qu'il en est dans ton code, donc c'est toi qui vois ce qui est le plus faisable .

L'autre avantage de ta méthode c'est que du coup on aurait plus besoin de LWLIB? On pourrait passer les nb d'arguments, arguments, n° de fonctions (comme tu l'as dis quoi) dans Ans?

m@thieu41 a écrit:Les numéros de slot commencent à 0, pas à 1

Code:

{1,2} -->Lwlib  // (1 = [strike]1er slot[/strike] indique la chaine dans laquelle sont rangés les sprites, donc Str1, et 2 = le nombre de Sprites )
8:prgmUSEWLIB // pour charger

{2,X,Y} -->Lwlib // [strike]2 = 2eme sprite ?[/strike] Non, 2 = 3e slot... Donc ça va pas, faut commencer à 0, donc 2e sprite = 1. X,Y en pixels ?
10:prgmUSEWLIB // pour dessiner dans le buffer

Code:



Sur ta capture:
{0,X,Y->WLIB
10:prgmUSEWLIB
Pour afficher le sprite sur le buffer, à la position (X; Y).

sur la tilem

ne m'affiche rien non plus ...
sur une vraie TI82 stat fr
ça affiche mais si je change ma chaine ça ne rafraichit pas
et la position Y si je mets 9 plus rien... {0,1,9} -->Lwlib

Bref je ne comprends trop rien...

Rafraîchis tu l'écran toi-même après avoir changé la chaîne ? Il faut appeler 12 fastcopy.

Toujours se méfier des émulateurs quand on touche aux ports et à l'écran. Des raccourcis abusifs peuvent exister. Le meilleur exemple que j'ai est l'extinction de l'écran par le bug de la fonction Rappel qui n'est pas correctement capturée.

Déplacer des arguments, même avec une instruction LDDR, ne dois pas satisfaire l'espoir de rapidité de matrefeytontias. Et puis il faut remplir les registres pour contrôler cette copie !
Pour lui c'est certainement plus simple de tout faire avec des mnémoniques d'adresses en dur (les RAM+1 etc).

Matrefeytontias, je crois que la description de la fonction 0 shiftupdown ne convient pas. Cela semble toujours prendre la valeur absolue et déplacer l'écran vers le bas de ce nombre de pixels. Si la fonction reconnaissait les négatifs, ce serait pratique pour nous. Mais pas pour toi j'imagine. (si tu commences toujours par copier la mantisse, alors pas de place pour la lecture du signe ensuite)

Quand ya deux spirites qui se chevauchent ça peut permettre d'émettre des conditions quand ya deux spirites quasi l'un sur l'autre. C'était utilise sur les vieilles consoles de jeu et surtout sur la game boy.

bon je me demande si je ne vais pas abandonner wlib
j'essaie de faire un sprite qui ferait le tour de l'écran et n'arrive à faire que le côté gauche (et encore...)
dois-je me contenter du basic ?  peut-être

Mais nooon

Aaaah mais oui au fait, ma routine de sprite ne peut afficher les sprites que si la coordonnée X est multiple de 8. Au fait.

je crois avoir essayé et jamais réussi a afficher en dehors de la 1ere colonne donc si as un exemple je suis preneur sinon ...

Linkakro a écrit:Déplacer des arguments, même avec une instruction LDDR, ne dois pas satisfaire l'espoir de rapidité de matrefeytontias. Et puis il faut remplir les registres pour contrôler cette copie !
Pour lui c'est certainement plus simple de tout faire avec des mnémoniques d'adresses en dur (les RAM+1 etc).

Ben... justement le décalage que j'ai proposé c'est pour avoir les adresses en dur... Mais de toute façon même si elles sont dans la liste, va bien falloir à un moment savoir ou il en est dans la liste... Et je pense qu'un lddr, même en comptant les infos pour les registres pour controler la copie, c'est plus rapide que de séparer le traitement des arguments, de tester le nombre d'arguments tout ça... Mais après ça dépends de comment il s'y prend pour gérer ça en fait...

Hum ... je viens de regarder le code ASM pour drawSprite et je viens de me rendre compte que je me suis gouré dans le readme --'

En fait c'est {X,Y,slot}→LWLIB. Désolé tout le monde -_-

Edité ça dans le message 1.

La colonne ne fonctionne que pour un multiple de 8 qui fait tomber sur une tuile entière contrairement à la ligne. La fonction est encore un peu rudimentaire. (les chevauchements latéraux seront bien plus pénible n'est-ce pas ? Il ne reste plus qu'à copier les routines complètes telles que celle montrée dans le tutoriel d'assembleur Z80 de OpenClassRooms)

M@thieu41 : je m'exprimes mal, je suis conscient que le déplacement LDDR permet ensuite d'utiliser des addresses dur, mais je voulais sous-entendre qu'il préfère ne pas rassembler plusieurs appels, car cela évite aussi bien les adresses relatives que le décalage LDDR qui y pallie.

Mais il a pas parlé de le faire mais d'une autre façon justement? En gérant une fonction puis l'autre?

matref a écrit:Une solution serait de tout stocker sous la forme {nb arguments, arguments, ..., n° fonction} et de répéter. Vu que je me débrouille pour n'utiliser que des nombres comme arguments ça devrait passer.

matrefeytontias a écrit:Hum ... je viens de regarder le code ASM pour drawSprite et je viens de me rendre compte que je me suis gouré dans le readme --'

En fait c'est {X,Y,slot}→LWLIB. Désolé tout le monde -_-

je comprends mieux pourquoi rien ne marchait ... une doc en inéquation c'est pas tip top ...

Ce qui me gêne avec LDDR c'est qu'il faut que le programme sache combien d'arguments VONT être pris en compte. Peut-être que je peux faire ça avec une table ceci dit ... Je vais essayer ça en fait, et si ça va pas j'essaye mon truc.

jo2geek ça va, on peut se tromper --'

Ouf bon je vais réessayer je croyais avoir fait une bêtise en codant mais voilà donc la solution x)
Merci matrefeytontias !!!
Autre chose: la fonction qui inverse tous les pixels de l'écran ne marche pas.

Ça inverse les pixels du buffer, pas de l'écran.

oui ça j'avais testé ça marchait nickel

OK donc il ne s'agit pas de l'écran graph, calcul et toussa ?

ce que j'ai compris
le buffer (une sorte de cache mémoire d'écran)
tu dessines sur le buffer
après tu charges le buffer sur l'écran par 12:prgmUSEWLIB

La fonction ShiftUpDown modifie le comportement de tout le système. Les fonctions scrollRight et scrollLeft modifient le graphique.
Toutes les autres fonctions de dessin modifient uniquement un tampon/buffer/cache qui doit être envoyé à l'écran par fastCopy.

matrefeytontias a écrit:jo2geek ça va, on peut se tromper --'

pas de soucis on n'est pas des robots

à bientôt

En fait, le mieux serait de ne plus à avoir à utiliser LWLIB, et de tout passer directement dans Ans. Niveau TI-Basic on y gagnerait je pense.

Donc soit comme tu avait proposé: {nb arguments, arguments, ..., n° fonction} répété X fois pour X fonctions, et on met juste cette liste dans Ans
Ou bien (si tu gères ça avec une table, ou autrement) : {n° fonction [, arguments, ...]} répété X fois pour X fonctions.

C'est comme tu le sens

Le truc c'est que je vais devoir tester le signe de Ans pour savoir si c'est bien une liste, et ça ça m'emmerde >_< au pire je peux dire "moui alors c'est à vous de faire en sorte que Ans soit toujours une liste et la bonne" mais le risque serait que programmer avec Wlib devienne aussi dangereux que programmer en ASM tout court. Actuellement ça va parce que je teste le nombre d'arguments dans chaque routine et renvoie un ERR:ARGUMENT si y'en a pas assez.

Le type de Ans tu veux dire?

Bah tu peux renvoyer une erreur syntaxe si c'est pas une liste non? C'est pas difficile à tester si c'est une liste ou pas si?

Ouais nan compte pas sur ça . Sinon on risque de prendre des ram clear à tout va .

Ouais c'est pas le but... x)
N'empêche qu'il faudra trouver quelque chose
Mais si t'y arrives, tant mieux