Nan je veux dire quand on copie le buffer à l'écran (l'écran est écrasé dans tous les cas), est-ce que j'en profite pour effacer le buffer ou pas ?

Je ne pense pas que ce soit intéressant dans tous les cas d'effacer le buffer. Si tu veux le faire d'une traite plutôt qu'en deux fois tu peux aussi inclure l'option dans les paramètres.

Moui à la limite je peux faire un paramètre qui vaut 0 pour conserver le buffer et 1 pour l'effacer.

Non. Sinon on est obligé de tout refaire à chaque fois (imaginons qu'on fasse un jeu, on charge tout dans le buffer, on affiche, là tu effaces le buffer, donc si on veut faire bouger le perso, on est obligé de tout recharger dans le buffer, ce qui n'est pas pratique du tout).
Il vaut donc mieux ne pas effacer le buffer. Dans un autre langage plus rapide ça pourrait être bien (même pour ma part je n'ai pas rencontré cette option dans des bibliothèques C++/Java), mais là ça pourrait ralentir le prgm dans certains cas, donc c'est pas top. Mieux vaut avoir à effacer le buffer au besoin qu'à tout réécrire.

Je crois pas que vous vous rendiez compte d'à quel point la vitesse change : effacer le buffer dans la fonction d'affichage prend deux dixième de seconde (à 1 milliseconde près, autant qu'afficher le buffer sans l'effacer - valeurs réelles), et l'afficher avec un appel de fonction puis l'effacer prend 5 dixièmes de seconde. L'impact sur la vitesse est vraiment énorme. Je vais donc prendre un paramètre pour effacer le buffer ou pas.

Avec un paramètre pour choisir de l'effacer ou pas ça va, mais il vaut mieux ne pas le faire systématiquement.

Par contre tes chiffres me surprennent: effacer le buffer prends 3 dixième de secondes alors que l'afficher n'en prend que 2?
Pourtant travailler avec le port écran est assez long (il faut souvent faire des instructions rien que pour attendre que l'écran soi prêt), alors que mettre à 0 une partie de la mémoire... ça se fait en 4-5 instructions non?

Oui effectivement j'ai confondu les deux.

En fait l'exécution du programme ASM prend 2 dixièmes de secondes à lui tout seul, les fonctions de WLib elles-même prennent en général moins d'un dixième de seconde. Donc moins on fait d'appels au programme, plus vite on va.

C'est sûr, mais du coup s'il faut ré-afficher des trucs qu'on aurait pu conserver, bah ça fait encore plus d'appels au prgm.
Donc le rendre optionnel est une bonne chose à mon avis.

Bon à part ça, WLib permet maintenant :

• De scroller le buffer dans les 4 directions d'un nombre de pixels donné
  
• De vérifier l'existence d'un programme
  
• De créer un programme d'une taille donnée (je pense changer ça en juste "créer un programme")
  
• Allumer, éteindre ou inverser un pixel du buffer
  
• Charger des sprites dans la mémoire (plus d'explications ci-dessous)
  
• Inverser les pixels du buffer
  
• Afficher le buffer à l'écran

Je me suis vite rendu compte qu'allumer/éteindre/inverser un pixel avec WLib était environ 1.5 fois plus lent qu'allumer/éteindre/inverser un pixel en TI-Basic, mais avec WLib ça influe sur le buffer. Tout ça à cause de la manière dont le TI-Basic lance des programmes ASM. Pf. Peut-être que pour rendre la commande de pixels un peu plus utile je pourrais faire en sorte qu'elle allume un nombre théoriquement infini de pixels ? Du style, pour allumer les pixels aux quatres coins de l'écran on ferait :

Code:

:{0, 0, 95, 0, 95, 63, 0, 63}→LWLIB
:5:Send(9prgmWLIB)

Ensuite, à propos des sprites, ce que je prévois est de charger les sprites dans des slots, c'est à dire des emplacements mémoire référencés par un nombre. L'intérêt est que la conversion token → hexadécimal se fait une seule fois par sprite. Donc pour afficher un sprite on ferait :

Code:

:ChargerSprites(Str1, 1, slot1)
:AfficherSprite(X,Y,slot1)

On aurait donc ChargerSprites(Str, nb_de_sprites, slot_de_départ).

Vous voulez quoi comme paramètres pour le tilemapping ? J'ai un peu de mal à imaginer.

Je ne pensais pas à manipuler un pixel à la fois mais qu'un sprite agisse comme un masque d'une opération logique. Si tu fais ça pour un masque cela devrait être plus rapide que de faire chaque pixel en Basic. Et la distinction set/reset/toggle est un bonus qui pourrait se montrer bien utile.

Est-ce indispensable que les paramètres et données soient en format token hexadécimal ? Si on écrit un outil potable sur ordinateur du genre stocker un bitmap dans une Pic ou autre, alors cela augmenterait les capacités, bien que ce stockage ne soit plus entièrement contrôlable en Basic sur la TI.

Je pense qu'il faudrait avoir la possibilité de copier un sprite déjà stocké dans un "slot" pour le stocker dans un autre slot, ou bien récupérer l'hexadécimal en tokens.

Le tilemapping necessiterait selon moi :
-le stockage de chaque tile, organisé par tableau ou slots
-le choix d'un certain nombre de tile différentes pour la map
-le codage de la map (avec naturellement un certain nombre de pixels contigus codant l'identité d'un tile, cela pour chaque til)

(Ou bien le stockage brut de toutes les tiles dans le tableau au lieu de stocker la map et les sprite séparément. Mais la map et les sprites c'est plus souple)

Et enfin, si tu appliques "MoreVar" pour utiliser les noms de variables pirates, tu peux peut-être t'arranger pour donner accès en basic aux données de sprite et tilemap. En réservant une partie des noms à WLIB.

Coooool!!!! ca avance!!
chaque jour je pense qu'un pokemon est de plus en plus faisable maintenant!!!
ca ressemble de plus en plus a x-lib, continuez comme ca!!!!

Linkakro je demandais quels paramètres devrait prendre la fonction, pas comment elle fonctionnerai ...

Moi je pense à ça : AfficherTilemap(str_tilemap, x_départ, y_départ, largeur_à_afficher, hauteur_à_afficher)

Le plan serait que la tilemap soit déclarée du genre "1111100110011111"->Str1 pour une map 4*4, qu'on puisse afficher n'importe quelle tilemap et que le tilescrolling soit supporté.

Tu peux envoyer une preview à ton bêta testeur unique et préféré ?
( <3 <3 <3 )

Pour moi le fonctionnement définit les données à échanger et les actions donc les fonctions et leurs paramètres.

:ChargerSprites(Str1, 1, slot1)
:AfficherSprite(X,Y,slot1)

Moi je pense à ça : AfficherTilemap(str_tilemap, x_départ, y_départ, largeur_à_afficher, hauteur_à_afficher)

Le plan serait que la tilemap soit déclarée du genre "1111100110011111"->Str1 pour une map 4*4, qu'on puisse afficher n'importe quelle tilemap et que le tilescrolling soit supporté.

Cela signifie-t-il qu'il y a forcément 16 sprites maximum possible ?
Je trouve dommage qu'on ne puisse pas optimiser selon leur nombre.
Est-ce important d'écrire chaque caractère en tant qu'un bit ? Hexadécimal me plairait, est-ce vraiment trop dur pour les noobs ?
Je préfèrerais que tu stockes la tilemap de la même façon que tes slots.
Si tu ne stockes pas en compilé, autant écrire la map avec les identifiants des slots, cela prendrait moins de place et ce serait plus ludique (pour les incultes surtout).

Persalteas quand j'aurai fini les tilemaps promis

Linkakro c'est de l'hexa, c'est juste que je suppose qu'il n'y a que deux tiles chargées pour l'exemple (d'ailleurs y'a 16 = 4*4 caractères). Un token 6 dans la map affichera le sprite du slot 6.

Oui 16 tiles suffisent puisqu'on peut translater des sprites dans les slots. J'ai donc pensé à une fonction de déplacement et une fonction d'échange de sprites (mettre un slot dans un autre ou échanger deux slots).

Les gens ... epic update !!!

J'ai installé un moyen simple de rendre un programme Basic utilisant WLib compatible toutes z80 : quand vous utilisez WLib, envoyez deux programmes à votre calto, prgmUSEWLIB et prgmWLIB. Prenez évidemment la version des deux programmes qui correspondent à votre calto. Ensuite, dans le programme Basic utilisant WLib, à la place de Asm(prgmWLIB) ou Send(9prgmWLIB), utilisez simplement prgmUSEWLIB. Comme ça, dans la version 83p de USEWLIB y'aura Send(9prgmWLIB), et dans la version 8xp y'aura Asm(prgmWLIB) ! De cette manière, le même programme Basic marchera partout tant que vous avez les bons programmes !

Ensuite, WLib est maintenant capable de :

• Scroller l'écran (pas le buffer) en haut ou en bas de manière instantanée ! {colonne de l'écran à afficher en première}→LWLIB : 0 : prgmUSEWLIB
  
• Scroller le buffer à gauche ! {nombre de pixels à scroller}→LWLIB : 1 : prgmUSEWLIB
  
• Scroller le buffer à droite ! {nombre de pixels à scroller}→LWLIB : 2 : prgmUSEWLIB
  
• Vérifier l'existence d'un programme ! {numéro de la Str contenant le nom du programme}→LWLIB : 3 : prgmUSEWLIB
  
• Créer un programme et l'écraser s'il existe déjà ! {numéro de la Str contenant le nom du programme, taille du programme en octets}→LWLIB : 4 : prgmUSEWLIB
  
• Allumer un pixel ! {X, Y}→LWLIB : 5 : prgmUSEWLIB
  
• Éteindre un pixel ! {X, Y}→LWLIB : 6 : prgmUSEWLIB
  
• Changer l'état d'un pixel ! {X, Y}→LWLIB : 7 : prgmUSEWLIB
  
• Charger des sprites dans des slots ! {numéro de la Str contenant les sprites, nombre de sprites}→LWLIB : 8 : prgmUSEWLIB
  
• Charger une tilemap !!! {numéro de la Str contenant la tilemap, taille en octets (largeur*longueur), offset de départ où charger la tilemap}→LWLIB : 9 : prgmUSEWLIB
  
• AFFICHER UNE TILEMAP CHARGÉE !!! 10 : prgmUSEWLIB
  
• Afficher le buffer à l'écran ! 11 : prgmUSEWLIB
  
• Inverser les pixels du buffer ! 12 : prgmUSEWLIB
  

Et voilà, le tout en 763 octets ! Joyeux Noël !

Maintenant, explications :

• Tous les sprites doivent être stockés en hexadécimal, similaire au format des sprites Axe ou Assembleur.
  
• Pareil pour les tilemaps, ce qui veut dire qu'une tilemap peut contenir maximum 16 tiles différentes (0 à F).
  
• Un slot est un truc interne à WLib, pis 'toute façon vous en avez pas l'usage actuellement. Vous en occupez pas pour le moment, mais ça viendra.
  
• Chaque paquet de plusieurs sprites doivent aller à la suite dans la même Str pour être chargé correctement !
  
• Idem pour les tilemaps, tout à la suite dans la même Str !
  

Testé sur 83+, je laisse aux possesseurs de TI non-flash le soin de tester, mais attention, les zones mémoires que j'utilise dans WLib sont okay sur 83+, mais je ne connais pas leur utilité sur 82 stats. J'ai quand même vérifié par mes propres moyens que ça soit pas trop la merde, mais soyez prudents quand même, je ne sais pas l'effet que ça peut avoir.

Télécharger WLIB

Screenshot pris sur une 83 émulée :


Faites-moi part des résultats des tests sur 83 surtout

Bon ben tout le monde s'en fout, c'est bien. --'

(  

Si on ne réponds pas en 10h (pendant la nuit qui plus est) une journée (j'avais mal regardé), c'est peut être parce que c'est les vacances, donc on est pas connectés 7j/7 24h/24 )

Ce que tu as fait est juste super, bravo !
On va pouvoir faire des choses géniales avec ta librairie

J'ai quelques questions:

Scroller l'écran (pas le buffer) en haut ou en bas de manière instantanée ! {colonne de l'écran à afficher en première}→LWLIB : 0 : prgmUSEWLIB

Qu'entends tu par "colonne de l'écran à afficher en première" ?

Charger des sprites dans des slots ! {numéro de la Str contenant les sprites, nombre de sprites}→LWLIB : 8 : prgmUSEWLIB
Charger une tilemap !!! {numéro de la Str contenant la tilemap, taille en octets (largeur*longueur), offset de départ où charger la tilemap}→LWLIB : 9 : prgmUSEWLIB

Les sprites ont des dimensions fixées par WLIB ?

Pour la dimension de la tile map, si on veut faire un truc de 10*15 ou de 15*10, on indique pour les 2 cas 150... Comment distinguer ces 2 cas?

Une dernière chose:

Pareil pour les tilemaps, ce qui veut dire qu'une tilemap peut contenir maximum 16 tiles différentes (0 à F).

Pourquoi cette restriction?
Je ne sais pas trop comment tu traites les données qui sont dans la chaine, mais ce n'est pas du vrai héxadécimal, donc j'imagine que ce ne serait pas très dur d'autoriser à donner des numéros de 0 à Z au lieu de 0 à F, comme ça on a bien plus de sprites possibles.

Pour le scrolling.haut/bas, si tu passes 32 en paramètres les deux moitiés de l'écran seront inversées puisque la 32ème ligne sera affichée tout en haut, comme si c'était la première.
Les sprites sont toujours 8*8, et le resteront.

C'était juste un essai de tilemaps là, la fonction finale prendra largeur et hauteur en argument.

Je mets cette restriction parce que de cette manière, tout rentre en un caractère et est convertit en un octet poir WLib. Impossible d'aller au-delà puisque je travaille par paquets de deux tokens et pas par tokens pour aller plus vite avec moins de code. Si tu veux des sprites différentes pour la même map, charge des sprites différents tout en gardant la même map chargée.

Ah ok c'est la première ligne à afficher alors, pas la première colonne

Et est-ce qu'il sera possible (avec une autre fonction) d'afficher des sprites de dimension choisie?

Si tu veux des sprites différentes pour la même map, charge des sprites différents tout en gardant la même map chargée.

Tu veux dire changer l'apparence d'un certain numéro de tile sur toute la tile map? C'est pratique mais ce n'est pas tellement ce à quoi je pensais
Mais pourquoi gérer les tokens 2 à 2? J ne comprends pas trop comment tu t'y prends en fait.
Et s'il y a un nombre impair de tiles? (du genre 11*11)

Je gère les tokens deux par deux pour dessiner deux tiles à la fois. "7A" fait deux caractères, mais je peux le transformer en un seul octet, 7A, contrairement à "7G". Ça c'est pour les sprites. Pour les tilemaps, oui je peux faire de 0 à Z pour 36 tiles par map, faudra que j'y bosse - ce qui veut dire un caractère par tile.

Je vois bien comment tu peux passer de 2 caractères à un octet, mais ce que je ne comprends pas c'est comment tu fais pour traiter cet octet ensuite, et pourquoi tu le fais... Pour les sprites c'est sur que c'est efficace (puisqu'un octet bah c'est une ligne du sprite) mais pour les tilemaps, je ne vois pas l’intérêt: il faut de toute façon traiter séparément les 2 quartets de l'octets non?

Ben oui c'est ce dont je me suis rendu compte et que je viens de dire. On pourra donc utiliser 0-9 et A-Z pour 36 tiles par map.

Ok super

Sinon pour gérer les objets qui se déplacent sur la tilemap tu compte t'y prendre comment?
Et la caméra sera gérée par WLib ou manuellement?

Les objets sont gérés manuellement et la caméra par WLib.

C'est un peu contradictoire?
Je me suis mal exprimé alors: je voulais savoir si on pouvait faire en sorte que la caméra "suive" un objet, mais comme ils sont gérés manuellement, ça veut dire que non.

Ca risque d'être plus lent de gérer les objets manuellement (du coup on est obligé de travailler avec des matrices en ti basic pour une grande tilemap, et c'est leeeeent).
Ca ne serait pas possible d'instaurer une gestion des objets (en accordant certaines propriétés préfixées à des tiles)? Du style la tile 0 bloque dans tout les sens, la tile 1 est traversable, la tile 2 peut être détruite, etc (un peu comme la gestion que j'avais avec mario, mais en plus général (en accordant les propriétés avec les tiles et non pas chaque case)).
Et avoir un perso qui est suivi par la caméra (avec un écart max avec le centre)?

Moi je voulais dire que la tilemap est scrollée par WLib. Genre tu charges une tilemap 60*60 et quand tu la dessines tu passes des offsets en argument.

Mais là il reste le problème de la gestion des collisions entre les objets.
Regarde comment mario est lent: l'affichage est réduit au strict minimum (terrain géré par les statplot et perso affichés avec du texte), et ce qui fait tout ralentir c'est le fait de charger la matrice à chaque scroll, et aussi de récupérer et tester les valeurs de la matrice.

Je ferai une fonction qui renvoie la tile située aux coordonnées passées en argument. Pour les collisions entre objets autres que tiles, va falloir faire manuellement.

Ok.

Cette histoire de caméra, c'est ce qu'il y a dans pokémon rouge et mario bros mais qui n'était pas dans zelda the link's awakening (map de 2560*2048 pixels divisés en maps d'environ 160*130).
Au début, on sera forcés de commencer avec une gestion des maps comme dans zelda sur game boy (pour decouvrir les fonctions de w-lib et apprendre a les utiliser ) et ensuite on fera comme dans pokemon et on refera topaze sur 83.

Spoiler: