Kernel vs Nostub? - Page 8

sBibi a écrit :
et tu vois, si t'avais utilise une [pub]belle/bonne[/pub] norme, t'aurais dessuite vu que ton code puait...

Ben non, c'est ta norme stupide qui rend mon beau code illisible. C'est la norme le problème, pas le code.

dailleurs j'av pas fait gaffe avant de le rendre lisible...

De le rendre illisible plutôt.

jackiechan
a écrit : Sinon, ça n'a rien à voir, mais mon prof de physique m'a dit que la persistance rétinienne de l'oeil est de 100 ms, ça signifie que lorsqu'on regarde une image, elle reste pendant 100 ms dans notre vue, donc il faut que le fps soit d'au moins 10 fps pour qu'on ait une impression de fluidité

Voilà. En d'autres mots: Thomas Nussbaumer a raison une fois de plus.

Tu utilises quoi d'autre. genlib? Elle est aussi disponible en pseudo-_nostub, donc pas besoin de USE_KERNEL pour ça.

Genlib, filelib, shrnklib et sfontlib(lib perso)

Tu ne t'imagines pas le nombre de bogues qu'on a corrigés dans la série des bêtas 0.94. Au moins une demi-douzaine par bêta en moyenne. Et il y a eu 22 bêtas.

certes mais personellement je n'ai trouvé aucun bug dérangeant sauf peut être dans les version furtive(changées en moins de 1 semaine) que je n'ai pas eu l'occasion de tester

Ben, moi je le sais très bien, et je garde quand-même mes lanceurs personnalisés, même si j'utilise TICTEX la plupart du temps. Donc les gens qui utilisent les lanceurs personnalisés ne sont pas forcément des ignorants comme tu as l'air de le présupposer.

Certainement que certain le font en connaissance de causemais la grande majorité l'ignore

Certes, mais ça ne veut pas dire qu'on dépasse l'ordre de grandeur des millisecondes même dans un jeu complexe. Les optimisations classiques de la vitesse au détriment de la taille (déroulement de boucles, multiplication des routines pour traîter des cas différents, ...) n'apportent pratiquement jamais de différence que l'utilisateur puisse remarquer. Les optimisations vraiment efficaces sont celles qui simplifient les routines, et donc améliorent à la fois taille et vitesse.

Certes mais tout est bon a prendre quand on est juste

Ben oui, ExtGraph est plus flexible. Mais partout où on peut utiliser genlib, on peut aussi utiliser ExtGraph!

Certes mais elle est aussi baucoup moins efficace et moins adaptée au jeux car plus généraliste

Uther Lightbringer
a écrit : Genlib, filelib, shrnklib et sfontlib(lib perso)

filelib
Je ne toucherai certainement pas à tes programmes.
filelib est boguée, sale, et inutile. Utilise vat.h directement!

Pour shrnklib, utilise ttpack à la place.
Pour ta librairie personnelle, recompile-la en statique.
Et hop, plus besoin de USE_KERNEL.

certes mais personellement je n'ai trouvé aucun bug dérangeant sauf peut être dans les version furtive(changées en moins de 1 semaine) que je n'ai pas eu l'occasion de tester

Ben, si les bogues étaient faciles à trouver, ça ferait longtemps qu'ils seraient corrigés.

Certainement que certain le font en connaissance de causemais la grande majorité l'ignore

Et alors? Ça ne change rien à ce que j'ai dit.

Certes mais tout est bon a prendre quand on est juste

On est très rarement "juste" dans un jeu/programme 2D. Les seuls cas où les 10 FPS étaient vraiment difficiles à atteindre que j'ai vus étaient des jeux 3D.

Certes mais elle est aussi baucoup moins efficace et moins adaptée au jeux car plus généraliste

Mais alors pas du tout. Elle n'est pas moins efficace ni moins adaptée que genlib.

XDanger a écrit :
>>Pitoyable. Même nous, qui n'aimons pas le kernel, te faisons des suggestions (notamment pour l'amélioration de ces RAM_CALLs de fonts qui sont actuellement implémentés n'importe comment: très lent, pas sûr...)
> 1. On s'en fout de la vitesse de detection. On n'est pas a 1 ms pret.
Ta version ne prend pas 1 ms...

