WLib : Topic de dev

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:

Voilà c'est à peu près à ça que je pensais, faire des changements brusques de maps qui font la taille de l'écran et pas de scrolling. Ça me semblait être la seule solution viable par rapport à la vitesse.

Bah non on peut directement faire une caméra déplaçable, matref a dis qu'on peut la gérer manuellement, en passant des offsets en arguments...
Après la caméra peut être gérée de différentes façons.

Pour faire un pokemon sur 83, la plus grande difficulté sera de faire tenir le programme et ses sauvegardes en 27 Ko...

Edit: Oups j'étais pas à la dernière page
C'est une solution, mais il n'en reste pas moins qu'il y aura un délai de chargement entre les 2 map, et un scrolling c'est quand même nettement plus classe tant qu'à faire  

Ma foi ouais

Oui bah oui qui a dit le contraire
Mais pour pokemon, comme a dit matrefeytontias, faut faire tenir ca dans 27Ko avec la sauvegarde!!!!
Mais le nombre de maps sera plus petit, on fera genre 30-40 maps plus les arenes etc plus combat et faut reduire a 40-50 pokemons differents. C'est limité.
sauf si quelqu'un s'amuse a faire une memoire externe expres pour la 83 (il me semble que c'est deja fait avec une memory card de PS2 pour la 82)

extension carte ps2 dont tu parles : http://espace-ti.forumactif.com/t440-82-extension-de-1-mo-de-memoire-avec-une-memory-card-de-playstation

matrefeytontias : Je suis enthousiasmé par la version que tu as présenté, ne crois pas qu'on s'en fiche (même si nous sommes peu nombreux et absents).

@rpg c'est moi qui ait parlé des 27 Ko

Et c'est sans compter qu ça réduit l'utilisation de la calto: si on limite à 27 Ko (en comprenant WLib, le programme en lui même et l'espace qu'il devra utiliser pour fonctionner (pour charger d'éventuelles listes/matrices) ), et bien on ne pourra tout simplement pas avoir d'autres programmes dans la calto...

Mais finalement personne n'a testé la manipulation avec la memory card de PS2 si?

Au fait j'ai une question: est ce que les dernières lignes/colonnes sont utilisables avec WLib? Si oui je pense qu'il faudrait envisager une fonction pour éteindre l'indicateur d’exécution (inclue dans WLib), afin d'éviter qu'il efface une partie de la map.

Je trouve enfin le temps de tester vraiment ta petite merveille Désolé pour le retard alors que je te l'avais demandé vite :/

Je n'arrive pas à comprendre comment on affiche un sprite seul sans tilemap.


donne


Tu avais parlé d'une fonction qui afficherait un sprite chargé, et si j'ai bien compris, tu as déjà fait celle pour charger, mais pas celle pour afficher ? okay

• Ensuite, je confirme le fonctionnement sans problème de la Tilemap !!
  Je m'incline bien bas devant cet exploit !

• Sinon, questions à propos des scrolls, que j'aime beaucoup graphiquement parlant
  - est-il possible de proposer une option qui scrolle le buffer automatiquement, sans animation ?
  - même question, mais en ajoutant le fait que le buffer n'est pas automatiquement affiché sur l'écran (on attendrait un 11:prgmUSEWLIB pour le voir à l'écran)
  
  
• Je n'ai plus de bugs graphiques comme j'ai pu en avoir avant, cercles carrés, etc. Est-ce de la chance, ou tu as réglé le problème ?
  
  
• La TI gère encore le buffer de façon... bizarre. On sent qu'elle n'a pas été faite pour. Exemple:
  

  Code:

  
:AxesAff
:EffDessin
:AffGraph
:Repeat codeTouche=45
:12:prgmUSEWLIB
:{20}->LWLIB:1:prgmUSEWLIB
:11:prgmUSEWLIB
:End

  
  fonctionne à meveille. A la fin du programme, lorsqu'on quitte avec [Annul], le buffer reste affiché à l'écran.
  Alors que si j'enlève le AffGraph totalement inutile... la modification se fera après le programme ! (c'est à dire que lorsque je quitte, la TI affiche l'écran vide avec les axes.)
  Alors que je n'ai jamais demandé à effacer le buffer.
  

Je continue de tester des trucs. :p

Linkakro : boh, j'étais juste impatient d'avoir des réponses

M@thieu41 : l'intégralité de l'écran est utilisable, puisqu'on travaille avec un buffer géré entiérement par Wlib. J'ai prévu une fonction d'initialisation de Wlib qui s'occupe de différents trucs, notamment remplir de zéros certaines adresses, désactiver l'indicateur d'exécution et enlever le Done.

Persalteas : oui voilà, j'ai pas encore fait la fonction pour afficher un sprite seul. C'est que c'est dur :/
- C'est pas déjà le cas ? J'ai dû oublier d'enlever une ligne.
- ^ idem

Le problème est réglé par le fait qu'on utilise plus du tout les fonctions de dessin de l'OS. Tout se fait sur le buffer, pour un minimum de conflits.

Pour le programme, c'est normal. Quand tu fais EffDessin, y'a un flag qui se met à 1 qui dit "il faut afficher le graph à l'écran". AffGraph remet ce flag à 0 tout en affichant, ben rien alors que si tu mets pas AffGraph à la fin, ben le flag est toujours à 1, donc le graph recouvre l'écran.

- C'est pas déjà le cas ? J'ai dû oublier d'enlever une ligne.
- ^ idem

Ben moi j'ai une jolie animation de scrolling, pixel par pixel.
J'aime beaucoup hein.

T'es sûr que c'est pas parce que t'utilises 11 dans la boucle ?

Ben oui, mais et pour l'animation ?

Je lui demande de scroller 20 pixels d'un coup, pas un seul 20 fois...

Ben ... {20}->LWLIB:1:prgmUSEWLIB, nan ?

axesaff (ou axesnaff) efface aussi le dessin!!
tout comme quand on enleve une fonction et qu'on en rajoute une a afficher sur l'ecran graphique!!!
bizarre, mais pratique pour l'optimisation!!

Seulement si on affiche les axes et qu'ils n'y étaient pas, ou qu'on les enlèves et qu'ils y étaient (utiliser AxeAff alors que les axes sont déjà affichés ne fera rien).

Je crois que cet effacement est simplement le fonctionnement normal de la TI indépendamment de WLIB. Des choses sont réinitialisées lors du prochain affichage quand on a modifié les formats ou courbes. (et même la RAZ de Y)

exemple page 84 du sdk83plus a écrit:SetTblGraphDraw Sets the graph to dirty, which causes a complete regraph the next time the graph is brought to the display.

Salut tout le monde,

Voilà, j'ai essayé de mettre WILB qui m'a l'air absolument fantastique sur ma TI-82 Stats.fr, sauf que quand j'essaie de transférer le programme WILB.83p via Ti-connect, il m'informe que le type est incompatible, j'ai essayé de décompiler, recompiler mais rien n'y a fait.
Alors je voulais savoir qu'est-ce que je n'ai pas fait. Merci encore, ça a dû te prendre un temps fou !   
Link

Tu complimentes bien matrefeytontias j'espère.
L'expérience permet d'aller plus vite que tu ne sembles croire.

Transmet ton programme en le glissant dans l'utilitaire TIDeviceExplorer de TI-connect si tu utilisais le clic droit. TI-Connect pose des problèmes supplémentaires avec le clic-droit.
Et si tu voulais transmettre A.8xp, assures-toi de l'envoyer séparément pour éviter de possibles refus de TI-Connect. Et je précise bien que le 8xp est compatible avec le 83p, la calculatrice se débrouille.
Et si ce n'est toujours pas correct alors dis le nous et tente de nous donner plus d'informations sur tes manipulations.

Et je précise bien que le 8xp est compatible avec le 83p

Dans le cas de A, oui.

Mais dans le cas de WLIB et USEWLIB, c'est bien les 83p qu'il faut envoyer.
Essaie de les envoyer un par un

Mirki, je n'avais pas pensé à utiliser cette technique.
En revanche je ne savais pas qu'on pouvait faire tourner un .8xp sur une Ti-82 Stats ou une Ti83. C'est bon à savoir =)

Ça marche très bien, faudra que j'apprenne le numéro de toute les fonctions mais je pense pouvoir m'y habituer :p
Ha et, le buffer, c'est l'écran des disp, input, etc... ?

Enfin passer un .8xp sur une Ti83 c'est bien mais il ne faut pas que ce soit un programme asm (parce que sinon ça te fait planter ta calto).

Le buffer c'est un écran "virtuel", il n'existe que en mémoire, les fonctions de WLib passent par ce buffer en mémoire plutôt que d'afficher directement à l'écran (et tu peux l'afficher grâce à une fonction de WLib)

un "buffer" est une zone de la mémoire qui fait pile le nombre d'octets nécessaires pour que tout son contenu tienne sur l'écran.

On peut donc afficher différents "buffers" à l'écran quand on programme en assembleur. En TI-Basic, ça ne s'utilise pas, on utilise que l'écran principal ou l'écran graphique, la calculatrice modifie toute seule les buffers et gère toute seule l'affichage, le programmeur n'a pas besoin de s'en préoccuper.

Avec Wlib, on a accès à des fonctions qui vont dessiner sur le buffer de l'écran graphique directement, sans passer par les méthodes de dessin pré-rentrées dans le système de la calculatrice.
ça permet de tracer des choses à l'écran en plusieurs étapes successives, mais plus vites, et de n'afficher le tout qu'à la fin, quand on a fini notre dessin, et pas étape par étape.

Donc à la fois c'est plus rapide, et c'est plus joli puisque l'image apparait d'un seul coup et non pas au fur et à mesure.

Oké, si j'ai bien compris le buffer est une zone de mémoire qu'on ne peut pas afficher directement, on doit le copier sur l'écran graphique pour afficher son contenu. Il peut y avoir plein de buffers, et je suppose que Pic0 à Pic9 sont des buffers.
C'est vraiment énorme ce que tu as fait matrefeytontias, surtout que j'ai abandonné l'asm à cause du fait que je ne trouvais pas l'header que je devais mettre au début de mon programme. Au moins maintenant ça compensera

Exact

A la base, l'utilisateur quelquonque de la calculatrice n'a pas accès au buffer.

Wlib dat powerful unlocker

En fait, Wlib utilise bien un buffer, mais pour l'afficher j'ai fait ma propre fonction qui le copie à l'écran LCD directement, je passe pas par un buffer du Basic car comme chacun sait, comme TI est une bouse même moi je fais des trucs qui vont plus vite.

Quoi qu'il en soit, update, et quel update ! la fonction de tilemapping est maintenant complètement terminée ! Vous pouvez charger des tilemaps maximum 255*255 (ce qui dépasse la capacité de la RAM de toute façon ) et en afficher seulement une partie à l'écran, ce qui permet de faire ... du scrolling !

Je ne poste pas de programmes pour l'instant (il faut encore que je le prépare, documente, toussa) mais voici un screenshot pour vous faire baver

HOUAHHHH!!!   
Bravo c'est juste génial!   

Fantastique ! Tout ce dont j'ai rêvé !

Testé la bêta oncalc et... pas approuvé !

1) j'ai pas compris pourquoi on devait load le sprite avant de l'afficher puisqu'on reprécise le numéro de la String dans la commande d'affichage.

2) J'essaie d'afficher un sprite et ça ne fonctionne pas.

Ah euh oups, faut pas mettre le numéro de la string, mais du slot

Et comment je sais mon numéro de slot ?

8 load les sprites à partir du slot 0, donc si tu fais {1,1} tu load un sprite venant de Str1. Pour l'afficher tu utilises donc le slot 0.