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

La vérité est rétablie.

Avec GraphX on peut déclarer 4 timers
> Bah montre moi des programmes qui en utilisent plus de 2 déjà...

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

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)
> Ça rejoint l'interet très relatif pour moi des multi-timers...

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

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

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
> Arg... Ne me compare à Kevin
Simplement comme je l'ai déjà dit, GraphX est censée être une librairie graphique, et les timers aussi bien programmés qu'ils soient, sont rarement utiles.

Dire qu'il sont "rarement utiles" implique qu'ils sont quelquefois utiles !
Bon on va arrêter là

Enfin bon, il ne faut pas abuser... c'est pas la mort de détourner une int...

Thibaut a écrit :
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 ?

Non, mais j'ai marre de la duplication d'efforts totalement inutile.

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.

Je t'ai déjà dit plusieurs fois que ça fait longtemps que OSVRegisterTimer n'est plus dans AMS! TI l'a retiré dans AMS 2.04. L'implémentation actuelle est dans TIGCCLIB.

>>Avec GraphX on peut déclarer 4 timers
>Bah montre moi des programmes qui en utilisent plus de 2 déjà...
Je veux voir un programme qui utilise 4 timers, en effet... Surtout que si tu détournes certains des timers d'AMS de leur usage initial (c'est très sale, mais bon...), tu peux avoir au moins 3 timers disponibles, sur toutes les versions de système... Sur AMS

>>Avec GraphX la fréquence d'appel peut atteindre 256 Hz
> Ok
La fréquence d'auto-int-5 peut probablement être montée à (environ) 256 Hz aussi en modifiant les ports appropriés...
Tes timers sont-ils basés sur l'auto-int-1 ?

>>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)
> Ça rejoint l'interet très relatif pour moi des multi-timers...
En effet, c'est intéressant, pour ceux qui en ont besoin (et ils ne sont probablement pas nombreux).

>> 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 <http://yn1.free.fr/smilies/tongue.gif>
Les extensions du GNU C rendent la restauration d'a5 parfaitement triviale... GTC ne le gèrera peut-être pas.
(Je ne veux pas lancer un débat TIGCC/GTC ici).

>>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
A mon avis, peu de gens rencontrent ce problème, même si c'est très bien, il faut te féliciter, d'avoir pensé à la restauration du port clavier...

>Je t'ai déjà dit plusieurs fois que ça fait longtemps que OSVRegisterTimer n'est plus dans AMS! TI l'a retiré dans AMS 2.04. L'implémentation actuelle est dans TIGCCLIB.
Et l'implémentation de TIGCCLIB corrige des bugs qui étaient dans les ROM_CALLs d'AMS.

Kevin > Non, mais j'ai marre de la duplication d'efforts totalement inutile.

On n'en a rien à faire ! On programme qu'on veut. Je n'ai aucun compte à rendre, je suis bénévole et je code pour le plaisir. C'est compris, Môssieur ?


XDanger > c'est intéressant, pour ceux qui en ont besoin (et ils ne sont probablement pas nombreux).

Je suis très heureux de rendre service à ces gens-là.

> peux avoir au moins 3 timers disponibles

Mais un timer ne peut pas être interrompu par un autre.


> Les extensions du GNU C rendent la restauration d'a5 parfaitement triviale...

Mais votre fonction de base ne le fait pas ?
Bon et puis on va arrêter ce débat à la con.

Aux dernières nouvelles tu portais SHL sous GX

Ca y est, tu as laissé tombé ?

De toute façon, BASIC PoWa !!!!
Vertel est la meilleur lib, de trés loin, y a pas de question à se poser

Faux. Flib pawaaa !

XDanger a écrit :
>> 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 <http://yn1.free.fr/smilies/tongue.gif> Les extensions du GNU C rendent la restauration d'a5 parfaitement triviale...

En effet, le suivant suffit:

CALLBACK void callback(void) {
 void *olda5=__jmp_tbl;
 __jmp_tbl=*(void***)0xc8;
 /*...*/
 __jmp_tbl=olda5;
}

