Re: WLib : Topic de dev

par **matrefeytontias** Dim 13 Oct 2013 - 21:41

Ça va alors

par **persalteas** Mar 15 Oct 2013 - 18:32

Bon, alors j'ai un peu joué avec invertScreen, j'ai plusieurs remarques...

Par exemple, je veux:
- inverser l'écran
- Afficher l'écran
- Re-inverser l'écran (retour à zéro)
- Afficher l'écran

eh bien, j'aurai un écran inversé alors que ça devrait pas.

Ensuite, il y a quelques bugs, qui peuvent faire des choses jolies...

Par exemple:

Code:: :EffDessin :For(A,1,2 :0:Envoi(9prgmWLIB :Cercle(2,2,2 :AffGraph :End

Va me dessiner un cercle sur écran blanc, ce qui prouve que le premier appel du programme ne marche pas, puis, sur un écran toujours blanc, va me dessiner un cercle à l'aide de carrés. Comme si le cercle avait une épaisseur de trait, un peu. Bizarrement, le fond ne devient noir qu'après la fin du traçage du cercle (question d'UpdateLCD ?)

par **matrefeytontias** Mar 15 Oct 2013 - 19:07

C'est possible en effet, mais le truc c'est que la géométrie en TI-Basic se fait tout sur l'écran, et les commandes de WLib agisse sur un buffer. Mon idée était de faire en sorte de ne plus utiliser les fonctions graphiques Basic du tout pour préférer celles de WLib, qui gèrera un buffer pour un gros gain de performances.

par **ashtrail** Mar 29 Oct 2013 - 14:42

Eh! J'ai une nouvelle idée pour Wlib. Perso ça ne me servira pas vu que je suis sur 83+ mais ça pourrait être pratique : c'est le transtypage soit transformer une liste en chaine, ou une chaine en variable, etc... Mais je sait pas si c'est possible. C'est juste une idée.

par **m@thieu41** Mar 29 Oct 2013 - 14:49

Une chaine en variable c'est déjà faisable en ti basic grâce à la fonction expr().
Par contre une autre variable en chaine ça peut être intéressant Smile

.

par **matrefeytontias** Mer 30 Oct 2013 - 10:50

Ça va pas être possible nan ... beaucoup trop compliqué. Faut convertir un float en tokens, nan très peu pour moi.

par **ashtrail** Mer 30 Oct 2013 - 13:02

Bon bin tant pis... (de toute façon ça change rien pour moi Razz

)

par **persalteas** Dim 1 Déc 2013 - 18:38

ça en est où ?

par **matrefeytontias** Dim 1 Déc 2013 - 19:48

Ah euh oui. Ben comment dire, j'ai un peu eu la flemme, et comme j'ai pas de vraie TI-82 stats pour tester, c'est pas trop motivant.

par **persalteas** Dim 1 Déc 2013 - 21:01

Ah, bon

par **m@thieu41** Dim 1 Déc 2013 - 21:09

Dommage ça avait l'air prometteur Sad

par **matrefeytontias** Dim 1 Déc 2013 - 21:31

Nan mais j'abandonne pas hein

comme vous me l'avez rappelé je m'y remets

par **rpgcreator** Sam 14 Déc 2013 - 9:44

re

qu'y a t-il de nouveau dans la w-lib??
et quand est ce qu'on aura une bétatest? je voudrais bien essayer avec, pour voir ce que ca change!! ca m'a l'air utile j'ai vraiment besoin de perfos pour accélérer les programmes, comme ca je fais un pokémon!!

par **matrefeytontias** Sam 14 Déc 2013 - 10:46

Actuellement je galère sur la fonction de sprites ... Je compte donner une bêta dès que c'est fait.

Actuellement ces fonctions sont disponibles et fonctionnelles :

0:Send(9prgmWLIB) : inverse les pixels du buffer
1 à 4 : scrolle le buffer dans les 4 directions
5 : vérifie si un programme existe
6 : supprime un programme
7 : créé un programme d'une taille donnée

Pensez-vous qu'il serait mieux que les fonctions de dessin interviennent sur l'écran et pas un buffer ?

par **m@thieu41** Sam 14 Déc 2013 - 10:56

Je pense que sur un buffer c'est mieux: on travaille sur un buffer et après on utilises une fonction de WLib pour afficher le buffer à l'écran, ça réduira les clignotements et ce sera plus rapide.
Mais le problème c'est si on a déjà des choses d'affichées à l'écran en TI-Basic, ça risque de les effacer et ce n'est pas bien (je pense notamment au mario qui utilise les statsplot pour le terrain)...
Donc travailler directement sur l'écran est plus judicieux au final.

par **matrefeytontias** Sam 14 Déc 2013 - 17:57

Okay alors j'ai testé des trucs sur l'écran et ... aaaargh.

Le paramétrage de l'écran fait que l'allumage d'un simple pixel est un vrai bon gros bordel des familles, donc non, on reste sur un buffer.

La solution : le tilemapping. Comme je ferai le maximum pour qu'on ait le moins besoin des fonctions graphiques du Basic, ça devrait aller.

par **m@thieu41** Sam 14 Déc 2013 - 18:30

Le paramétrage de l'écran fait que l'allumage d'un simple pixel est un vrai bon gros bordel des familles, donc non, on reste sur un buffer.

Que veux tu dire par la?
Tu as un port dédié à l'écran et au pire il y a les rom call non?

par **matrefeytontias** Sam 14 Déc 2013 - 18:34

Ben oui y'a un port dédié à l'écran (tu veux y écrire comment sinon ...) mais l'écran a un driver, et il est configuré de telle sorte qu'une lecture ou écriture déplace le pointeur interne, et ça c'est super chiant.

Et les romcalls, c'est ce qui est appelé quand tu fais du Basic. Autant faire du Basic.

par **m@thieu41** Sam 14 Déc 2013 - 19:09

J'ai déjà fait mes propres routines pour travailler avec le port de l'écran (ce n'étais pas vraiment une question en fait

), et ce n'est pas si terrible que ça, il faut juste repositionner le "curseur" de l'écran entre la lecture et l'écriture, et faire une lecture "blanche" après un changement de coordonnées avant la lecture réelle, c'est un peu chiant mais pas insurmontable Wink

Et les rom call avec un prgm asm c'est quand même plus rapide que les rom call avec l'interpréteur de ti basic.

par **matrefeytontias** Sam 14 Déc 2013 - 19:44

Ben oui mais faut l'appeler depuis un programme Basic le programme ASM. Donc l'appel à la ROMcall s'additionne à l'appel du programme = encore plus lent que le Basic.

par **Linkakro** Sam 14 Déc 2013 - 20:02

Sur ti83plus je comprendrais que tu considères la perte de temps liée à la routine 28h (b_call=rst28h), mais sur ti83 tu n'as pas ce problème car l'instruction call suffit, et quelques push/pop si nécessaire ne seront jamais aussi lents que b_call.

par **matrefeytontias** Dim 15 Déc 2013 - 0:13

Certes, sauf que le Basic n'utilise pas rst 28h non plus du coup.

De toute façon si on veut vraiment gagner du temps, on est obligé d'utiliser un buffer, ce qui sera le cas.

par **m@thieu41** Dim 15 Déc 2013 - 9:46

Comme tu veux. De toute façon si tu fais du tilemapping ça peut ne pas être nécessaire de passer directement par l'écran, même si je pense qu'il vaut mieux garder la possibilité de mélanger fonction WLib/ti basic, ne serait ce que pour pouvoir utiliser les statplots.

par **matrefeytontias** Dim 15 Déc 2013 - 12:32

Si tu peux faire du tilemapping, t'as pas besoin de statplots ...

par **m@thieu41** Dim 15 Déc 2013 - 12:48

Ca reste à voir les stat plots peuvent être pratique aussi ...
Ce n'est pas exactement la même chose.

par **rpgcreator** Mer 18 Déc 2013 - 11:55

Bah c'est vrai que chacun fait ce qu'il veut avec Razz

pour notre mario, on fera au plus rapide, si on ne peut faire assez "fluide"

par **matrefeytontias** Mer 18 Déc 2013 - 12:15

Ben euh rapide = fluide

Actuellement je bosse sur des fonctions graphiques.

par **persalteas** Mer 18 Déc 2013 - 22:14

Chouette

Tu nous tiens en haleine

par **matrefeytontias** Jeu 19 Déc 2013 - 0:05

Ptite question, est-ce que la fonction d'affichage du buffer devrait aussi effacer ce dernier ? C'est beaucoup plus rapide que afficher puis effacer.

par **Linkakro** Jeu 19 Déc 2013 - 0:59

Pour l'écran complet ?
Si ton but est d'effacer ce qui n'est pas inclus dans l'image, il vaut mieux effacer avant d'écrire.

Je pense que permettre de choisir entre on/off/toggle serait profitable. Sinon on ne peut jamais gérer de transparence, ni complémenter ou encore effacer suivant un sprite, à la manière d'un masque.
(et d'un point de vue opération je pense bien que tu en es cappable, malgré les opérations supplémentaires de or/and/xor)

par **matrefeytontias** Jeu 19 Déc 2013 - 1:07

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 ?

par Contenu sponsorisé


TI-Planet	Espace-TI : Forum