Un tout nouveau shell pour TI: sh`L - Page 7

TheCodR : GX_DrawStr est indépendante du reste de GX !
Pour les timers, il y a une fonction qui fonctionne pareil que GX_CreateTimer sous AMS 2.0x. Par contre, avec, tu ne pourras pas appeler un ROM_CALL dans un timer si tu compiles avec l'option OPTIMIZE_ROM_CALL.

la rapidité de l'affichage

lol

Par rapport aux fonctions de TIGCClib qu'il utilisait jusque là

ouais allez on va dire ça

Thibaut a écrit :
TheCodR : GX_DrawStr est indépendante du reste de GX !
Pour les timers, il y a une fonction qui fonctionne pareil que GX_CreateTimer sous AMS 2.0x.

Sous AMS 2.0x seulement? Tu veux parler de quelle fonction?
Il y a en tout cas OSVRegisterTimer de TIGCCLIB. (Le nom en OS est parce que c'était un ROM_CALL dans les vieilles versions de AMS.)

Par contre, avec, tu ne pourras pas appeler un ROM_CALL dans un timer si tu compiles avec l'option OPTIMIZE_ROM_CALL.

1. Avec OSVRegisterTimer de TIGCCLIB, il n'y a pas ce problème.
2. Pour les callbacks appelés par AMS, la solution est simple:
CALLBACK void callback(void)
{
void *olda5=__jmp_tbl;
__jmp_tbl=*(void***)0xC8;
//...
__jmp_tbl=olda5;
}

GraphX est rapide... Même par rapport à Extgraph elle est assez rapide, et elle gere le clipping. Même si j'ai tendance à plaisanter un peu dessus ça n'en reste pas moins une des meilleurs lib quand on fait le rapport confort d'utilisation / vitesse

mouais
ya pas enormement de fcts qd tu regardes par raport a genlib ou xlib

Et pour le 'confort d'utilisation', c'est une question de point de vue...

TheCodR
a écrit : je connais pas trop XLib

On dirait en effet... cf ce qui suit...

TheCodR a écrit :
mais il me semble que y'a pas les fonctions de timers, scrolling, sprite multi taille etc..

Timer -> Si
Scrolling -> XLib n'est pas une lib qui prémache tout le travail... Le scrolling c'est à l'utilisateur de le faire, il sera mieux.
Sprites multi taille -> Si

le scrolling, généralement ça sert a rien (sauf exceptions)
vaut mieux tout réafficher a chaque cycle

Vertyos : que de bêtises dans ton post

Timers "à la Delphi" sous Xlib : y'a pas.
Sprites 8x8 et 32x32 sous Xlib : y'a pas.

J'ai fait un nouveau bench FS_DrawString C/ FS_DrawString ASM / GX_DrawStr / DrawStr (F_4x6 / police de GX_DrawStr). Le bench consiste à afficher 4000 fois "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", et à mesurer le temps en ticks d'AUTO_INT_5 (en principe ce sont des calculettes avec les paramètres de reset).
VTI 89 AMS 2.05: 246/213/304/2750 (identique sous AMS 2.03).
VTI 89 AMS 1.00: 165/142/204/872.
Real calculator 89 AMS 2.03: 165/155/156/1404.

Comme vous pouvez le remarquer, l'écart entre FS_DrawString et GX_DrawStr est insignifiant sur calculette réelle. L'écart de performances avec AMS n'est pas 12x sur une calculette réelle, aussi.
Donc je présente toutes mes excuses à Thibaut si j'ai donné une mauvaise image de GX_DrawStr et une trop bonne image de FS_DrawString (routine générique qui gère les trois polices, mais l'écart de vitesse entre FS_DrawString et FS_DrawLittleString qui ne gère que la F_4x6 sera très faible, probablement moins de 2, avec mon bench sur VTI. Il faut savoir reconnaître ses erreurs...
VTI est un outil de debug formidable, mais les benchs avec VTI sont hasardeux (je le savais, mais pas à ce point-là)...

Thibaut: que des bétises dans ton post !

Timers comme delphi: c pas utile, y'a des timers et c largement suffisant !
Sprite 8x8: Ben y'a le 16x8 (nan, ca ne prend pas plus de place ..)
Sprite 32x32: y'a même tous les sprites 16*largeur x 16*hauteur

Et bien si, ça prend 2x plus de place, ou alors tu m'explique le miracle qui fait que non...

Thibaut a écrit :
Timers "à la Delphi" sous Xlib : y'a pas. Sprites 8x8 et 32x32 sous Xlib : y'a pas.

Que de bêtises toi aussi... Orion n'a pas précisé "Timers à la Delphi" (d'ailleurs je ne vois pas trop l'interet). Perso j'utilise XTimer5, et je vois mal comment on peut faire qqchose de plus simple.
Quand aux sprites 8x8, il y a les 16*8 qui affichent en 8*8, et les 32*32, il y a les XPic.

XDanger : c'est rassurant pour mon GX

Vertyos : c'est tout bêtement plus simple pour exécuter du code à intervalles réguliers. Ca évite des codes du genre :

timerautodécrémenté= 10;

boucle
{
  blabla;
  if (timerautodécrémenté==0)
  {
    blabla;
    timerautodécrémenté= 10;
  }
  blabla;
}
finboucle

Un timer à la Delphi ça s'utilise comme ça :

GX_Timer timerhandle= GX_CreateTimer(MonTimer, fréquence);

boucle
{
  blabla;
}
finboucle

GX_DestroyTimer(timerhandle);

...
void MonTimer(void)
{
  blabla;
}

Je trouve ça plus clair. Et ça a des avantages (plusieurs timers peuvent s'éxécuter en même temps, par exemple)

Mais il y a déjà des timers comme ça dans TIGCCLIB:
http://tigcc.ticalc.org/doc/system.html#OSVRegisterTimer
Donc aucun intérêt d'en mettre dans les librairies graphiques.

Avec Kevin, il faudrait UN compilateur, UN shell, UN jeu de chaque genre, UN kernel, UN éditeur de handles, etc, sur nos TIs
T'aimerais pas la domination, un peu ?

Et puis mon système a des avantages par rapport à celui de l'AMS, je te les ai déjà énumérés une fois. J'ai la flemme de chercher le topic, c'était dans Questions.

Franchement si c'est uniquement pour ça, je trouve l'interet un peu limité. D'autant plus que, si il m'est arrivé rarement d'avoir des boucles comme ça, JAMAIS je n'ai eu à utiliser 2 timers en même temps

XDanger : c'est rassurant pour mon GX

En effet. Ta routine est bien écrite. Elle tire parti du fait que ta police est de taille fixe, ce qui n'est pas le cas de celle d'AMS.
J'ai désassemblé ta routine pour la première fois hier: je me suis rendu compte qu'elle écrivait en mode A_REPLACE, pas en mode A_NORMAL. C'est peut-être écrit dans la doc, mais je ne l'avais pas vu... Donc, en plus, je faisais un bench GX_DrawStr (A_REPLACE) / FS_DrawString (A_NORMAL)... Utilisant le même algorithme, la fonction FS_ReplaceString est plus lente car il faut utiliser un masque. Donc GX_DrawStr est (était ?, cf plus bas) plus rapide que FS_ReplaceString.

Mais j'ai changé un peu l'algorithme (mettant en application un truc que j'avais vu il y a un certain temps). J'ai gagné environ 20% par rapport à l'algorithme précédent si je ne ré-enroule pas les boucles, 10% en ré-enroulant la boucle. Cependant, même en laissant les boucles déroulées et en comptant la taille des routines de startup et de cleanup, la taille reste inférieure à celle de GX_DrawStr...
Quand j'aurai modifié toutes les routines génériques gérant les 3 polices (FS_DrawString, FS_InvertString, FS_ReplaceString, FS_ReverseString, FS_DrawString et FS_InvertString étant très proches), je ferai les routines gérant une seule police. Je m'occuperai en premier de FS_DrawLittleString et FS_ReplaceLittleString. C'est seulement à ce moment-là qu'on pourra faire un vrai bench GX_DrawStr (F_4x6_like) / FS_ReplaceLittleString (F_4x6).
Je sais que tout cela est de ma faute...

Moi aussi je peux accélérer GX_DrawStr : en changeant le format des sprites (un octet par ligne de caractère plutôt que deux) et en changeant ma façon d'écrire lorsque le caractère chevauche deux octets.

Vertyos : on est content pour toi

Pfff... C'est tout ce que tu trouve à répondre ?

Bah oui, tant mieux si tu n'as jamais eu besoin de plus d'un timer et que tu aimes te débrouiller avec les variables autodécrémentées !
Ce n'est pas le cas de tout le monde. Nerick, par exemple, utilise GraphX dans un de ses projets, juste pour les timers ! Il n'utilise rien d'autre dans la bibliothèque

<Vertyos> "Nerick, par exemple, utilise GraphX dans un de ses projets, juste pour les timers ! Il n'utilise rien d'autre dans la bibliothèque"
<Vertyos> c vrai ça ???
<Nerick> nan
<Nerick> dans un de mees proj
<Nerick> j'utilise gx que pour eviter de detourner les ints a la main
<Nerick> #fleme#
<Vertyos> arf ok <Nerick> rien a voir avec les timers

Et très honnêtement je pense que les cas ou on a vraiment besoin de 2 timers sont rares. En tout cas ce n'est pas un très bon argument pour une librairie graphique

Nerick : hé ho dans ton mode 7 tu utilises les timers de GX pour compter les FPS !!! j'ai eu tes sources sous les yeux


> ce n'est pas un très bon argument pour une librairie graphique

Avec GraphX on peut déclarer 4 timers

Avec GraphX la fréquence d'appel peut atteindre 256 Hz

Avec GraphX l'exécution d'un timer peut être interrompue si un autre timer doit être exécuté (par exemple si on a un timer à 10 Hz qui met du temps à s'exécuter et un autre timer à 200 Hz, l'exécution du timer à 10 Hz est interrompue puis poursuivie si le moment est venu que le timer à 200 Hz s'exécute)

Avec GraphX, la calculatrice ne plante pas si le timer fait appel à des ROM_CALLs en mode OPTIMIZE_ROM_CALL et que a5 est modifié par la fonction interrompue

Avec GraphX, si le timer lit le clavier, le contenu du port clavier n'est pas changé lorsque la main est rendue au code interrompu

Voilà. Ca a donc quelques avantages ! On dirait que t'es comme Kevin, toi. Tu aimerais UN shell, UNE lib graphique, UN mode de programmation, UN utilitaire, UN compilateur, etc... le monopole quoi

ah ue merde désolé, j'avais oublié le compte des fps
mais bon, c un truc que j'ai maintenant viré dans la source actuelle du mode7, donc je n'utilise plus de timers au final :]