Moumou
a écrit : Faux. Flib pawaaa !

Bon, Moumou, tu c visiblement pas de koi tu parle
Si Orion_ passe à GraphX, c pasque le scrolling de Shellian avec Vertel était aussi rapide que celui de shL en C pur. Tu va me dire que tu peut faire ça avec FLib

Elles n'ont pas les mêmes fonctions ces libs, si ?

FLib et Vertel ????
Globalement si, mais Vertel est trés largement plus rapide que FLib (et plus de 2* plus petite aussi).
Au niveau de la vitesse, c comme si tu comparait TIGCCLIB avec XLib ou Genlib

en gros il y a à peu pres toutes les fonctions qui sont communes sont 2-3 truc du genre kompression (qui prend bcp de place) mkpic (qui peut être recreer avec vertel, à la main)

Et y en a qui sont pas dans FLib (comme v_load, v_test, ...)

Au niveau de la vitesse, c comme si tu comparait TIGCCLIB avec XLib ou Genlib

AMS n'est pas fait du tout pour faire des jeux, les librairies graphiques spécialisées le sont (elles ne font que ça). On ne doit pas attendre des miracles des fonctions d'AMS, intégrées dans TIGCCLIB...
Je vous rappelle encore une fois que la TIGCC Team et TICT sont généralement ouvertes aux contributions (améliorations des routines existantes, création de nouvelles routines, documentation correcte des fonctions inconnues d'AMS sans recopie mot à mot de la doc de TIFS...).

T'as pas comprit, je parle du rapport de vitesse entre FLib et Vertel. La comparaison des libs graphiques et de TIGCCLIB, vu que c l'écart le plus représentatif que je connais, ne fait qu'illustrer le différence (et puis c libs ne sont pas forcément faite pour faire des jeux, vu que GraphX est utiliser pour shL).

y en a qu'on vraiment du mal...

XDanger
a écrit : AMS n'est pas fait du tout pour faire des jeux, les librairies graphiques spécialisées le sont (elles ne font que ça). On ne doit pas attendre des miracles des fonctions d'AMS, intégrées dans TIGCCLIB...

Attention, les routines de sprites de TIGCCLIB ne sont pas des ROM_CALLs.

A ce propos j'ai une question :

Pourquoi ne mettez-vous pas dans TIGCClib.h les fonctions d'Extgraph, qui sont nettement plus rapides ?

Parce que les routines de TIGCCLIB prennent moins de place, vu que la même routine permet d'afficher en AND, OR ou XOR.

Pourquoi ne pas mettre les 2 alors ?

Dans ce cas pkoi ne pas faire une librairis qui regroupe toutes les libs statiques qui xiste

Vertyos
a écrit : Pourquoi ne pas mettre les 2 alors ?

J'étais serieux en posant la question... Extgraph ressemble tellement à un "addon" pour TIGCC que je trouverais normal de la fusionner avec.

C sur que les fonctions d'affichage de sprite de TIGCC ne prenne pas de place mais elles sont dangereuses à utiliser.

Je m'explique: étant donné quelles ne gère pas le clipping, on risque de planter la calculatrice si on affiche hors de l'écran. de plus, si on met un sprite qui sort a moité en haut de l'écran, il ne s'affiche pas du tout (ce qui est normal vu comment elle ca été programmé). Elle est bien seulement pour des petits jeux ou des programmes qui s'en servent pour faire des sprite a l'écran ou l'on sait a l'avance qu'ils ne sortirons pas.

J'ai reussi, à en refaire une equivalante qui gère le cliping et qui permet en plus d'afficher les sprites masqués en une seule passe (et non deux pour Spritexx de TIGCC) à une vitesse équivalente. Le seul problème, c qu'elle marche parfaitement pour TI89 mais meme si je ne l'ai pas testé sur 92, je sais que c'a n'ira pas. Si on fait sortir un sprite a droite de l'écran, il ressortira a gauche (comme TIGCCLIB)

Hein? Memeleti-basic clippe les sprites sur la droite!

Le rapport?