Sur ma calc, l'install ne prend pas 1s. Kevin aide moi a lui faire comprendre que c'est bien assez rapide (C'est ton domaine, non ?)

> 2. Ca marche.
Non, pas sous AMS 2.xx si les fonts sont redéfinies...

Non, cf en dessous.

> 3. Ce sont les fonts du boot qui DOIVENT etre exportes.
Pourquoi ?

Cf Specifications.

> 4. J'ai deja propose des trucs mais personne ne m'ecoute.
Nous aussi, nous avons proposé des trucs, mais tu ne nous as pas répondu...

Si cf au dessus. Ou c'est autre chose ?

Tu ne respectes pas les autres, ne t'attends pas à être respecté... Dorénavant, je cesserai de ne pas être agressif envers toi...

A bon ? Premiere nouvelle ! Je ne savais pas que je ne respectais pas les autres.
Merci de me le dire. Et sans rancune

>Kevin: Je prepare mon MEGA post.

Kevin Kofler a écrit :
Voilà. En d'autres mots: Thomas Nussbaumer a raison une fois de plus.

Il n'y a pas qu'une histoire de persistance rétinienne. Imagine que tu veuille faire passer un sprite 8*8 (par exemple) d'un bord de l'écran à l'aute en une durée donnée. Si tu es à 10fps, et si on fixe la durée à 1s, tu ne verra presque pas l'objet, tu auras juste l'impression d'un vague truc qui se déplace en saccade. A 20fps, le problème est moindre. Les déplacement d'objets sont donc directement influencés par le fps.Et bien sur plus le fps est grand, moins la vitesse instantannée (d'une frame sur l'autre) sera grande et plus l'objet paraîtra net.

La spécification dit: "These are pointers to the font tables of each font of the calculator." Nulle part n'est-il question de boot code. Du moins c'est ce que je lis dans PreOs 0.62 [EDIT: Cf. aussi #223] et dans la dernière version de DoorsOS II.

Et puis, s'il y a un problème dans la spécification, on corrige la spécification.

Ximoon
a écrit : Il n'y a pas qu'une histoire de persistance rétinienne. Imagine que tu veuille faire passer un sprite 8*8 (par exemple) d'un bord de l'écran à l'aute en une durée donnée. Si tu es à 10fps, et si on fixe la durée à 1s, tu ne verra presque pas l'objet, tu auras juste l'impression d'un vague truc qui se déplace en saccade. A 20fps, le problème est moindre. Les déplacement d'objets sont donc directement influencés par le fps.Et bien sur plus le fps est grand, moins la vitesse instantannée (d'une frame sur l'autre) sera grande et plus l'objet paraîtra net.

Tu affiches les sprites qui se déplacent rapidement 2 fois (effet de trainée). Ça reste toujours plus rapide que d'afficher un frame entier de plus.

Ca n'est pas une solution propre et efficace.

Ben si. Au-delà du seuil de persistance rétinienne, l'œil humain ne fait plus la différence entre 2 frames séparés et un frame combiné.

Pour avoir essayé je te dis qu'à 1/10è de seconde ça rend très mal.

Sauf que si on affiche bien les deux frames, l'oeil verra un des sprites plus foncé que l'autre. La trainé est effectivement visible sur les jeux affichant plus de 10 fps, mais il apparait toujours clairement qu'un des sprites est plus récent que les autres.

Sinon, ça serait quand même révolutionnaire pour les programmeurs TI (à combien de fps tourne sma ?). M'étonnerait qu'on soit passé à côté pendant toutes ces années (mais pourquoi j'alimente ce débat moi ?)

> A bon ? Premiere nouvelle ! Je ne savais pas que je ne respectais pas les autres.
>Merci de me le dire. Et sans rancune
Ne pas vouloir faire les suggestions pour le _nostub, pour laisser le _nostub dans la merde où tu prétends qu'il est, c'est quoi ? Dire 'Kevin speaks and I don't want to listen anymore', c'est quoi ? Ne pas écouter les suggestions pour ton kernel, c'est quoi ?

cf au post 205>
oups, desole, effectivement c'est faux, le melange entre le fait que qd on quitte un prog sur pc il n'y a pas besoin de freer la mem allouee et le fait que je venais de me lever n'a pas fait bon menage

Tiens, PpHd, je n'avais pas vu que tu as changé la spécification entre PreOs 0.62 et 0.64. Maintenant, il y a écrit:

These are pointers to the Boot font tables of each font of the calculator (on emulator, it may be the OS font tables).

Il faudra m'expliquer pourquoi tu as changé la spécification de cette manière stupide malgré qu'on t'ait conseillé de faire le contraire. Comme j'ai déjà dit plusieurs fois:
Rien ne t'empêche de rajouter un autre RAM_CALL pour tios::font_medium (maintenant que le problème de tios::font_small et tios::font_large définis en ses termes est résolu), et de renommer _RAM_CALL_00E en tios::boot_fonts. Comme ça, tu peux utiliser les bonnes fontes pour tios::font_medium, tios::font_small et tios::font_large après recompilation, et les anciens programmes non recompilés/réassemblés marcheront toujours (mais avec les fontes du boot).

>Tu sais que je ne ferai jamais ça sans l'accord de Sebastian, et qu'il veut garder le support pour USE_KERNEL. Donc on le garde.
Faites que Sebastian dure dans la team !

>Et puis de toute façon, ce n'est pas de notre faute si les auteurs disparaissent sans laisser leurs sources.
Non. Je t'ai accuse de ca ? Pardon.

>Je te signale que tu es passé totalement à côté de mon argument, qui est que les librairies dynamiques peuvent elles aussi avoir des problèmes de mise à jour si certaines fonctions sont codées sous forme de macros. Et genlib est dans ce cas-là.
Ok. Je reprends. Les macros de genlib ne peuvent pas poser ce genre de probleme de mise a jour puisque j'ai choisir des fonctions qui peuvent ne pas necessiter de mise a jour. Pour Tigcclib, c'est impossible.

>Et je trouve quand-même que le minimum d'effort qu'on puisse attendre d'un programmeur, même s'il ne s'intéresse plus à la programmation sur calculatrices, est de faire Project/Build. S'il n'est pas prêt à faire ça, ni à laisser ses sources pour qu'un autre puisse le faire, c'est de l'égoïsme de la part de l'auteur. Ça n'a rien à voir avec le format de l'exécutable.
Peut etre plus simplement qu'il ne s'y interresse plus et qu'il oublie. Cela me parait plus posible.

>J'ai l'impression que tu m'as encore une fois mal compris. Je répète donc avec d'autres mots, que j'espère être plus clairs:
Oui j'ai l'impression. Ou alors c'est toi m'enfin.

>Je compte un seul lanceur quand je calcule la taille parce que je compte ce qui est nécessaire pour lancer le programme, pas ce que l'utilisateur choisit d'utiliser.
Mais oui. C'est bien ce que j'avais compris.

>Sinon, je code un kernel de 64 KO et je dis: "Moi, j'utilise mon kernel de 64 KO, donc je compte 64 KO pour chaque programme pour kernel. "
Tu auras du mal a faire un kernel de 64Ko qui fonctionne sur AMS 2.0x

>Tu as déjà vu un Mario avec 20 ennemis qui sautent en même temps, toi?
Disons 10, et alors je dirais oui. Plus les boules qu'ils envoient et ca fait 20.

>Donc la vitesse n'est pas aussi importante que vous avez l'air de croire.
Tout depend du type de jeu ! Si le jeu est lent, les niveaux sont concus pour !
Sinon t'immagines jouer a un jeu avec des niveaux concus dans l'esprit rapide avec un jeu lent ! Soit c'est chiant, soit c'est injouable !

>Bon, EM_blockErase et fonctions liées et quoi d'autre? Rien qui était en utilisation réelle. Et puis les kernels n'ont rien fait pour résoudre ce problème. Nous oui: on a mis OSVRegisterTimer et OSVFreeTimer dans tigcc.a.
Ok, tu veux que je mettes ces fonctions dans le kernel, c'est cela ? Alors que personne ne va s'en servir ?

>Mais nous, on a résolu le problème très vite. Les kernels n'ont rien fait pour le résoudre.
Le seul programme qui l'utilisait etait en _nostub, je me trompe ?

>Je sais déjà que tu es anti-recompilation.
Et toi anti-dynamique.

>C'est ironique?
Je ne sais plus.

>Je te signale que je ne parle pas du temps total mis pour calculer un frame, mais de la différence entre le temps mis par une routine optimisée en vitesse et le temps mis par une routine optimisée en taille. Je ne pense pas que ça dépasse l'ordre de grandeur des 100 µs (1200 cycles). Peut-être que je me trompe, mais il faudra des chiffres pour montrer que j'ai tord.
Compare (Attention je parle du point de vue algorithmique, je connais ScreenClear !) :
lea LCD_MEM,a0
move.w #960-1,d0
\loop:
clr.l (a0)+
dbf d0,\loop
A :
Une boucle completement deroulee avec des movem.
Et apres dis moi si ca ne fait pas 1200 cycles de difference.

>Mais ça n'a rien à voir avec un CounterStrike!
Un sonic lent. Tu penses que ca a un interet ?

>L'œil n'arrive quand-même pas à distinguer par exemple entre 100 et 200 FPS. (J'ai utilisé exprès de très grosses valeurs pour que la valeur exacte à partir de laquelle on ne voit plus la différence ne rentre pas dans l'équation.)
Forcement. Le frame rate de l'oeil est environ de 20 images par seconde vers le cerveau. Mais ensuite y'a les retine capable de recuperer des evenements plus rapides (car la lumiere a le temps d'impregner la retine).
C'est pas clair. Desole.

>Mais les fonctions offertes par genlib sont sur la calculatrice même si elles ne sont pas utilisées!
Et bien il n'y a qu'a les utiliser

>Tu connais le passage par registres? Il me semblait que oui, mais j'ai des doûtes là.
Oui. Mais ca consomme quand meme un registe, ce qui peut etre genant (Les routines necessitant 10 registres sont un peu penibles parfois).

>Tu peux même utiliser une "global register variable". Comme ça, il n'y a rien à copier, sauvegarder ou restaurer (sauf au tout début et tout à la fin).
Mais on perd un registre !
Et on a souvent besoin ailleurs, pour un autre global plus interressant.

>Bon, d'accord, je vais tester ça
1ms entre un appel a tigcclib et a extgraph. Oupss je suis mal barre la.
XDanger, sort nous ta version, vite ! Ca sera jouable je pense alors.

>KerNO 2.xx ne fonctionne que sur AMS 2.0x. Ce n'est pas un bogue, c'est fait exprès.
Essentiellement a cause de cela, je pense.

>Ben, tu peux lui conseiller de ne pas afficher de message dans ce cas, par exemple.
Et de faire quoi a la place ?

>Ce que j'appelle un format flexible, c'est le format qui fixe le moins de trucs possibles, et laisse donc le maximum de choix au programmeur et à son outil de développement. C'est à l'outil de développement de fournir les fonctionnalités au programmeur, pas au format de l'exécutable.
C'est ta definition de flexible. Ce n'est pas la mienne.

>Tant pis.
>Je vois nettement plus de personnes qui utilisent DoorsOS que AMS 1.0x, et pourtant tu t'en fiches de la compatibilité avec DoorsOS.
Y'a encore des personnes qui utilisent un kernel dans ton entourage immediat
Je ne vois pas en quoi je me fiches de la compatibiltie avec DoorsOs puisque Preos permets d'executer les programmes DoorsOs (Je bosse encore sur les v2).

>Un leak de mémoire est un bogue, donc tu as perdu.
Je te tiens, tu me tiens par la barbichette !

>En quoi la liberté de choix est-elle un problème??? Ta manière de "centraliser" les problèmes est celle utilisée par les régimes autoritaires.
Absolument pas ! Cela n'a rien a voir avec les regimes autoritaires !
Il ne faudrait pas exagerer ! Centraliser une chose peut etre une maniere tres democratique de faire les choses.

>Mais ce n'est qu'en ayant cet idéal-là (même si ce n'est évidemment qu'un idéal) qu'on crée des programmes faciles à utiliser.
Un programme kernel reste facile a executer.
1. Tu installes le kernel.
2. Tu executes le programme.
Pas de quoi crier a la complexite extreme (Pas de variables systemes a installer ou autres).

>Comment ça? Le matériel est totalement inadapté.
Explicite step.

>Bon, OK. Mais tout ce système de librairies dynamiques est copié directement sur Fargo.
Parce que c'est un bon systeme (Utiliser les ordinaux est bien mieux qu'utiliser les noms exportes par exemple).

>Les programmes appellent-ils les fonctions de fichiers de DOS directement? Je ne pense pas.
fopen sous win 3.1 ou sous dos fait appel aux memes int dos.

>Non, et c'est pour ça que je n'arrête pas de dire que c'est inutile.
Pourquoi ?

>Tu essayes de faire faire au kernel des choses pour lesquelles il n'était tout simplement pas prévu.
Et c'est grave docteur de faire evoluer quelque chose ?

>... ce qui revient au même en pratique.
mais le format est different.

>Ce sont des améliorations d'ordre vraiment mineur.
En es-tu si sur ?

>Etc. quoi? Je suppose que ce sont des changements (même pas forcément des améliorations) d'ordre encore moins important.
Compatibilite 89 / 92+. Format de reloc non compresse par exemple aussi.

>On corrige les bogues avant et on rajoute les nouveaux features après. La TICT a toujours fonctionné comme ça, et ça se voit: rares sont les programmes aussi stables que les programmes TICT.
C'est cela en theorie. En pratique on ne fait pas toujours cela pour diverses raisons.

>Vive les disques durs de plusieurs GO!
Ben j'ai que 2 Giga sur mon Pc et ca me suffit

>Les programmes pour PC ont tous tendance à être beaucoup trop gros à mon avis.
Et en plus tu voudrais qu'ils incluent tous les libs statiques
Si seulement ils exportaient le start-up C++ en lib dynamique, ca ferait gagner des octets

>Mais on n'a pas besoin de la partie TSR en _nostub.
>Sauf si on installe un TSR, mais comme ce n'est pas possible (de manière propre) en mode kernel, ce n'est pas en discussion.
Ce n'est pas possible tout simplement.

>La solution de AMS a quand-même un avantage. Le suivant marche en _nostub et pas en mode kernel:
>.include "os.h"
>...
>format: .asciz "%lp"
>buffer: .space 9
Je me demande encore quel est l'interet de ton programme.
Elle fait perdre de la place pour permettre cela ?

>Comme tu vois, si l'adresse relogée est corrompue pour une raison ou une autre, l'adresse correcte est restaurée en mode _nostub, alors qu'en mode kernel, ou avec la solution que tu proposes, l'adresse calculée peut valoir n'importe quoi et faire tout planter (pas dans cet exemple-là, mais dans un cas concret).
Si l'adresse relogee est corrompue, il y a de TRES FORTES chances que le reste du code qui n'est pas touchee par le relogement des adresses soit aussi touchee !
Donc inutile quand meme la plupart du temps.

>TIGCCLIB supporte exactement les mêmes fonctionnalités (sauf EXECUTE_IN_GHOST_SPACE et ENABLE_ERROR_RETURN) en mode kernel et en mode _nostub.
C'est bien ce que je critique !

>Seulement si tu passes à côté de l'abstraction de TIGCCLIB. Avec TIGCCLIB, des choses comme CALCULATOR fonctionnent exactement de la même manière dans les 2 cas.
Grace aux preprocesseur C ! Pas en assembleur.

>Sauf si on fait comme DB92.
Exemple trivial.

>Comment ça?
Checking lors des programmes kernels non-derelogees et derelogement automatique.

>Ça nous obligerait à patcher GCC pour des trucs qui devraient être sous la responsabilité des headers.
Pas tant que ca ! Plutot de la responsabilite du linkeur. Donc patcher GCC ne serait pas idiot.

>Hors de question. On ne va pas changer le nom de TIGCCLIB,
Tu l'aimes ?

>et on ne va pas rajouter un neuvième caractère (numéro de version) au nom du fichier non plus.
...

>http://tict.ticalc.org
Bonne blague

>Je ne vois pas le problème que ça poserait en pratique.
Fais le et decouvre.

>Et on se retrouve avec le problème résolu 2 fois dans certains cas. Mais bon, tu as raison, il vaut mieux résoudre un problème 2 fois plutôt que pas du tout.
Oui.

>Ton include utilise des hacks assez bizarres. Je te les ai signalés, mais tu as refusé d'en corriger quelques uns.
Oui.

>Par exemple, pourquoi ton hack pour le support pour exit? Le code de tipatch.lib marche très bien! Et même mieux, parce que ton code ne permet pas NO_EXIT_SUPPORT.
Ben dans ce cas tu utilises tigcclib.

>D'ailleurs, tu risques d'avoir des ennuis quand le code de tipatch.lib sera changé en "startup sections" dans le nouveau linker de Sebastian.
Tant pis ! On verra alors.

>Dis-moi comment on était censés implémenter le découpage lors du linking avec un système de linking en 2 étapes: ld ne peut sortir qu'un .o, obj2ti ne reçoit qu'un seul fichier .o. Ce découpage sera réalisable (mais pas nécessairement réalisé) avec ld-tigcc (TIGCC 0.95), mais il ne l'était pas du tout quand le support des DLLs a été introduit.
Je crois qu'on s'est mal compris des le debut. Je parle de maintenant.

>>push_internal_simplify par exemple.
>Et ton problème est où? C'est accessible à partir de AMS 1.01:
Ce N'EST PAS dans l'API d'AMS 1.0x !
C'est un Hack pour y avoir acces sur AMS 1.0x

>Les fonctions que tu juges "inutiles" ne le sont pas nécessairement. Certaines fonctions utiles manquent, mais les APIs parfaites n'existent pas.
CustomOn ? CustomOff ? Tres utiles si on peut pas definir nous meme le custom.
Et on peut y acceder quand meme pas un NG_execute bien place.
(NG qui signifie d'ailleurs ?)

>Il y a des fonctions Fopen et liées qui ressemblent à du C ANSI, mais ne le sont pas vraiment, dans AMS 2.
Elles ne ressemblent pas vraiment.

>Mais de toute façon, fopen est implémentable en assez peu d'octets en termes de vat.h, comme on l'a fait dans tigcc.a.
Tu veux savoir en combien d'octets je reimplemente toute les fonctions de la VAT d'AMS
1Ko.

>Pour printf: il y a vcbprintf dans la ROM, et cette fonction fait presque tout le travail de printf et permet au printf de tigcc.a d'être très compact.
Cette fonctions 'vcbprintf' n'est pas exporte dans l'API d'AMS. Merci de me le rapeller.

>Ça ne fait pas vraiment partie des fonctions les plus importantes.
Pour toi. Et ce ne sont pas des fonctions.

>AMS != OpenGL
>Il y a FillTriangle, ça suffit largement. De toute façon, le texture mapping avec la vitesse de AMS serait inutilisable.
Bof. Pas tellement plus lent que DrawIcon je pense.
Et puis depuis quand tu t'interresses a la vitesse ?

>Au fait, je traînais depuis longtemps l'idée de mettre un lanceur de style ttstart en Exec et de cacher le vrai programme dans le début du PRGM. Mais je n'ai jamais essayé de la réaliser, parce que je trouve ça vraiment abusé que de mettre de l'assembleur dans un PRGM.
huhu. Tu verras.

>Et moi, je pense que non. Il rejette normalement les fichiers "corrompus" (par exemple les chaînes de caractère qui n'en sont pas).
Sauf que si on l'envoie sur la calc par un autre moyen, puis qu'on le recupere avec graphlink, la ca marche.

>C'est trop demander que de demander aux auteurs de recompiler leur programme une fois tous les 4 ans? Ben moi, je trouve que non.
Ils oublient leur programme en 4 ans.

>En tout cas, _keytest et tous les #defines de compat.h sont prêts pour un nouveau modèle.
Cool.

>Et d'ailleurs, un troisième type de modèle totalement différent f**trait aussi la m*rde en mode kernel et obligerait donc aussi de recompiler pas mal de programmes:

>- Beaucoup de programmes (entre autres ceux compilés avec TIGCC, mais pas seulement - cf. TxtRider, ziplib, ...) choisissent des constantes en fonction du résultat de tst.w CALCULATOR. Le kernel n'a aucun moyen de rajouter une troisième possibilité sans que le programme soit recompilé.
Je me debrouillerais alors. En choisissant le CALCULATOR le plus proche du resultat qu'il faudra produire.

>- Les EXTRA_RAM_CALLS cesseront eux aussi de fonctionner en présence d'un troisième modèle radicalement différent des 2 autres (parce qu'il n'y a que le choix entre 2 valeurs - c'est d'ailleurs un bon argument contre l'utilisation des EXTRA_RAM_CALLS dans TIGCC: ils ne sont pas du tout conçus de manière extensible, donc on fait quoi quand un nouveau modèle arrive?).
Je croyais qu'il etait prevu pour 2006 ?
Et bien pour les programmes ne possedant pas le bit de la machine, je mettrais l'extraramcall la plus adapte, et sinon je ferais evolue le format des extra-ramcalls.
Satisfait ?

>D'ailleurs, déjà pour la V200, si un programme avait utilisé des EXTRA_RAM_CALLS pour choisir entre 0x2xxxxx et 0x4xxxxx, il n'aurait plus fonctionné.
Tres peu probable, car de telles choses dependent plus d'AMS que de CALCULATOR.

>C'est bien ça: tu es paresseux.
Pas toi ? Je suis tellement paresseux que je tape 400Ko de code source en ASM pour rien.

>Ça explique aussi pourquoi tu te plains des quelques #defines à mettre si tu veux désactiver le code d'initialisation de TIGCC.
Aussi c'est vrai.

>[Ctrl]+[F]SymFindPtr[ENTER]
Et dans plusieurs fichiers ? Non, je ne dis pas que ca soit difficile. C'est plus long c'est tout.

>Si c'est vraiment un problème, il suffit d'utiliser une indirection supplémentaire.
D'ou du temps et des octets de perdu.

>Sauf que ce sont 16, pas 12. Désolé, j'ai raté cette erreur en me relisant. Mais tu ne l'as pas remarquée, toi non plus.
Pas tout a fait. 16 - (d0-d2/a0-a1 + a7/a6) = 9 registres globals libres. Si on fait appel souvent aux romcalls. 14 si on n'y fait pas appels.
En fait, ca depend du contexe.

>C'est justement ça que je te reproche.
Tant pis.

>On n'utilise pas de BackBuffer.
C'est parfois plus rapide.

>Et puis le fait de permettre à la taille de l'écran d'être variable ralentit et agrandit pas mal les routines graphiques. Cf. BitmapPut. La dernière fois que j'ai regardé, genlib n'avait pas l'air de supporter les écrans 400×300 non plus...
Certes mais je n'ai jamais voulu que genlib soit archi-hyper flexible.
Et BitmapPut est lent, mais pas a cause de la taille de l'ecran varaible (Cf Pedrom\BitmapPut).

>C'est un hack parce que tu implémentes un système d'allocation totalement différent par dessus celui du système d'exploitation.
Ou est le probleme ? J'alloue normalement un grand Handle que la librarie gere elle meme.
Cela n'a rien d'un hack.

>N'empêche que tu tournes autour du problème alors qu'il suffirait d'adapter les programmes pour utiliser des stratégies d'allocation plus adaptées à la plateforme.
Mais pas du tout ! On est parfois obbliger d'avoir recours a des allocations dynamiques. Souvent tres souvent. Dans ce cas, je deconseille d'utiliser malloc. Utilise genalib c'est fait pour.

>Et as-tu des résultats documentables? Si tu sais pourquoi une combinaison est mieux qu'une autre, documente-le. Sinon, ben tant pis.
Je crois que ca sera tant pis alors Rien de documentable.


>Le problème est que c'est beaucoup de travail pour quelque chose qui n'est ni une correction de bogue, ni vraiment une addition de fonctionnalité.
Pas tant que ca si son linkeur est bien ecrit.

>Mais je ne dis pas du tout que la réponse définitive sera "non". Il faut suggérer l'amélioration à Sebastian, il demandera mon avis et éventuellement celui de Zeljko, et puis on prendra une décision. Alors: comptes-tu suggérer ça à Sebastian ou dois-je le faire?
Heu... Je prefererais que ca soit moi. sebastian@tigcc.ticalc.org nan ?

>Est-ce vraiment une fonctionnalité (surtout vu que ça donne du code "plus compact, plus rapide, plus petit" seulement en mode kernel)?
Tout depend de ta definition de fonctionnalite.

>DLL = dynamically linked library. C'est exactement la même chose que le terme "librairie dynamique".
DLL = WINDOWS systeme = de la merde.

>Je ne sais plus. Mais en tout cas, on ne parle pas de "library" pour des données normalement.
qu'est ce que du code que des donnees ayant un sens ?

>Ben non. Thomas Nussbaumer est un auteur qui agit de manière responsable et altruiste. Il met toujours à jour ses programmes quand il y a des problèmes. Tous les programmeurs devraient suivre son exemple.
J'attends depuis 2 mois la nouvelle version de tictex avec les modifs que je les ai file (et qui corrige quelques bugs).

>Depuis quand?
Dans le code d'inialisation oué Content.

>Non. Ça prend la mauvaise fonte si on utilise ROMedit ou Font Installer Demo.
Ca prend la fonte du boot, ce qui est prevu.

>Pour _RAM_CALL_00E oui. Pour les autres absolument pas. Et rien ne t'empêche de rajouter un autre RAM_CALL pour tios::font_medium (maintenant que le problème de tios::font_small et tios::font_large définis en ses termes est résolu), et de renommer _RAM_CALL_00E en tios::boot_fonts.
Tu veux que je rajoutes 3 autres RAM_CALLS ?
Ok, mais c'est toi qui me les a demande alors.

>Parce que tes suggestions sont soit irréalisables, soit extrèmement difficilement réalisables.
mais interressantes

>Il y a 6 lignes seulement parce que j'ai été obligé de couper l'appel à GraySprite16_MASK en 2 lignes à cause de la largeur limite du forum. Il était en 5 lignes avant.
Mais cette ligne compte double vu sa longeur

>genalib pourrait très bien exister en statique. Ce n'est que parce que toi, tu refuses de faire une version statique qu'elle ne marche qu'en mode kernel.
Parce que je compte faire une mise a jour qui double la vitesse. Il me reste a la debogguer de maniere saine.

>Entre les forcer à rester ignorants et les forcer à apprendre, il y a une grosse marge.
Qu'on appelle education.

>À part toi, qui utilise ça?
Bonne question. Mais c'est tres utile lorsqu'on comprend.

>Il faut déjà une journée pour avoir une idée vague de son fonctionnement. C'est beaucoup trop compliqué.
Arg. Je suis sur que d'autres ont compris plus rapidement que toi.

>Oui, mais toi, tu fais exprès. 96 missiles à la fois
C'est ce qu'on appelle la demesure. C'est du fun !

>Un moteur 3D est un cas bien particulier. Oui, chaque FPS compte en 3D
Pourquoi ?

>void *a;
>if (!(a = malloc(7680)) || !GrayOn())
> {
> ST_helpMsg("Not enough memory");
> return;
> }
Sauf que tu oublies parfois de desallouer a...

>Sinon, ça n'a rien à voir, mais mon prof de physique m'a dit que la persistance rétinienne de l'oeil est de 100 ms, ça signifie que lorsqu'on regarde une image, elle reste pendant 100 ms dans notre vue, donc il faut que le fps soit d'au moins 10 fps pour qu'on ait une impression de fluidité, théoriquement.
Theoriquement oui. Mais pas des images statiques.

>Mais bon, moi je trouve que c'est mieux à 20 fps quand même.
Oué parce que cf au dessus.

> filelib
>Je ne toucherai certainement pas à tes programmes.
>filelib est boguée, sale, et inutile. Utilise vat.h directement!
Elle a ete corrigee depuis. Mais bon je ne garantis rien puisque c'est pas moi qui l'ai ecrite.

>Pour shrnklib, utilise ttpack à la place.
Plus lent.

>Pour ta librairie personnelle, recompile-la en statique.
Ils l'utilisent surement pour autre chose.

>Et hop, plus besoin de USE_KERNEL.
Mais non.

>On est très rarement "juste" dans un jeu/programme 2D. Les seuls cas où les 10 FPS étaient vraiment difficiles à atteindre que j'ai vus étaient des jeux 3D.
Tu veux que je te cites des exemples de programme 2D qui rament ? Regarde la serie des Ultima par exemple. Meme sur un P200 Ultima8 saccade.

>Mais alors pas du tout. Elle n'est pas moins efficace ni moins adaptée que genlib.
Mais si ! Elle est moins efficace car ils manquent les fonctions clippées, et ils manquent les fonctions planes. Mais elle va bien pour faire un shell.

XDanger a écrit :
Ne pas vouloir faire les suggestions pour le _nostub, pour laisser le _nostub dans la merde où tu prétends qu'il est, c'est quoi ?

Ben a mes yeux, la seule suggestion possible est : passer en mode kernel.
Je crois pas que ca aide beaucoup

Dire 'Kevin speaks and I don't want to listen anymore', c'est quoi ?

Technique secrete Ayamamoshi pour faire enrager les Kevin

Ne pas écouter les suggestions pour ton kernel, c'est quoi ?

J'ecoute. Mais je ne suis pas d'accord avec ta suggestion, c'est tout.

Kevin Kofler a écrit :
Il faudra m'expliquer pourquoi tu as changé la spécification de cette manière stupide malgré qu'on t'ait conseillé de faire le contraire. Comme j'ai déjà dit plusieurs fois:
Rien ne t'empêche de rajouter un autre RAM_CALL pour tios::font_medium (maintenant que le problème de tios::font_small et tios::font_large définis en ses termes est résolu), et de renommer _RAM_CALL_00E en tios::boot_fonts. Comme ça, tu peux utiliser les bonnes fontes pour tios::font_medium, tios::font_small et tios::font_large après recompilation, et les anciens programmes non recompilés/réassemblés marcheront toujours (mais avec les fontes du boot).

Parce que ca a toujours ete les fonts du boot que les kernels prennaient. C'etait implicite. La je l'ai rendu de maniere explicite.
Il faut que je fasse un sondage pour savoir si je les rajoute ou pas.

filelib
Je ne toucherai certainement pas à tes programmes.
filelib est boguée, sale, et inutile. Utilise vat.h directement!

Pour shrnklib, utilise ttpack à la place.
Pour ta librairie personnelle, recompile-la en statique. Et hop, plus besoin de USE_KERNEL.

Filelib je vais essayer de m'en passer.Je n'ai pas envie d'alourdir mon prog pour des neuneux qui ont la flemme de taper 'preos()' alors je reste en Kernel
Sfontlib je l'utilise dans presque tous mes programmes alors je la garde en dynamique. D'ailleurs elle serait adaptable a d'autres mais elle n'est absolument pas optimisée pour le moment.

certes mais personellement je n'ai trouvé aucun bug dérangeant sauf peut être dans les version furtive(changées en moins de 1 semaine) que je n'ai pas eu l'occasion de tester

c'est vrai

Et alors? Ça ne change rien à ce que j'ai dit.

Peut-être que c'est parceque tu a détourné le sujet. Je dis que a cause des launcher en surnombre beaucoup de gens perdent de la place sans le savoir et que c'était, a mon avis, un des avantages des KernelPack sur les ExePack le débat n'est pas ailleurs.
[cite]

On est très rarement "juste" dans un jeu/programme 2D. Les seuls cas où les 10 FPS étaient vraiment difficiles à atteindre que j'ai vus étaient des jeux 3D.

comme je l'ai déjà dis tout dépends de la complexité du jeu, Krypton ou CF ont sans doute plus de dificultés a les atteindre que backgammon

Mais alors pas du tout. Elle n'est pas moins efficace ni moins adaptée que genlib.

Je renonce a répondre tellement t'est borné.

PpHd a écrit :
>Je te signale que tu es passé totalement à côté de mon argument, qui est que les librairies dynamiques peuvent elles aussi avoir des problèmes de mise à jour si certaines fonctions sont codées sous forme de macros. Et genlib est dans ce cas-là. Ok. Je reprends. Les macros de genlib ne peuvent pas poser ce genre de probleme de mise a jour puisque j'ai choisir des fonctions qui peuvent ne pas necessiter de mise a jour. Pour Tigcclib, c'est impossible.

On ne sait jamais. Il pourrait toujours y avoir une erreur dans tes macros.

>Et je trouve quand-même que le minimum d'effort qu'on puisse attendre d'un programmeur, même s'il ne s'intéresse plus à la programmation sur calculatrices, est de faire Project/Build. S'il n'est pas prêt à faire ça, ni à laisser ses sources pour qu'un autre puisse le faire, c'est de l'égoïsme de la part de l'auteur. Ça n'a rien à voir avec le format de l'exécutable. Peut etre plus simplement qu'il ne s'y interresse plus et qu'il oublie. Cela me parait plus posible.

Oublier ce qu'on a programmé et publié??? Moi, je sais très bien ce que j'ai publié vu que ça traîne encore sur mon site (sauf pour DB92, parce que ma version n'est plus à jour - hwti l'a repris en partant de mes dernières sources).

>Je compte un seul lanceur quand je calcule la taille parce que je compte ce qui est nécessaire pour lancer le programme, pas ce que l'utilisateur choisit d'utiliser. Mais oui. C'est bien ce que j'avais compris.

Mais alors pourquoi ta réponse "Mais alors pourquoi tu en tiens compte dans tes calculs ?"?

>Sinon, je code un kernel de 64 KO et je dis: "Moi, j'utilise mon kernel de 64 KO, donc je compte 64 KO pour chaque programme pour kernel. "
Tu auras du mal a faire un kernel de 64Ko qui fonctionne sur AMS 2.0x

On peut le faire en plusieurs fichiers.

>Tu as déjà vu un Mario avec 20 ennemis qui sautent en même temps, toi? Disons 10, et alors je dirais oui. Plus les boules qu'ils envoient et ca fait 20.

10? D'habitude, ce sont plutôt 5 ou 6 maximum (sauf dans certains cas extrèmes de Super Mario World où il peut y en avoir une douzaine), et ils ne lancent en général pas de boules. Et le nombre de boules que Mario peut lancer en même temps est limité à 2 normalement. Total: 8 ou 9 sprites qui bougent.

>Bon, EM_blockErase et fonctions liées et quoi d'autre? Rien qui était en utilisation réelle. Et puis les kernels n'ont rien fait pour résoudre ce problème. Nous oui: on a mis OSVRegisterTimer et OSVFreeTimer dans tigcc.a. Ok, tu veux que je mettes ces fonctions dans le kernel, c'est cela ? Alors que personne ne va s'en servir ?

Ce n'est plus la peine.
Ce que je dis, c'est que les développeurs de kernels de l'époque auraient dû le faire. Ils ne l'ont pas fait. Maintenant, c'est trop tard, parce que de toute façon plus personne n'utilise ces ROM_CALLs. (Si quelqu'un utilise ces fonctions maintenant, il utilise les versions dans tigcc.a.)

>Mais nous, on a résolu le problème très vite. Les kernels n'ont rien fait pour le résoudre. Le seul programme qui l'utilisait etait en _nostub, je me trompe ?

Je ne sais plus. Le programme en question était Othello II de FL, et il était d'abord en _nostub, puis est passé en kernel, et puis repassé en _nostub. Je ne sais plus en quoi il était au moment du problème.

>Je te signale que je ne parle pas du temps total mis pour calculer un frame, mais de la différence entre le temps mis par une routine optimisée en vitesse et le temps mis par une routine optimisée en taille. Je ne pense pas que ça dépasse l'ordre de grandeur des 100 µs (1200 cycles). Peut-être que je me trompe, mais il faudra des chiffres pour montrer que j'ai tord.
Compare (Attention je parle du point de vue algorithmique, je connais ScreenClear !) :
lea LCD_MEM,a0
move.w #960-1,d0
\loop:
clr.l (a0)+
dbf d0,\loop
A :
Une boucle completement deroulee avec des movem. Et apres dis moi si ca ne fait pas 1200 cycles de difference.

Bon, d'accord, tu as raison. J'ai ressorti timing.txt et voilà:
lea 0x4c00:w,%a0 -> 8
move.w #960-1,%d0 -> 8
0: -> 0
clr.l (%a0)+ -> 20 * 960 = 19200
dbf %d0,0b -> 10 (?) * 959 + 12 (?) = 9602
total: 28818
Avec des movem, ça fait beaucoup moins.

On voit que je n'ai pas du tout l'habitude de compter en cycles.

>Mais ça n'a rien à voir avec un CounterStrike! Un sonic lent. Tu penses que ca a un interet ?

Ça dépend de ce qu'on entend par "lent". À 1 FPS, ça ne doit pas rendre très bien (alors qu'un Mario à 1 FPS passe encore). Mais un Sonic tournant en le tiers de la vitesse de SMA serait tout à fait jouable à mon avis. (SMA est trop rapide. Du moins sur VTI, avec "Restrict to actual speed" évidemment.)

>Mais les fonctions offertes par genlib sont sur la calculatrice même si elles ne sont pas utilisées!
Et bien il n'y a qu'a les utiliser

Et si on n'en a pas besoin?

>Tu connais le passage par registres? Il me semblait que oui, mais j'ai des doûtes là. Oui. Mais ca consomme quand meme un registe, ce qui peut etre genant (Les routines necessitant 10 registres sont un peu penibles parfois).

Et ben, tu "spilles" un registre sur la pile, tu l'utilises pour tes calculs et tu le restaures. GCC fait ça systématiquement s'il a besoin de plus de registres qu'il n'y en ait de disponibles.

>Tu peux même utiliser une "global register variable". Comme ça, il n'y a rien à copier, sauvegarder ou restaurer (sauf au tout début et tout à la fin).
Mais on perd un registre ! Et on a souvent besoin ailleurs, pour un autre global plus interressant.

Tant pis, tu consommes un registre de plus en global et tu "spilles" tes registres en local.

>Bon, d'accord, je vais tester ça 1ms entre un appel a tigcclib et a extgraph. Oupss je suis mal barre la.

Plus la peine de tester alors?

XDanger, sort nous ta version, vite ! Ca sera jouable je pense alors.

LOL, c'est la première fois que tu es en faveur d'une accélération de ExtGraph.

>Ben, tu peux lui conseiller de ne pas afficher de message dans ce cas, par exemple. Et de faire quoi a la place ?

Bonne question...
Il pourrait utiliser un ST_helpMsg plutôt qu'un DlgMessage, ça serait probablement moins dangereux.

PpHd a écrit :
>Tant pis.
>Je vois nettement plus de personnes qui utilisent DoorsOS que AMS 1.0x, et pourtant tu t'en fiches de la compatibilité avec DoorsOS.
Y'a encore des personnes qui utilisent un kernel dans ton entourage immediat

J'en vois sur Internet, pas dans mon entourage immédiat.

Je ne vois pas en quoi je me fiches de la compatibiltie avec DoorsOs puisque Preos permets d'executer les programmes DoorsOs (Je bosse encore sur les v2).

Mais SMA n'est plus compatible avec DoorsOS, par exemple.

>En quoi la liberté de choix est-elle un problème??? Ta manière de "centraliser" les problèmes est celle utilisée par les régimes autoritaires.
Absolument pas ! Cela n'a rien a voir avec les regimes autoritaires ! Il ne faudrait pas exagerer ! Centraliser une chose peut etre une maniere tres democratique de faire les choses.

Ce que je veux dire, c'est que pour toi, "centraliser" = imposer.

>Mais ce n'est qu'en ayant cet idéal-là (même si ce n'est évidemment qu'un idéal) qu'on crée des programmes faciles à utiliser.
Un programme kernel reste facile a executer.
1. Tu installes le kernel.
2. Tu executes le programme. Pas de quoi crier a la complexite extreme (Pas de variables systemes a installer ou autres).

Plutôt:
1. Tu envoies le kernel à la calculatrice.
2. Tu envoies les librairies (par exemple le pack stdlib) à la calculatrice.
3. Tu exécutes le kernel. C'est surtout ça qui est totalement contre-intuitif. On s'attend à ce que le programme marche sans avoir lancé quoi que ce soit avant.
4. Tu envoies le programme à la calculatrice.
5. Tu exécutes enfin le programme.

En _nostub, c'est beaucoup plus simple.
1. Tu envoies le programme à la calculatrice.
2. Tu exécutes le programme.
C'est totalement intuitif.

>Comment ça? Le matériel est totalement inadapté. Explicite step.

- Pas assez de RAM pour faire tourner un bon compilateur C (comme GCC).
- Processeur trop lent pour faire tourner un bon compilateur C (comme GCC).
- Pas assez d'archive pour pouvoir stocker de grandes sources.
Et à ces problèmes matériels vient s'ajouter la limite de taille des fichiers trop petite pour de grandes sources.

>Bon, OK. Mais tout ce système de librairies dynamiques est copié directement sur Fargo. Parce que c'est un bon systeme

Toi, tu trouves ça. Moi non. Un bon système de librairies dynamiques n'existe pas.

(Utiliser les ordinaux est bien mieux qu'utiliser les noms exportes par exemple).

Ça économise de la place, mais c'est un hack.

>Non, et c'est pour ça que je n'arrête pas de dire que c'est inutile.
Pourquoi ?

>Tu essayes de faire faire au kernel des choses pour lesquelles il n'était tout simplement pas prévu. Et c'est grave docteur de faire evoluer quelque chose ?

Le problème, c'est que tu essayes de faire évoluer un vieux système dépassé.

>Ce sont des améliorations d'ordre vraiment mineur. En es-tu si sur ?

Oui.

>Etc. quoi? Je suppose que ce sont des changements (même pas forcément des améliorations) d'ordre encore moins important. Compatibilite 89 / 92+.

Heureusement... Il est évident qu'un kernel TI-89/92+ soit compatible TI-89/92+.

Format de reloc non compresse par exemple aussi.

Ça, ça ne change rien au principe général. C'est d'ailleurs un changement négatif.

>On corrige les bogues avant et on rajoute les nouveaux features après. La TICT a toujours fonctionné comme ça, et ça se voit: rares sont les programmes aussi stables que les programmes TICT. C'est cela en theorie. En pratique on ne fait pas toujours cela pour diverses raisons.

Mais on devrait au moins essayer de le faire.

Et ça n'explique toujours pas la corrélation que j'ai observée entre l'utilisation de genlib et le fait que les jeux restent bloqués en état de bêta. Les bogues seraient-ils dus à genlib? genlib a eu longtemps une réputation d'être boguée, donc ça ne m'étonnerait pas.

>Les programmes pour PC ont tous tendance à être beaucoup trop gros à mon avis.
Et en plus tu voudrais qu'ils incluent tous les libs statiques
Si seulement ils exportaient le start-up C++ en lib dynamique, ca ferait gagner des octets

Sous Linux, c'est fait d'habitude. Pas seulement le startup, mais aussi la librairie standard, d'ailleurs. Le résultat, c'est que pour utiliser un programme en C++ sur une autre distribution Linux (ou sur une autre version de la même distribution) que celle sur laquelle il a été compilé, c'est le b*rdel. Donc maintenant, je linke libstdc++ statiquement dans les programmes en C++ de la version Linux de TIGCC (actuellement Obj2Ti), comme dans la version Windows (MinGW fait ça d'office).

>Mais on n'a pas besoin de la partie TSR en _nostub.
>Sauf si on installe un TSR, mais comme ce n'est pas possible (de manière propre) en mode kernel, ce n'est pas en discussion. Ce n'est pas possible tout simplement.

Si, c'est possible. N'oublie pas qu'on est sur un système sans MMU, donc rien ne m'empêche de trouver et de traffiquer ta sauvegarde des vecteurs et/ou de EV_hook.

>La solution de AMS a quand-même un avantage. Le suivant marche en _nostub et pas en mode kernel:
>.include "os.h"
>...
>format: .asciz "%lp"
>buffer: .space 9
Je me demande encore quel est l'interet de ton programme. Elle fait perdre de la place pour permettre cela ?

C'était juste une démonstration. Du code auto-modifiant capable de changer les adresses relogées peut être intéressant parfois (surtout si on fait des calculs avec l'adresse plutôt que de la remplacer avec une adresse fixe comme dans mon exemple).

>Seulement si tu passes à côté de l'abstraction de TIGCCLIB. Avec TIGCCLIB, des choses comme CALCULATOR fonctionnent exactement de la même manière dans les 2 cas. Grace aux preprocesseur C ! Pas en assembleur.

En assembleur, tu mets le startup code de détection de modèle (avec le nouveau linker de Sebastian, il y aura juste un xdef à mettre) et:
CALCULATOR equ __calculator
et voilà, ça fonctionne comme en mode kernel.

>Ça nous obligerait à patcher GCC pour des trucs qui devraient être sous la responsabilité des headers. Pas tant que ca ! Plutot de la responsabilite du linkeur. Donc patcher GCC ne serait pas idiot.

J'ai déjà assez de patches à GCC à maintenir comme ça.

>http://tict.ticalc.org
Bonne blague

Ce n'est pas une blague. Les programmes TICT sont vraiment codés de manière très propre.

>Je ne vois pas le problème que ça poserait en pratique. Fais le et decouvre.

Précise. Je sais de quoi je parle. La simplicité du format _nostub fait qu'il est très simple de rajouter du code tout au début. La seule difficulté est qu'il faut changer les offsets dans la table de relogement. Le programme d'origine sera appelé comme sous-programme, comme dans le système de startup code de TIGCC.

>Oui, mais toi, tu fais exprès. 96 missiles à la fois C'est ce qu'on appelle la demesure. C'est du fun !

exact
c vrai que le prog ralenti un peu qd on utilise cete super-arme
mais l'effet est assez saisissant, du moins les premières fois
et qd j'aurai appliqué les idées d'optimisation que j'ai en tête, je pense que ça ralentira un peu moins...

>Mais alors pas du tout. Elle n'est pas moins efficace ni moins adaptée que genlib. Mais si ! Elle est moins efficace car ils manquent les fonctions clippées, et ils manquent les fonctions planes. Mais elle va bien pour faire un shell.

si c bien de Extgraph que vous parlez, je suis d'accord : bien adaptée pr les menus d'un jeu... mais bcp moins pr le jeu en lui-même ; ne serait-ce que parce qu'elle n'est pas clippée...

(je m'aréte avant le post 228 : je dois aller bosser )

squale92
a écrit : si c bien de Extgraph que vous parlez, je suis d'accord : bien adaptée pr les menus d'un jeu...

mais bcp moins pr le jeu en lui-même ; ne serait-ce que parce qu'elle n'est pas clippée...

Ça c'est vrai par contre. Mais je crois qu'elle va bientôt l'être

PpHd a écrit :
>Par exemple, pourquoi ton hack pour le support pour exit? Le code de tipatch.lib marche très bien! Et même mieux, parce que ton code ne permet pas NO_EXIT_SUPPORT. Ben dans ce cas tu utilises tigcclib.

C'est à moi que tu dis ça?! Je ne programme pas en mode kernel de toute façon, donc la question ne se pose pas.

Ça n'explique toujours pas pourquoi tu crois que c'est intelligent de faire un hack totalement inutile de la sorte.

>Dis-moi comment on était censés implémenter le découpage lors du linking avec un système de linking en 2 étapes: ld ne peut sortir qu'un .o, obj2ti ne reçoit qu'un seul fichier .o. Ce découpage sera réalisable (mais pas nécessairement réalisé) avec ld-tigcc (TIGCC 0.95), mais il ne l'était pas du tout quand le support des DLLs a été introduit. Je crois qu'on s'est mal compris des le debut. Je parle de maintenant.

En effet, maintenant, ton idée devrait être implémentable. Mais maintenant, le support des DLLs y est déjà.

>>push_internal_simplify par exemple.
>Et ton problème est où? C'est accessible à partir de AMS 1.01:
Ce N'EST PAS dans l'API d'AMS 1.0x ! C'est un Hack pour y avoir acces sur AMS 1.0x

Et alors? Je m'en fiche si c'est dans la table des sauts. Tant que c'est dans la ROM et que ce n'est pas dur à trouver, je ne vois pas le problème. D'autant plus que c'est exporté depuis AMS 2.00, et que donc le hack est sûr à 100% (parce qu'il n'y aura pas de nouvelles versions 1.0x).

>Les fonctions que tu juges "inutiles" ne le sont pas nécessairement. Certaines fonctions utiles manquent, mais les APIs parfaites n'existent pas. CustomOn ? CustomOff ? Tres utiles si on peut pas definir nous meme le custom.

Déjà, ce sont des cmd_*, qui sont prévus avant tout pour l'usage interne de l'interpréteur BASIC, mais qui sont exportés parce qu'ils peuvent aussi être utiles pour les programmeurs C.
Et ensuite, il y a CustomBegin, CustomEnd, CustomFree et CustomMenuItem dans unknown.h.

Et on peut y acceder quand meme pas un NG_execute bien place.

Oui, mais c'est plus compliqué et plus lent.

(NG qui signifie d'ailleurs ?)

Aucune idée.

>Pour printf: il y a vcbprintf dans la ROM, et cette fonction fait presque tout le travail de printf et permet au printf de tigcc.a d'être très compact. Cette fonctions 'vcbprintf' n'est pas exporte dans l'API d'AMS. Merci de me le rapeller.

Peu importe. Ce qui compte, c'est qu'elle y est. Et elle est très facile à trouver sous n'importe quelle version de AMS.

>Ça ne fait pas vraiment partie des fonctions les plus importantes. Pour toi. Et ce ne sont pas des fonctions.

Ce ne sont pas des fonctions, donc ça ne fait pas partie des fonctions les plus importantes.
Mais franchement, fprintf(stdout ou fprintf(stderr (l'utilisation la plus courante de std*) n'apporte pas grand chose en fonctionnalité par rapport à un simple printf(.

>AMS != OpenGL
>Il y a FillTriangle, ça suffit largement. De toute façon, le texture mapping avec la vitesse de AMS serait inutilisable.
Bof. Pas tellement plus lent que DrawIcon je pense. Et puis depuis quand tu t'interresses a la vitesse ?

>Et moi, je pense que non. Il rejette normalement les fichiers "corrompus" (par exemple les chaînes de caractère qui n'en sont pas). Sauf que si on l'envoie sur la calc par un autre moyen, puis qu'on le recupere avec graphlink, la ca marche.

???
Ça ne devrait pas changer quoi que ce soit. As-tu comparé les 2 fichiers pour voir ce qui a changé?

>C'est trop demander que de demander aux auteurs de recompiler leur programme une fois tous les 4 ans? Ben moi, je trouve que non. Ils oublient leur programme en 4 ans.

Moi, je n'ai pas oublié ce que j'ai sorti il y a 4 ans. Ça fait bientôt 4 ans que j'ai commencé CHEMISLV, et je sors toujours les mises à jour de maintenance nécessaires (par exemple pour la compatibilité avec la version polonaise de AMS).

>- Beaucoup de programmes (entre autres ceux compilés avec TIGCC, mais pas seulement - cf. TxtRider, ziplib, ...) choisissent des constantes en fonction du résultat de tst.w CALCULATOR. Le kernel n'a aucun moyen de rajouter une troisième possibilité sans que le programme soit recompilé. Je me debrouillerais alors. En choisissant le CALCULATOR le plus proche du resultat qu'il faudra produire.

Le plus proche? Et s'il n'y a pas de plus proche? Imagine un écran 128×128, et une matrice clavier qui n'a rien à voir avec celle de la TI-89 ni avec celle des TI-92+/V200.

>- Les EXTRA_RAM_CALLS cesseront eux aussi de fonctionner en présence d'un troisième modèle radicalement différent des 2 autres (parce qu'il n'y a que le choix entre 2 valeurs - c'est d'ailleurs un bon argument contre l'utilisation des EXTRA_RAM_CALLS dans TIGCC: ils ne sont pas du tout conçus de manière extensible, donc on fait quoi quand un nouveau modèle arrive?). Je croyais qu'il etait prevu pour 2006 ?

Peu importe quand il arrive, on fait quoi quand il arrive? Les EXTRA_RAM_CALLs sont totalement inadaptés à la situation.

Et bien pour les programmes ne possedant pas le bit de la machine, je mettrais l'extraramcall la plus adapte, et sinon je ferais evolue le format des extra-ramcalls. Satisfait ?

Non! Si le nombre d'entrées des EXTRA_RAM_CALLs change en fonction des flags mis, ça sera l'horreur à gérer dans le linker!

>[Ctrl]+[F]SymFindPtr[ENTER] Et dans plusieurs fichiers ?

Les versions récentes de TIGCC IDE recherchent automatiquement dans tous les fichiers de ton projet.

Non, je ne dis pas que ca soit difficile. C'est plus long c'est tout.

On n'est pas à 10 secondes près quand on programme.

>Si c'est vraiment un problème, il suffit d'utiliser une indirection supplémentaire. D'ou du temps et des octets de perdu.

movea.w (%a0),%a0;adda.l %a3,%a0
4 octets et 16 cycles (1,25 µs). Il ne faut pas exagérer.

>Sauf que ce sont 16, pas 12. Désolé, j'ai raté cette erreur en me relisant. Mais tu ne l'as pas remarquée, toi non plus.
Pas tout a fait. 16 - (d0-d2/a0-a1 + a7/a6) = 9 registres globals libres. Si on fait appel souvent aux romcalls. 14 si on n'y fait pas appels. En fait, ca depend du contexe.

Je parlais des registres en total. Tu peux très bien utiliser %d0-%d2/%a0-%a1 pour les calculs. D'ailleurs, %a6 n'est pas spécial. (-fomit-frame-pointer n'est pas là juste pour faire beau.)

PpHd a écrit :
>Et puis le fait de permettre à la taille de l'écran d'être variable ralentit et agrandit pas mal les routines graphiques. Cf. BitmapPut. La dernière fois que j'ai regardé, genlib n'avait pas l'air de supporter les écrans 400×300 non plus...
Certes mais je n'ai jamais voulu que genlib soit archi-hyper flexible. Et BitmapPut est lent, mais pas a cause de la taille de l'ecran varaible (Cf Pedrom\BitmapPut).

Ta routine n'est même pas clippée.

>C'est un hack parce que tu implémentes un système d'allocation totalement différent par dessus celui du système d'exploitation.
Ou est le probleme ? J'alloue normalement un grand Handle que la librarie gere elle meme. Cela n'a rien d'un hack.

Et si on a besoin d'allouer plus de 65520 octets en tout?

>N'empêche que tu tournes autour du problème alors qu'il suffirait d'adapter les programmes pour utiliser des stratégies d'allocation plus adaptées à la plateforme. Mais pas du tout ! On est parfois obbliger d'avoir recours a des allocations dynamiques. Souvent tres souvent. Dans ce cas, je deconseille d'utiliser malloc. Utilise genalib c'est fait pour.

Qu'on utilise des allocations dynamiques, d'accord. Mais il ne faut pas en abuser non plus.

>Mais je ne dis pas du tout que la réponse définitive sera "non". Il faut suggérer l'amélioration à Sebastian, il demandera mon avis et éventuellement celui de Zeljko, et puis on prendra une décision. Alors: comptes-tu suggérer ça à Sebastian ou dois-je le faire? Heu... Je prefererais que ca soit moi. sebastian@tigcc.ticalc.org nan ?

Oui.

>DLL = dynamically linked library. C'est exactement la même chose que le terme "librairie dynamique". DLL = WINDOWS systeme = de la merde.

Ce n'est pas parce que cette abbréviation est utilisée par Windows qu'on ne peut l'utiliser pour rien d'autre.

>Ben non. Thomas Nussbaumer est un auteur qui agit de manière responsable et altruiste. Il met toujours à jour ses programmes quand il y a des problèmes. Tous les programmeurs devraient suivre son exemple. J'attends depuis 2 mois la nouvelle version de tictex avec les modifs que je les ai file (et qui corrige quelques bugs).

Patience, il n'a pas que ça à faire.

>Non. Ça prend la mauvaise fonte si on utilise ROMedit ou Font Installer Demo. Ca prend la fonte du boot, ce qui est prevu.

Pourquoi?

>Pour _RAM_CALL_00E oui. Pour les autres absolument pas. Et rien ne t'empêche de rajouter un autre RAM_CALL pour tios::font_medium (maintenant que le problème de tios::font_small et tios::font_large définis en ses termes est résolu), et de renommer _RAM_CALL_00E en tios::boot_fonts.
Tu veux que je rajoutes 3 autres RAM_CALLS ? Ok, mais c'est toi qui me les a demande alors.

Non, surtout pas. C'est déjà assez chaotique comme ça.
Mais je ne vois pas du tout l'intérêt d'exporter les fontes du boot et pas celles utilisées par AMS (qui ne sont pas nécessairement celles dans AMS lui-même d'ailleurs, cf. Font Installer Demo), sauf pour _RAM_CALL_00E à cause des equates débiles utilisant les offsets du boot.

>Il y a 6 lignes seulement parce que j'ai été obligé de couper l'appel à GraySprite16_MASK en 2 lignes à cause de la largeur limite du forum. Il était en 5 lignes avant.
Mais cette ligne compte double vu sa longeur

C'est un seul appel de fonction, donc c'est une ligne.

>genalib pourrait très bien exister en statique. Ce n'est que parce que toi, tu refuses de faire une version statique qu'elle ne marche qu'en mode kernel. Parce que je compte faire une mise a jour qui double la vitesse. Il me reste a la debogguer de maniere saine.

Tu as toujours une excuse...

>À part toi, qui utilise ça?
Bonne question. Mais c'est tres utile lorsqu'on comprend.

>Il faut déjà une journée pour avoir une idée vague de son fonctionnement. C'est beaucoup trop compliqué. Arg. Je suis sur que d'autres ont compris plus rapidement que toi.

Vu la manière de laquelle tu "expliques" ça dans la documentation, ça m'étonnerait.

>Oui, mais toi, tu fais exprès. 96 missiles à la fois C'est ce qu'on appelle la demesure. C'est du fun !

Ben, si on est démesurés, il ne faut pas s'attendre à que ce soit rapide.

>Un moteur 3D est un cas bien particulier. Oui, chaque FPS compte en 3D Pourquoi ?

Parce qu'on tourne autour des 10 FPS en 3D. Alors qu'on en est généralement loin en 2D.

>Pour shrnklib, utilise ttpack à la place. Plus lent.

Mais elle compresse mieux! (Mes tests l'ont montré.)

>Pour ta librairie personnelle, recompile-la en statique. Ils l'utilisent surement pour autre chose.

Et alors?

>Et hop, plus besoin de USE_KERNEL. Mais non.

Mais si.

>On est très rarement "juste" dans un jeu/programme 2D. Les seuls cas où les 10 FPS étaient vraiment difficiles à atteindre que j'ai vus étaient des jeux 3D. Tu veux que je te cites des exemples de programme 2D qui rament ? Regarde la serie des Ultima par exemple. Meme sur un P200 Ultima8 saccade.

Ben, évidemment que si on met plein d'effets spéciaux, c'est lent. Mais on n'a pas besoin d'une tonne d'effets spéciaux pour qu'un jeu soit jouable.

>Mais alors pas du tout. Elle n'est pas moins efficace ni moins adaptée que genlib. Mais si ! Elle est moins efficace car ils manquent les fonctions clippées,

XDanger, tu ne peux pas nous rajouter des fonctions clippées? Tout le monde râle à cause de ça.

et ils manquent les fonctions planes.

Un jeu n'a pas du tout besoin de fonctionner par plans. Il est beaucoup plus simple de travailler avec le scrolling de ExtGraph.

Mais elle va bien pour faire un shell.

Pour un shell, AMS suffit.

PpHd
a écrit : Ben a mes yeux, la seule suggestion possible est : passer en mode kernel.

C'est ça le problème.

Uther Lightbringer
a écrit : Je n'ai pas envie d'alourdir mon prog pour des neuneux qui ont la flemme de taper 'preos()' alors je reste en Kernel

Passer en _nostub n'est pas "alourdir" ton programme. Au contraire, c'est l'alléger parce qu'il a une dépendance en temps d'exécution (runtime dependency) en moins.

Sfontlib je l'utilise dans presque tous mes programmes alors je la garde en dynamique.

Ça ne t'empêche pas de la mettre en statique. J'utilise h220xTSR dans "presque tous mes programmes" et je le linke quand-même statiquement.

D'ailleurs elle serait adaptable a d'autres mais elle n'est absolument pas optimisée pour le moment.

Les autres auront beaucoup plus de chances de l'utiliser si tu la mets en statique. La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub.

Peut-être que c'est parceque tu a détourné le sujet. Je dis que a cause des launcher en surnombre beaucoup de gens perdent de la place sans le savoir et que c'était, a mon avis, un des avantages des KernelPack sur les ExePack le débat n'est pas ailleurs.

J'ai déjà compris que ton avis est que c'est un avantage que d'obliger les gens à faire ce que toi, tu trouves bien au lieu de les laisser faire ce qu'eux, ils trouvent bien. C'est totalement stupide et égocentrique comme position.

comme je l'ai déjà dis tout dépends de la complexité du jeu, Krypton ou CF ont sans doute plus de dificultés a les atteindre que backgammon

Aucun de ces jeux n'a vraiment de difficultés à atteindre les 10 FPS. Les seuls jeux TI-89/92+/V200 où la vitesse est un vrai problème que j'ai rencontrés jusqu'à présent étaient des jeux 3D.

Je renonce a répondre tellement t'est borné.

Coup bas -> poubelle.

squale92 a écrit :
exact
c vrai que le prog ralenti un peu qd on utilise cete super-arme

Pourquoi ne pas faire comme Phoenix? Il y a une super-arme pour laquelle seulement 5 projectiles sont affichés, mais le dommage apporté aux ennemis est bien plus important que ça, et les 2/3 des projectiles ennemis sont détruits (effacés de l'écran).

Kevin Kofler a écrit :
Pourquoi ne pas faire comme Phoenix? Il y a une super-arme pour laquelle seulement 5 projectiles sont affichés, mais le dommage apporté aux ennemis est bien plus important que ça, et les 2/3 des projectiles ennemis sont détruits (effacés de l'écran).

Pour le plaisir d'avoir une arme qui tire vraiment partout !
Mais c'est vrai qu'avec 96 missiles, ça fait beaucoup...
Il pourrait en mettre le quart (24) et ça suffirait.

>Passer en _nostub n'est pas "alourdir" ton programme. Au contraire, c'est l'alléger parce qu'il a une dépendance en temps d'exécution (runtime dependency) en moins.
Je vois pas vraiment ce que j'y gagne.

>Ça ne t'empêche pas de la mettre en statique. J'utilise h220xTSR dans "presque tous mes programmes" et je le linke quand-même statiquement.
C'est bien ce que je te preproche: c'est totalement inutile.

>Les autres auront beaucoup plus de chances de l'utiliser si tu la mets en statique. La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub.
Tant pis elle me sert surtout a moi si d'autre veulent l'utiliser tant mieux s'ils sont aussi bornés que toi il pouront la reprogrammer, ce n'est pas d'une grande difficulté. Si j'en ai fait une lib en dynamique c'est pour gagner de la place.

>J'ai déjà compris que ton avis est que c'est un avantage que d'obliger les gens à faire ce que toi, tu trouves bien au lieu de les laisser faire ce qu'eux, ils trouvent bien. C'est totalement stupide et égocentrique comme position.
Tu évites encore brillament le sujet. Sache que monsieur "j'aime contraindre les gens a faire du nostub et pas autre chose" que si je ne souhaite pas contraindre l'utilisateur mais qu'il puisse économiser de la place. si taper preos() est un contrainte insurmontable dans ce cas la je plaide coupable.

>Aucun de ces jeux n'a vraiment de difficultés à atteindre les 10 FPS. Les seuls jeux TI-89/92+/V200 où la vitesse est un vrai problème que j'ai rencontrés jusqu'à présent étaient des jeux 3D.
Peut-être parcequ'ils n'utilisent pas extragraph

>Coup bas -> poubelle.
Que veut tu que je te dise tu ne va pas affirmer que extraph en l'heure actuelle est plus rapide qe GraphX, Xlib ou genlib a par peut-être dans certains cas très particuliers

>Pourquoi ne pas faire comme Phoenix? Il y a une super-arme pour laquelle seulement 5 projectiles sont affichés, mais le dommage apporté aux ennemis est bien plus important que ça, et les 2/3 des projectiles ennemis sont détruits (effacés de l'écran).
Et pourquoi pas faire un jeu en mode texte! S'il veut faire des effet visuel qui rendent bien c'est son droit!

Bon, j'avoue, la prog TI, j'y touche de loin, donc je ne vais pas m'aventurer dans une discussion pour laquelle je serais vite débordé. Je suis aussi content que le dialogue soit moins tendu entre KK et PpHd.
Par contre 2 infos sur le PC :
Windows 3.xx utilise les accès disque de DOS. Il est possible qu'il ait une int propre mais elle utilise directement l'int DOS. Ce n'est qu'à partir de W95 que l'int accès disque est totalement réécrite pour Win (et d'ailleurs c'est beaucoup plus rapide)
A propos des DLLs de windows : ce sont en réalités des ressources (donc des données accessibles par un autre programme) doublées d'un support permettant d'implanter directement des fonctions dans la librairie (à la différence d'une ressource telle qu'on la rencontre sur AtariST/GEM qui ne contient que des données, le code n'étant que dans le .PRG). Je pense à ce propos que les bibliothèques de fonctions et les bibliotheques de données sont des concepts parfaitement viables, c'est le fait d'avoir utilisé la même extension .DLL pour les deux concepts qui est assez crade. Pour un bon programme, il faudrait l'exécutable, une librairie de données (icônes, strings - ce qui permet de faciliter les traductions... - & co) et une librairie de fonctions (ce qui permet de patcher plus facilement un programme pour corriger les bugs).
Sinon, une petite question toute bête : je pense avoir a peu près saisi les concepts, mais quelqu'un peut-il m'expliquer simplement la différence entre un kernel et un nostub (et si on me dit : yen a un qui a besoin d'un lanceur et l'autre d'un kernel, je le fusille).

Uther Lightbringer a écrit :
>Passer en _nostub n'est pas "alourdir" ton programme. Au contraire, c'est l'alléger parce qu'il a une dépendance en temps d'exécution (runtime dependency) en moins. Je vois pas vraiment ce que j'y gagne.

Tu te passes d'une couche d'émulation inutile.
Mais bon, le pseudo-_nostub de genlib est aussi une couche d'émulation, donc ce n'est pas beaucoup mieux. Tu devrais passer à une librairie graphique statique.

>Ça ne t'empêche pas de la mettre en statique. J'utilise h220xTSR dans "presque tous mes programmes" et je le linke quand-même statiquement. C'est bien ce que je te preproche: c'est totalement inutile.

Non, c'est très utile. Ça rend mes TSRs autonomes. D'ailleurs, même PpHd linke h220xTSR statiquement dans PreOs.

>Les autres auront beaucoup plus de chances de l'utiliser si tu la mets en statique. La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub. Tant pis elle me sert surtout a moi si d'autre veulent l'utiliser tant mieux s'ils sont aussi bornés que toi il pouront la reprogrammer, ce n'est pas d'une grande difficulté. Si j'en ai fait une lib en dynamique c'est pour gagner de la place.

Encore un qui croit en ce mythe que les librairies dynamiques feraient gagner de la place...
La taille totale du programme avec la librairie dynamique est plus grande, parce qu'il faut aussi compter la taille de la librairie et celle du kernel.

>J'ai déjà compris que ton avis est que c'est un avantage que d'obliger les gens à faire ce que toi, tu trouves bien au lieu de les laisser faire ce qu'eux, ils trouvent bien. C'est totalement stupide et égocentrique comme position. Tu évites encore brillament le sujet. Sache que monsieur "j'aime contraindre les gens a faire du nostub et pas autre chose" que si je ne souhaite pas contraindre l'utilisateur mais qu'il puisse économiser de la place.

Je n'évite pas du tout le sujet. C'est toi qui ne me comprends pas. Il peut économiser de la place avec ExePack, en utilisant ttstart. La différence est qu'il n'est pas obligé d'économiser de la place. S'il trouve les lanceurs personnalisés plus pratiques, il a le droit de les utiliser. Alors qu'avec ta méthode, il est obligé d'utiliser le lanceur unique (PreOs + shrnklib, ce sont 2 fichiers d'ailleurs, et leur taille totale est 3 fois celle de ttstart).

si taper preos() est un contrainte insurmontable dans ce cas la je plaide coupable.

N'oublie pas que PreOs prend plus de 5 KO en archive et plus de 3 KO en RAM.

>Coup bas -> poubelle. Que veut tu que je te dise tu ne va pas affirmer que extraph en l'heure actuelle est plus rapide qe GraphX, Xlib ou genlib a par peut-être dans certains cas très particuliers

Je ne dis pas qu'elle est plus rapide, je dis qu'elle est:
- plus flexible
- plus facile à utiliser
- plus petite, surtout grâce au système de librairies statiques qui ne linke que les fonctions réellement utilisées
- probablement plus stable
- suffisamment rapide pour pratiquement toutes les utilisations pratiques

Nil
a écrit : Windows 3.xx utilise les accès disque de DOS. Il est possible qu'il ait une int propre mais elle utilise directement l'int DOS. Ce n'est qu'à partir de W95 que l'int accès disque est totalement réécrite pour Win (et d'ailleurs c'est beaucoup plus rapide)

Bon d'accord. Il est vrai que Windows 3.xx est assez bâtard comme système. C'est en partie un système d'exploitation et en partie une surcouche pour DOS.

A propos des DLLs de windows : ce sont en réalités des ressources (donc des données accessibles par un autre programme) doublées d'un support permettant d'implanter directement des fonctions dans la librairie (à la différence d'une ressource telle qu'on la rencontre sur AtariST/GEM qui ne contient que des données, le code n'étant que dans le .PRG). Je pense à ce propos que les bibliothèques de fonctions et les bibliotheques de données sont des concepts parfaitement viables, c'est le fait d'avoir utilisé la même extension .DLL pour les deux concepts qui est assez crade.

Sur TI-89/92+/V200, si on travaille proprement, on utilise DLL pour une DLL de code et une autre extension (SAV, DAT, HSC etc.) pour un fichier de données.

Pour un bon programme, il faudrait l'exécutable, une librairie de données (icônes, strings - ce qui permet de faciliter les traductions... - & co)

Pas besoin de mettre les données sous un format de librairie pour cela. Les fichiers .po et .pot (de simples fichiers texte) marchent très bien pour la traduction.

et une librairie de fonctions (ce qui permet de patcher plus facilement un programme pour corriger les bugs).

Non. Dans le meilleur des cas, ça fera toujours un fichier à remplacer comme avant. Dans le pire des cas, il faudra remplacer l'exécutable et les DLLs. C'est vraiment contre-productif comme idée.

Sinon, une petite question toute bête : je pense avoir a peu près saisi les concepts, mais quelqu'un peut-il m'expliquer simplement la différence entre un kernel et un nostub (et si on me dit : yen a un qui a besoin d'un lanceur et l'autre d'un kernel, je le fusille).

Le format _nostub est le format d'exécutables natif de AMS. Le format kernel utilise un format émulé. Une comparaison vague est de comparer le mode kernel à Cygwin et le mode _nostub à MinGW. Mais il y a des différences. Cygwin est nettement plus utile que les kernels sur TI-89/92+/V200, et son format d'exécutables n'est pas aussi non-natif que celui des kernels sur TI-89/92+/V200. Le format kernel est vraiment totalement non-natif. Il n'utilise même pas la table de relogements prévue par AMS, mais laisse cette table vide et en met une autre en un autre format.