Ça va alors

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 ?)

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.

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.

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 .

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

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

 
ça en est où ?

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.

Ah, bon

Dommage ça avait l'air prometteur  

Nan mais j'abandonne pas hein comme vous me l'avez rappelé je m'y remets

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!!

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 ?

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.

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.

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?

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.

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
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.

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.

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.

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.

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.

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

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

Bah c'est vrai que chacun fait ce qu'il veut avec
pour notre mario, on fera au plus rapide, si on ne peut faire assez "fluide"

Ben euh rapide = fluide

Actuellement je bosse sur des fonctions graphiques.

Chouette

Tu nous tiens en haleine

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.

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)

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 ?