Kernel vs Nostub? - Page 12

si gt toi je passerais mon temps à autre chose Kevin ;]

Et tu mets plein de "no" injustifiés au _nostub:
"System Overrides: No, Yes by using TSR" -> donc Yes!
"TI-Basic extensions: No, without a hack." -> C'est possible, donc c'est Yes!
"Auto-uncompress when executing: No (directly), Yes with ttstart or EXE-packed technology" -> donc Yes!
"Comment: No" -> plus pour longtemps. Il y a déjà la spécification préliminaire. Donc encore Yes! "Protection from buggy programs: No" -> Si, il y a le choix entre crashlib (anti-crash en librairie statique), KerNO et PreOs.

Comme je l'ai déjà dit, une notation a partir d'un tableau est une maivaise idée car aucune note ne pourra vraiment représenter la réalité. Mais les commentaire a l'intérieur du tableau sont bons et représentent a peu près tous les avantages et inconvéniants. de chaque méthode.

"Size : 65520 / 8K / 24K" -> 131036 avec une DLL _nostub. Et c'est 65518 la limite pour un fichier, pas 65520.

La c'est vrai mais une DLL Nostub n'est vraiment pas si simple a utiliser qu'une lib dynamique kernel

De plus, pourquoi les programmes _nostub sont limités à 8 KO, alors que les programmes kernel seraient limités à 24 KO ? A ma connaissance, ils souffrent de la même stupide limitation software sur AMS 2.xx (et cette limitation est triviale à contourner...)

C'est un gros avantage du kernel: c'est 64K/64K/64K pour tous les programmes y compris Nostub !

>oui voila je l'avais opublié celui la: HW2TSR,ExtraKeys,Kerno,Autostart voila tout ce qu'il faut pour approcher les fonctionalités du kernel Tu oublies le support du format Kernel

J'avais bien dit approcher, je n'ai pas parlé du format kernel car ca me parraisait tellement evident et de toute façon je connaissait la réponse facile de Kévin: "kernel c'est nul, dépassé"

> cf ce qu'on dit depuis 9 pages : le kernel n'est pas dépassé, puisqu'il évolue encore Ça ne veut pas dire qu'il n'est pas dépassé! Comme j'ai déjà dit: il y a toujours des nostalgiques pour faire évoluer les systèmes totalement dépassés!

Mais rien ne te permet d'affirmer que le kernel est dépassé. C'est une idée bien personelle sans véritable fondement.

Le format de base ne change pas parce qu'il n'a pas besoin de changer. Il est très bien comme il est. Et il y a des évolutions à l'intérieur de ce format de base. Par exemple le format de commentaires et autres données qui est en développement.

Volées sur un format prétendu dépassé mais qui a été bien plus visionnaire vu qu'il les gère depuis des années.

Bon, de 2 choses l'une:
- soit elle ressemble à genlib.
- soit elle est simple d'utilisation. Je ne connais pas suffisamment Allegro pour dire laquelle des 2 solutions est la bonne, mais je connais suffisamment genlib pour pouvoir dire que si elle ressemble à genlib, elle n'est pas simple d'utilisation et vice-versa.

c'est ton avis personnel mais pour moi genlib est très simple

- impossible de lancer un programme sans installation préalable d'un programme tiers.

c'est a mon avis le seul défaut véritable du kernel, mais ce n'est pas si grave que ca

- gaspillage de place en utilisant une surcouche d'émulation par dessus AMS (pour une estimation de la place gaspillée, comparez la taille de PreOs avec celle de KerNO).

Argument qui ne vaut pas le Kernel fait plus que l'anti crash de Kerno. Si tu fait la somme de tout ce que je t'ai cité comme TSR pour s'approcher du format kernel, tu le dépasse.

- complique la vie aux développeurs d'outils de développement à cause de son format difficile à gérer pour le linker.

La j'avoue que je ne connais pas vraiment le problème. Mais d'un autre coté il y a facilite le vie au programmeur

- gaspillage de place pour les routines inutilisées des librairies dynamiques. etc...

gaspillage de place pour les multiples launchers et pour le code réemployé plusieurs fois. On en revient au même.

Si tu trouves nos routines de sprites lentes, tu dois n'avoir jamais essayé BitmapPut.

C'est sur que si on compare BitmapPut c'est difficile de faire pire

MDR.

Mon affirmation est tout a fait juste, c'est un axiome des Ti68K, donc amuse toi a demontrer sons contraire.

PpHd a écrit :
>Mais c'est le format natif standard qu'il faudrait respecter... Je le respecte, sinon ca ne pourrait jamais se lancer.

Tu ne le respectes pas. Déjà, tu n'utilises pas la table de relogements prévue par le format. Et ensuite, tu mets des trucs dans le fichier sans mettre du code pour les gérer, juste un stub pour appeler un TSR (le "kernel"), dans l'espoir qu'il soit installé. S'il ne l'est pas, ça ne marche pas. Ce n'est pas ce que j'appelle "respecter le format natif".

>Je te rappelle qu'AMS n'est pas fait pour la programmation en quoi que ce soit, que ça soit en BASIC ou en ASM... C'est vrai ca.

C'est totalement faux. AMS est conçu pour être programmable!

>D'où mon conseil de laisser tomber genlib et d'utiliser une librairie graphique statique. Plutot fait la fonctionner en mode kernel.

Je ne vois pas l'intérêt d'utiliser le mode kernel juste pour pouvoir utiliser une certaine librairie graphique dynamique, alors qu'il y a des alternatives _nostub en librairie statique.

>Je ne vois pas pourquoi, selon toi, ça serait une bonne idée pour PreOs et pas pour mes TSRs à moi.
Du point de vue utilisateur

Du point de vue utilisateur, il n'y a pas de différence à ce niveau-là. Il s'attend à ce que AutoClBr se lance exactement de la même manière que PreOs parce que les 2 sont des TSRs.

Et comme je prévois déjà qu'on va me critiquer sur ce point-là: La différence entre AutoClBr et PreOs est qu'il n'y a pas de programmes qui ne marchent que si AutoClBr est installé. S'il y en avait, je gueulerais sur ces programmes exactement de la même manière que je gueule sur les programmes en mode kernel.

>Non, tu es passé totalement à côté de mon argument une fois de plus. Tu n'assistes pas du tout l'utilisateur en l'obligeant à utiliser une certaine méthode de lancement! Il vaut beaucoup mieux le laisser faire ce qu'il veut faire, lui. Arg mais avant de le laisser faire ce qu'il veut, il faudrait lui expliquer les choix qui s'offrent a lui.

Les fichiers lisezmoi (readme) sont là pour ça.

>... et si les fonctions réutilisées prennent plus de place que les fonctions inutilisées des librairies dynamiques + l'overhead des importations/exportations + le code de relogement des importations (c'est-à-dire le kernel dans le cas des librairies dynamiques en mode kernel), ce qui n'est presque jamais le cas en pratique (j'ai déjà posté des calculs le montrant à plusieurs reprises). Sauf que c'est souvent faux. Cf cc qui est de 64K en _nostub et moins de 56K en kernel...

CC utilise un nombre excessif de relogements absolus! Il y a beaucoup trop de variables globales partagées entre plusieurs fichiers source. Un programme conçu spécifiquement pour TI-89/92+/V200 n'utilisera jamais autant de relogements.

Et puis, CC n'utilisait aucune librairie dynamique, donc ça n'a aucun rapport avec les librairies dynamiques ou statiques. C'est juste une question de relogements.

>Je te signale que ttstart (et donc aussi les lanceurs personnalisés) n'a besoin d'aucun TSR pour fonctionner! Il parlait des equivalents !

Mais ces "équivalents" ne sont pas nécessaires pour lancer les programmes. On peut s'en passer si on veut économiser sa mémoire, ce qui n'est pas le cas du kernel.

>Un programme _nostub qui n'est pas un TSR et qui n'utilise pas NG_execute (on peut lancer les programmes en assembleur/C directement à la place) n'a pas besoin de HW2Patch ni de h220xTSR. Et s'il connait les trucs et astuces a utiliser...

1. C'est tout bête. Il suffit de mettre #define EXECUTE_IN_GHOST_SPACE.
2. Cette "astuce" n'est nécessaire que si on programme un shell ou un programme de ce style. Pour tous les autres programmes (jeux, programmes mathématiques, ...), on n'a besoin d'aucune "astuce".

>Mais ça prend encore plus de place! genlib en prend déjà trop toute seule! Compressee, elle ne prend pas tant de place.

Tu appelles 9 KO "pas tant de place"? Voilà ce que me dit shrink92.exe, appelé par kpack.exe:
19143 bytes in 1 file compressed to 9051 bytes
D'ailleurs, avec ttstart, ça ne prendrait que 8481 octets. Mais ce sont quand-même plus de 8 KO, même après compression.

>Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib. Tu veux montrer quoi en affirmant cela ?

Je répondais à Uther qui avait dit:

-plus facile a utiliser: faux et même tout le contraire, genlib a pas mal de fonctions qui facilitent la vie et si tu es incapable de faire fonctionner cette lib, tu es incapable de faire un jeu qui requière plus que TIGCCLIB.

ce qui est faux, comme le montre ce que j'ai répondu et que tu as cité.

>ExtGraph est déjà "plus que TIGCCLIB". Et puis, je ne sais pas ce que vous avez tous contre les fonctions de sprites de TIGCCLIB. Elles marchent très bien. Oui. BitmapPut aussi.

Les routines de sprites de TIGCCLIB ne sont pas si lentes que ça.

>Même PpHd avoue (cf. #258) que des bogues ont été trouvés dans genlib à plusieurs reprises. Avec ExtGraph, il n'y a aucun problème. On ne peut raisonnablement pas comparer les degres de complexite des deux librairies.

En effet, genlib est trop complexe. C'est une erreur de conception. Ça n'apporte rien, ça la rend juste plus grosse, moins flexible, plus difficile à utiliser et, comme tu viens de le dire toi-même, augmente le risque de bogues.

Et les bugs sont souvent mineurs.

Ceux de ExtGraph l'étaient aussi.

>Mais ça ne sert à rien [d'être plus rapide que ExtGraph]. Pour toi oui. Pour certains non.

J'avais dit cela de manière totalement objective. Ça ne sert à rien parce que au moins 95% des jeux sur TI-89/92+/V200 n'ont aucune difficulté à atteindre les 10 fps nécessaires pour obtenir la fluidité. ExtGraph est suffisamment rapide.

>Je n'appelle pas ça "vouloir contraindre le programmeur", mais lui dire de programmer proprement. Je ne vois pas du tout l'intérêt d'abuser d'un ASM pour mettre des données. Et alors ?

Et alors, si ça n'a aucun intérêt et que c'est un abus du format, on ne le fait pas.

>Il est impossible de concevoir une DLL qui en même temps:
>- contient toutes les fonctions qui pourraient être utiles à un programme.
>- ne contient que les fonctions utilisées par tous les programmes.
Si c'est possible
Une Pack-Archive contenant une centaine de sous-DLL

Alors bonjour:
- le gaspillage de taille par le système de packs archive. Surtout les noms des DLLs dans le pack archive et dans la table d'importation du programme.
- le temps d'extraction. Même si les DLLs ne sont pas compressées, il faut quand-même allouer pas mal de blocs et copier pas mal de données.
- le temps de relogement
- le b*rdel que ça va être pour le programmeur (ou pour l'utilisateur) de choisir les bonnes DLLs parmi la centaine disponible pour son pack archive, alors que pour les librairies statiques, le linker s'occupe de cela pour lui.
Donc c'est une très mauvaise idée (en plus d'être un hack ). Les librairies statiques résolvent ce problème de manière plus propre et beaucoup plus efficace.

<Ce n'est pas un problème de conception de la DLL, mais une erreur de conception dans l'idée-même des DLLs. Cf au dessus.

Idem.

>- faciliter l'implémentation et l'utilisation (pas besoin d'associer un handle aux DLLs s'il n'y en a qu'une seule à la fois) Bof. On aurait pu faire de meme avec plusieurs.

Comment veux-tu pouvoir choisir la DLL à laquelle appartient la fonction que tu veux appeler si tu charges plusieurs DLLs en même temps et que tu ne les numérotes pas?

>- limiter les abus (Je répète que ce système est là uniquement pour permettre de créer des programmes de plus de 64 KO!) Un hack est facile.

Pas tant que ça. Tout le monde ne s'appelle pas PpHd.

>Et en tout cas, TI n'a aucun intérêt à empêcher à vcbprintf de fonctionner, et c'est aussi appuyé par le fait que, pour l'instant, aucune mise à jour de AMS n'a causé des problèmes avec vcbprintf. sprintf n'a pas du tout changé entre AMS 1.00 et 2.08. Oué, mais justement, c'est parce que le fichier 'printf.c' n'a JAMAIS ete recompile. S'il le recompilait (rien que par le fait qu'ils vont changer leurs flags de compilation), la methode actuelle serait invalide.

Je ne pense pas.

>Il y a de bonnes chances que je serai toujours membre de l'équipe de TIGCC. Moi y'a de bonnes chances que je disparaisse.

Donc plus de kernel en développement?
Dans ce cas, il suffira que TI sorte une mise à jour qui empêche à PreOs et Universal OS de fonctionner, et hop, plus de mode kernel. Et donc les programmeurs en mode kernel, auxquels on a promis (à tord) qu'ils ne devront "jamais" recompiler leurs programmes, seront tous obligés à les recompiler... en mode _nostub.

>BitmapPut de AMS est clippé! À ton avis, il sert à quoi, le paramètre SCR_RECT *clip
A clipper. Pas eu le temps de mettre le clipping. Si quelqu'un est interresse

>Parce que Windows est la plateforme la plus connue qui les utilise, et parce que sous *nix, le terme "so" (shared object) ou "shared library" est habituellement utilisé à la place. Évidemment, on n'utilise pas ce dernier terme pour les DLLs de TIGCCLIB parce qu'elles ne sont pas prévues pour être partagées!
Et les DLL windows ne sont pas prevus pour etre partages aussi Vous auriez mieux fait de mettre 'EASM' comme extension Extended Assembly file.

Mais "Extended Assembly file" ne veut rien dire. Contrairement à toi, nous n'aimons pas les néologismes.
À la limite on aurait pu les appeler "external code files", mais ça fait quand-même tordu.

>Mais un appel de fonction est quand-même une ligne logique. C'est un concept certifie ?

"Certifié" par qui?

>Ben, évidemment, si tu abuses des sprites pour remplir l'écran entier, il est normal que ce soit lent.
Tu dois pas beaucoup aimer les shoots toi

Phoenix est aussi un "shoot-em-up" et il affiche beaucoup moins de sprites. Et Alien Invasion en est aussi un et en affiche encore moins.

>C'est plus rapide que de tout réafficher à chaque fois. Faux.

Pourquoi? Il y a juste une rangée à redessiner plutôt que l'écran entier, et je pense bien que le scrolling lui-même soit plus rapide que de réafficher l'écran entier, vu qu'il y a beaucoup moins de calculs à faire.

>Si vraiment tu veux du scrolling différentiel, tu peux le faire très facilement toi-même. De toute façon, genlib (et XLib aussi, il me semble) se contente de tout réafficher à chaque fois. Certes, mais les routines de genlib sont optimises pour.

Ça ne veut rien dire. Évidemment qu'une routine d'affichage est optimisée pour l'affichage. Que tu affiches l'écran entier ou juste ce qui a changé n'a aucune importance pour la routine d'affichage: dans les 2 cas, tu affiches.

>Si tu fais la même chose, le scrolling différentiel devient trivial. moins que dans genlib.

Non. Dans les 2 cas, il y a juste une paire de coordonnées par plan à changer. C'est exactement la même chose.

>Et sinon, avec ExtGraph, tu peux aussi faire quelque chose comme ça (je mets en blanc/noir pour éviter de tout recopier 2 fois, mais c'est la même chose en niveaux de gris):
Ton code est nul

Pourquoi? Je ne fais qu'appliquer la définition du scrolling différentiel.

>Ben, si tu recherches les effets spéciaux, ne viens pas râler que c'est lent. La TI-89/92+/V200 n'est pas du tout une plateforme adaptée pour des jeux avec des graphismes impressionnants.
Ah bon

>Et de toute façon, ces effets graphiques ne changent rien à la jouabilité.
Joue a Quake3 en mode flat alors

Évidemment que si le jeu est conçu pour ne marcher correctement qu'avec le maximum d'effets graphiques, on ne verra pas grand chose si on les désactive. Mais c'est un problème de conception. Surtout celle des graphismes: il faut faire en sorte qu'elles soient clairement visibles même sans effets graphiques. Malheureusement, c'est souvent négligé par les développeurs de jeux commerciaux. Mais ça ne concerne pas du tout les jeux pour TI-89/92+/V200.

>C'est bien ce que je dis: tu abuses d'effets graphiques. Phoenix ne lance jamais plus de 4 missiles à la fois et pourtant c'est tout à fait jouable.
Phoenix affiche beaucoup de vaisseaux et de missiles a la fois

Évidemment, parce qu'il y a plein d'ennemis. Mais squale92 affiche 96 missiles sans compter ceux des ennemis!

>Ça n'apporte pas grand chose en fonctionnalités par rapport à KerNO qui fait la moitié de la taille. L'anticrash est meilleur.

Peut-être, mais la différence de taille ne vient pas de là.

>Traduction: sauf pour les jeux qui abusent d'effets graphiques. Et ben, la solution est simple: il suffit arrêter d'abuser d'effets graphiques! il en est hors de questions !

Ben, si on est tellement borné, on ne doit pas s'étonner que son jeu soit lent!

>>Avec les kernels on aurrait sans doute quelque problèmes mais on devrait pouvoir arriver a quelquechose d'executable a défault de marcher parfaitement.
>J'en doûte, si la matrice clavier et la résolution de l'écran ont complètement changé. File moi un exemple precis et je chercherais un moyen.

Aucun intérêt. TI réussira certainement à détruire les choses beaucoup plus que ce que je pourrais imaginer.

>De la même manière que le kernel: en recompilant, et en adaptant les sources au besoin pour gérer la nouvelle taille d'écran. Les programmes pour kernel devront faire exactement la même chose pour fonctionner. Le kernel ne peut rien faire pour résoudre ce problème-là. Comment veux-tu que le kernel change toutes les références à la matrice clavier? Et la taille de l'écran? Beaucoup de programmes nécessiteraient même un changement des sources pour gérer un écran de taille différente, et le kernel n'y change strictement rien. Et c'est exactement ce que j'ai voulu montrer par cet exemple.
Faux le kernel mettrait en place une surcouche emulation de l'ancien hardware. Le seul truc c'est de faire une traduction temps reel de la matrice clavier (Ca roulerait bien).

Comment ça? En changeant le code du programme? On peut faire la même chose en _nostub.

Pour l'ecran, une int qui s'occupe de la traduction fera l'affaire.

Comme la taille horizontale a diminué dans mon exemple, ça ne donnera rien de lisible.
Et puis, on peut faire exactement la même chose en _nostub.

Encore mieux : si le programme fonctionne avec genlib, une adaptation complete de genlib permettrait de s'en sortir facilement (sans a avoir a recompiler tous les autres programmes). Vive genlib

Et la taille de l'écran???

>Et c'est tout à fait normal qu'on compare, vu que c'est exactement le même concept. Non. Toi c'est une Extended Assembly File.

1. Comme dit plus haut, "Extended Assembly File" ne veut rien dire.
2. Je parlais de la comparaison DLL Windows / DLL kernel, pas des DLLs _nostub.

>Je ne vois pas du tout ce que Krypton gagnerait à être en kernel. Au contraire, il perdrait la compatibilité avec les calculatrices sans kernel. Il est gros. Il gagnerait en place en kernel.

Probablement non. Et je parie que tu as encore oublié de compter la taille du kernel.

>Pourquoi c'est dommage? Les DLLs partagées sont un concept défectueux depuis le départ. Elles ont beaucoup de désavantages pour pas ou presque pas d'avantages. TIGCC supporte parfaitement les librairies statiques, qui sont beaucoup plus adaptées pour le partage de code. Et lorsqu'on a plusieurs libs statiques de versions differentes entre elles incompatibles entre elles et que chaque programme necessite une version differente ?

Il n'y a aucun problème justement. Chaque programme utilise la version pour laquelle il est prévu. Il n'y a aucun conflit! Alors qu'avec les librairies dynamiques, ça serait le chaos parfait.

>Strictement rien.
>Reste en _nostub, c'est mieux.
Taille, mon respect. Ca tournerait sur ma calc

Arrête de boycotter le _nostub! Il n'y a pas de raison!

>Je ne vois vraiment pas pourquoi. Déjà, WinZIP (et WinRAR et WinACE) le décompressent sans problèmes. Et puis, untbz2 fait 23 KO. WinZIP fait nettement plus que ça. Certes dont moi, ont des vieilles versions de WinZip et ont pas envie de mettre a jour.

Mais untbz2 fait 23 KO. C'est téléchargé en moins de 10 secondes.

>On ne sait jamais. Le débâcle de EX_patch et de ttstart ne te dit-il rien? C'est une erreur (ça n'a d'ailleurs aucun rapport avec le fait que ttstart soit en _nostub, c'était tout simplement un bogue; le mode kernel n'y aurait changé strictement rien) qui a été mise en relief par une simple mise à jour de AMS. Mes macros ne fonctionnent qu'en mode algortihmique pur. Aucun appel de fonction AMS, ni de references materielles.

Si, il y a une référence matérielle: le code 68k.

>"Programmer en ASM" et "utiliser tigcc.a" ne sont pas incompatibles
Mais programmer en ASM peut faire utiliser les romcalls directement

Ça peut, mais ça n'y oblige pas.

>Ce n'est pas une solution au problème. Si, c'est une solution.

>Avec une librairie statique, on pourrait économiser la mémoire utilisée par ces fonctions au lieu de les utiliser "juste parce qu'elles y sont". Mais elles y sont ! Donc autant les utiliser.

N'importe quoi. Ton attitude "si les fonctions sont inutilisées, le programmeur n'a qu'à les utiliser" est arrogante et stupide. Si les fonctions ne lui servent pas, pourquoi devrait-il les utiliser juste pour qu'elles soient utilisées? Et tout ceci alors que la solution au problème est très simple: utiliser une librairie statique, comme ça, quand le programmeur n'utilise pas certaines fonctions, l'espace mémoire sera économisé. Ton "Mais elles y sont !" est exactement le problème, auquel tu n'as pas donné de solution parce qu'il n'y en a pas en restant dans le domaine des librairies dynamiques.

>En effet, pour la place, ça se discute. Les patches d'adresses prennent sans doûte pas mal de place.
Sauf que parfois on a aussi besoin de plus de 16 registres en meme temps. Le SMC permet de resoudre cela.

De manière complexe et pas très propre. Et puis, il faut apprendre à te passer de patches d'adresses à niveau global si tu veux pouvoir faire des librairies statiques efficaces. Ce n'est pas si dur que ça! Tu as bien réussi à te passer de code auto-modifiant dans PedRom!

>Et le risque d'erreurs est aussi beaucoup plus faible en utilisant un registre qu'en patchant des adresses de partout. Et puis, il est plus propre d'utiliser un registre pour ça. Pas tant que ca. Les erreurs surviennent en general tres vite. Si ca passe une fois, ca passera les autres.

À condition de tester à chaque fois toutes les routines que tu patches!

>Par paresse? Ça ne prend pas tellement d'octets/cycles si on le fait correctement. Non. Mais j'aime garder un max de registres pour mes routines.

En d'autres mots, tu es trop paresseux pour faire de l'allocation de registres. Dans ce cas, utilise un compilateur, il s'occupera de ça pour toi.

>Bon, je le ferai ce weekend si j'aurai le temps.
Rappel de francais (Juste histoire que tu te plantes pas dans un exam) :
"je le ferai ce weekend si j'<AI> le temps. "
Futur + SI + present. Desole

Oups...
Je ne pense pas que j'aurai encore un examen de français (du moins pas dans le futur proche), mais tu fais quand-même bien de me corriger.

>Mais j'ai l'impression que tu fais exprès de ne pas donner de suggestions pour KerNO parce que c'est un "concurrent".
C'est plutot que j'ai pas le temps
Et puis il a du y penser de lui meme non ? C'est trivial a penser. Il a du choisir DlgMsg pour certaines raisons.

Parce que c'est plus beau probablement.

>Ce qui alourdit le tout. Tu aurais dû intégrer ttunpack_decompress à PreOs, comme ça pas besoin de librairie de décompression, et un taux de compression meilleur. Ca n'alourdit pas vraiment. Le code utilise reellement le potentiel du kernel.

Mais ce n'est pas du tout dans ton esprit "le kernel gère tout", ce n'est pas pratique, et shrnklib compresse nettement moins bien que ttpack (cf. aussi l'exemple de genlib plus haut).

Et tu peux parfaitement utiliser ttunpack

En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça.

>Mais DOS est dépassé et difficile à utiliser.
Difficile
Et il manque un autoexec.bat a ASM plutot

AMS, pas ASM!!!
Et puis: exécution automatique au démarrage = possibilité d'avoir un plantage dès le démarrage...

>Non. Je répète qu'on s'attend à ce que le programme marche sans avoir lancé quoi que ce soit avant. Pas moi.

Parce que tu sais ce qu'est un kernel pour TI-89/92+/V200 etc. Mais quelqu'un qui ne connaît pas les particularités de la plateforme (et des abus de la plateforme; je considère le système de kernels comme un abus parce qu'il essaye de créer une autre plateforme par dessus), le fait de devoir installer un TSR avant de pouvoir lancer certains programmes est totalement inattendu.

Pen^2
a écrit : si gt toi je passerais mon temps à autre chose Kevin ;]

Kevin a le doit de se détendre de temps en temps
En tout cas c'est très interessant à lire (et je suis sincère : j'ai tout lu jusque là)

PpHd a écrit :
>GCC est assez lourd en effet, mais y a-t'il des compilateurs légers avec des fonctionnalités comparables? Il ne me semble pas. GTC est largement suffisant a mon avis.

GTC n'existe pas encore, et d'après ce qui a été dit, ses fonctionnalités ne seront pas tout à fait comparables à celles de GCC. Parle à Pollux de certaines techniques d'optimisation de GCC et il ne saura même pas ce que c'est... Cf. topics/18721-pile-et-allocation-memoire/3#80.

Surtout si on veut faire du code portable d'un compilo a un autre.

Ce qui n'est pas vraiment le cas pour les programmes pour TI-89/92+/V200 normalement.

>Évidemment, si on retire toutes les fonctionnalités intéressantes de AMS, on a la place. C'est surtout qu'AMS n'est pas optimise en taille. En moins de 64K, 350 fonctions d'AMS. Tu trouves ca normal ?

Pas vraiment. Mais il faut dire que tes fonctions n'ont pas toujours la fonctionnalité complète de celles de AMS.

>Il y a aussi des défauts objectifs indéniables. Cf. le premier paragraphe de réponse de ce message.
[Je remets le paragraphe en question:
Je répète ce que j'ai déjà répondu à Uther Lightbringer:
Il est impossible de concevoir une DLL qui en même temps:
- contient toutes les fonctions qui pourraient être utiles à un programme.
- ne contient que les fonctions utilisées par tous les programmes.
Ce n'est pas un problème de conception de la DLL, mais une erreur de conception dans l'idée-même des DLLs.] C'est corrigeable.

Faux. Ou alors il faudra que tu m'expliques comment tu veux faire. Et ne me ressors pas la blague des packs archive avec une DLL par fonction, j'ai déjà montré que ça ne tient pas du tout la route.

>Parce qu'un linker normal identifie une fonction par son nom. D'ailleurs, tu es obligé de passer par des #defines ou des equates pour associer les noms à des numéros. Tout OS identifie ces fonctions internes par des numeros, pas par des noms.

AMS oui. Windows par exemple, non.

Tu peux utiliser directement sous la forme malib__0000(); C'est lisible.

Tout le monde ne connaît pas par cœur les numéros de la centaine de fonctions de genlib. Je pense d'ailleurs que même toi, tu ne les connais pas par cœur.

>Pour un système de librairies qui identifie les fonctions par leur nom (le système de librairies statiques de TIGCC par exemple), on n'en a pas besoin. C'est une tres mauvaise idee a mon avis.

Et pourquoi?

>Tu n'es pas souvent passé sur le forum de la TICT Si. Mais je ne vois pas beaucoup de debat en parlant.

Parce que chez nous, la discussion n'est plus entre _nostub et kernel, mais entre _nostub et FlashApps.

>et sur celui de TI apparemment.
Jamais.

>Il y a pas mal de gens qui disent que les kernels sont complètement obsolètes là-bas. Ils disent des conneries c'est tout.

Non, les kernels sont considérés dépassés presque unanimement partout sauf sur ce forum.

>Je pense que tu te trompes là. C'est mon droit.

>Ben, les bogues qui empêchent aux jeux en question de s'appeler "version 1.00". Ben ces jeux sont concus pour etre beaus, riches et complexes. Donc ca prend du temps, surtout si on fait autre chose par ailleurs.

Il n'y a pas que les jeux genlib à être "concus pour etre beaus, riches et complexes", et pourtant les autres ont bien réussi à sortir des versions 1.00 (TI-Chess, Duke68k, ...).

>Tu n'as pas dû bien écouter quand le sujet revenait régulièrement. Si mais j'ai corrige.

LOL, on parle mal de ta librairie, donc tu essayes de censurer ("corriger"). Alors que les problèmes cités sont réels.

>Et ce n'étaient pas seulement les utilisateurs finaux (end-users) à s'en plaindre,
Qui ?

>mais aussi certains programmeurs utilisant genlib. Dark Angel par exemple. La c'etait le probleme de la detection de Vti. Un faux probleme.

Ce n'était pas le seul problème qu'il avait. Il y avait pas mal de bogues. Il a toujours fallu avoir la dernière version de genlib pour chaque version de Total Destruction.

>Je m'en fiche de la spécification.

>La spécification de AMS interdit les programmes en RAM >24 KO et les TSRs en RAM, et
>pourtant tout le monde s'en fout. L'important est que ça marche. Si tu me trouves un patche viable.

Corollaire: Le futur du mode kernel dépend de la bonne volonté de quelqu'un qui est contre les kernels (moi). Heureusement pour toi que j'ai aussi mes propres TSRs à faire marcher.

>Bon, voilà 2 exemples (je ne mets pas le code concret, parce que ça serait long et n'apporterait rien de plus que la description en mots):
- remplacer un buffer statique (pour une fonction de style sprintf) par un buffer alloué, plus grand, quand c'est nécessaire
- traverser une table dans un programme en modifiant l'adresse à lire à chaque fois
Évidemment, il y a aussi d'autres manières, plus propres, de coder ça, mais les exemples sont quand-même utiles et cohérents.
Tes deux exemples fonctionnent aussi en kernel. Suffit de faire l'init soit meme, ce qui est quand meme bien plus propre.

Mais tu ne peux pas faire une API de librairie statique de style:
SetBuffer(void *buffer);
If you call this function, then function xyz will write into the specified buffer. If you don't, it will use its own static buffer.

>Tu importes le code pour EXECUTE_IN_GHOST_SPACE (un seul xdef), et tu fais:
> move.w %d0,-(%a7)
> move.l HeapDeref*4(%a5),%a0
> jsr (%a0)
> addq.l #2,%a7
> adda.l #0x40000,%a0
> jsr (%a0)
> nop;nop;nop |pour RETURN_VALUE
> C'est tout bête.
Et tu obtiendras une belle barre noire en haut
Sur HW1 et sur HW2

J'ai déjà répondu, mais:
1. Oups, en plus du problème avec les programmes archivés (cf. 2.), j'aurais aussi dû mettre HLock, pas HeapDeref.
2. Quand j'en suis déjà au handle, je m'attends à ce que tout le travail sur les HSym et SYM_ENTRY ait déjà été fait, et EM_twinSymFromExtMem en fait partie. Quelle idée que de passer un bloc archivé à une fonction d'exécution! kernel::exec ne devrait pas accepter cela (je sais, c'est trop tard pour changer etc., pas la peine de me dire ça). La méthode propre est d'appeler EM_twinSymFromExtMem avant d'essayer d'obtenir le handle.

>Montre-moi des saletés dans les programmes TICT alors. Le patch pour faire communiquer tictex / tictexpl

Ce n'est pas sale. Même Thomas ne dit pas que c'est "dirty", et pourtant ce que Thomas appelle "sale" est toujours nettement plus propre que ce que toi, tu appelles "propre".

>Pourquoi? Le code de démarrage de TIGCC est prévu pour fonctionner indépendemment de ce que fait le programme principal. Mais un patch peut devoir faire autre chose.

Mais je parlais de patches pour rajouter du code de démarrage. SET_FILE_IN_USE_BIT et tous les autres exemples que j'ai cités, c'est du code de démarrage.

>C'est trop tard. Il y a déjà des programmes qui les utilisent (de la manière prévue). Duke68k et CalcRogue par exemple. On se demande comment ils font. Moi meme en y mettant du mien, j'ai du mal a remplir 64K de code pur.

Donc tes jeux ne sont pas si complexes que tu prétends.

>Bon, on remplace "100%" par "99%".
Ok.

>Mais il est très improbable que les versions futures de AMS exporteront moins de fonctions.
>Ce n'est pas du tout dans la logique de TI.
>Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas. Hum. Tu te contredis. "Ils en ont retires".

Bon, je répète en accentuant la locution importante: "Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas."

>Ils ont quand-même un minimum de souci de compatibilité, même si on les accuse souvent du
>contraire. Ah. Ou ca ? Certains ingenieur peut etre.

Ben, s'ils n'en avaient rien à battre de la compatibilité, au moment de la sortie du SDK, ils auraient refait toute la table des sauts pour supprimer toutes les fonctions qui ne sont pas documentées dans le SDK et renuméroter toutes les autres.

>Ah, je vois (c'est dans le ZIP de Pedrom que tu m'as envoyé pour le problème avec A68k ). Il y a pas mal de trucs qui pourraient nous intéresser (pour la documentation de TIGCC) dans ton Note.txt.
C'est fait pour

Mais il faudra que quelqu'un (probablement moi, ou peut-être Lionel) traduise tout ça du Français raccourci à l'Anglais complet.

>Mais il y a certainement un moyen de définir un menu CUSTOM en C.
push_parse_text("custom:text ....");
HS_popESTACK / NG_execute me semble le meilleur moyen.

push_parse_text, c'est lent, et le code en format texte est lourd. Il vaut mieux prétokéniser la chaîne. Mais évidemment, ça rend le tout plus compliqué à coder. (Enfin, pour la plupart des gens. Pour moi, c'est tout bête. J'ai travaillé pas mal sur le format tokénisé.)

>Plus simple? C'est plus simple de lancer un NG_execute avec des tags qu'un simple cmd_custmon??? Tu connais le format ?

>C'est certainement plus lent! NG_execute doit interpréter les tokens, puis exécuter le bon cmd_.... Il est certainement plus rapide d'appeler cmd_... directement. A condition de connaitre le format !

Le format de quoi?

>Et alors? prions pour qu'ils ne recompilent pas printf.c

Ou que l'offset ne change pas. Il n'y a que 8 instructions devant celle qui nous intéresse, et elles ont toutes peu de chances de changer à moins que TI ne se mette à utiliser l'équivalent de -fomit-frame-pointer.

>Certes. Mais je parlais de ce que ça apporterait comme fonctionnalité à un programme, pas ce que ça apporterait pour une librairie standard pour faciliter les portages. Tu l'as dit toi meme: faciliter les portages.

As-tu vraiment lu ce que j'ai dit??? "Mais je parlais de ce que ça apporterait comme fonctionnalité à un programme, pas ce que ça apporterait pour une librairie standard pour faciliter les portages."

>TI-Connect n'est pas juste une surcouche du logiciel GraphLink. Par exemple, il supporte les câbles USB, ce qui n'est pas le cas du logiciel GraphLink. J'ai essaye. Je n'ai vu qu'une surcouche de graphlink.

D'après ce que j'ai entendu dire (je n'ai pas encore essayé TI-Connect), tu ne peux pas "voir" les fonctions importantes de l'interface de TI-Connect, c'est du drag&drop pur.

Faudrait essayer ces chaines la.

En effet.

>1. Je me demande bien comment tu veux faire cet "émulateur". Il faudra changer le code du programme de partout, et pour l'écran, les changements ne sont pas automatisables à mon avis. Cf au dessus.

J'ai déjà répondu en haut. Une interruption pour "émuler" l'écran n'est pas une solution convenable si une des 2 dimensions a diminué.

>Nos #defines de compat.h sont tout aussi faciles à changer. De même si le programme lui-même utilise la même technique (#define CONST1 (TI89?1:2)). Plus lourd. Plus lent.

Pas au point où ça serait un problème réel.

>2. Cet "émulateur" marcherait exactement de la même manière en _nostub.
Pas de maniere automatique ni transparente

Il suffit de le mettre dans ttstart. Puis on recompile un nouveau lanceur personnalisé à partir de la mise à jour de ttstart et c'est bon.

>Tu utilises quoi alors? Notepad???
>TIGCC IDE est très pratique, même si tu programmes en assembleur! Ultra Edit pour tout et n'importe quoi (C, HTML, JAVA, ASM, C++, ..) avec pleins de compilos differents.

Ah, OK.
Mais les IDEs ont un grand avantage: ils gèrent les projets. Donc ils permettent de chercher et remplacer dans un projet entier, par exemple.

>Moi, j'aime bien, c'est la syntaxe GNU. Crois moi, on arrive très bien à s'y habituer.
C'est plus lourd. Ca obblige a taper un caractere sup par registre. Bref on voit bien qu'ils programment pas en asm.

Bah, j'ai codé *scanf (source de 11 KO, routine de 1 KO) en assembleur GNU et je n'ai pas trouvé ça si lourd que ça.

>Mais BitmapPut de AMS l'est! Et c'était ça, le contexte. Je ne vois pas du tout ce que vient y faire ExtGraph (à part que tu as recopié le code de ExtGraph pour implémenter BitmapPut ).
Parce que justement je l'ai prise de la

Hehe, vive ExtGraph.

>C'est justement ça ton erreur, à mon avis. Tu veux donc un exemple ou c'est impossible de faire autrement ?

Si tu en as un, poste-le.

>Tu peux essayer de les envoyer à XDanger. Il peut aussi faire des mises à jour des logiciels TICT si c'est vraiment important.
Ce n'etait pas important. Quelques details. Et puis ca l'obblige a refaire appel aux traducteurs

Il ne faut pas être surpris que Thomas ne soit pas très pressé pour mettre tes mises à jour si:
1. Ce n'est pas important.
2. Des chaînes susceptibles de traduction ont changé.

>Je ne vois pas en quoi ma solution (rajouter un nouveau RAM_CALL pour font_medium,
>changer font_small et font_large, et garder _RAM_CALL_00E pour les fontes du boot)
>causerait des problèmes de compatibilité. Mais bon, tu fais ce que tu veux, de toute façon,
> je n'utilise aucun de ces RAM_CALLs. (Vive le _nostub! )
Parce que certains programmes les utilisent deja

Est-il si grave que les 3 ou 4 programmes (je ne pense pas qu'il y en ait plus que ça) qui utilisent les 3 RAM_CALLs maintenant reçoivent un mélange de fontes du boot et de fontes de la ROM?

>Ce que je dis est que le fait qu'il y a une mise à jour qui accélère les routines de prévue n'est pas une excuse valable pour ne pas créer une version statique. Ce n'est en rien une excuse. C'est une fonctionnalite supplementaire.

C'est une fonctionnalité en moins (le linkage statique), pas une fonctionnalité supplémentaire.

>Si le programmeur a vraiment besoin de la vitesse supplémentaire apportée par la mise à jour, il recompilera/réassemblera/relinkera quand la librairie est mise à jour. Je n'ai pas du tout mis en question le fait que tu n'as pas le temps de sortir la mise à jour tout de suite. Pourquoi n'en aurait-il pas besoin puisque dans le contexe ou elle doit etre utiliser y'a la notion de vitesse.

Pourquoi en aurait-il besoin puisque, vu qu'il utilise la version actuelle, le programme doit forcément être adapté à la vitesse de la version actuelle?

> Parle à Pollux de certaines techniques d'optimisation de GCC et il ne saura même pas ce que c'est...
Ce n'est pas parcequ'il ne connait pas les termes qu'il n'a pas eu l'idée d'intégrer les optimisations qu'ils désignent
J'ai bien codé un algo d'extraction de racines carrées sans savoir que ça s'appelait une recherche dichotomique, par exemple.
C'est bien beau d'avoir de la culture (informatique), Kevin, mais je trouve que c'est bien mieux d'être capable de construire des algos.

>C'est bien beau d'avoir de la culture (informatique), Kevin, mais je trouve que c'est bien mieux d'être capable de construire des algos
oui, mais tu ne peux pas reinventer tout ce que des gens tres competents on passé leur vie à decouvrir
y'a un moment faut etre realiste.

le truc, c d'apprendre/comprendre ce qui a deja ete fait, et ensuite d'aller plus loin.

Bien sûr !!! J'ai pas dit le contraire. Par "culture", j'entendais "vocabulaire". Je m'exprime mal.
Ce que j'ai voulu démontrer, c'est que Pollux a très bien pu ajouter des optimisations à son compilo sans connaître leur nom !

oui, oui.
de toutes façons c un boss Pollux

PpHd a écrit :
>TI-89/92+/V200.
>Les jeux avec FAT Engine ou d'autres techniques 3D tournent souvent autour des 10 FPS. Les jeux en 2D ont des framerates nettement plus élevés. Ils sont plus interressants aussi.

>À peine, mais quand-même. Restons raissonnable. On est pas a 3% pres.

Ah tiens, tout d'un coup. Sur un jeu de 33 KO ou plus, les routines de niveaux de gris font 3% ou moins. Donc si tu n'es pas à 3% près, arrête de te plaindre du fait qu'ils utilisent les routines de niveaux de gris en librairie statique.

>Le contexte, c'était des conseils à Uther Lightbringer pour comment il peut se passer des librairies qui nécessitent USE_KERNEL. J'ai donc dit qu'en appliquant ces conseils, USE_KERNEL n'est plus nécessaire. Toi, tu as prétendu le contraire. J'aimerais bien que tu m'expliques ton raisonnement...
De toute facon, avec toi, USE_KERNEL n'est jamais necessaire alors

>Il faudra m'expliquer pourquoi ça rame alors...
Ils sont doues les gars de chez Origin. Mais doue Ils affichent come un bouef tous les sprites de la map, quelque soit ta position. Je ne vois que ca comme explication.

>Ben, je te signale que pour le scrolling de ExtGraph, il est très facile de comprendre comment il marche. Le système de plans est plus compliqué. Oui. Mais tellement plus simple une fois assimile.

Pas sûr.

Et plus rapide.

Pourquoi? Il y a plus de calculs à faire que pour un simple scrolling...

>Ben, alors, il suffit d'expliquer dans le lisezmoi comment on utilise ttstart. Ou mettre un message d'explication dans le programme _nostub juste avant l'extraction du PPG.

Quelle idée stupide!
Crois-tu vraiment qu'un nag screen de style shareware au début de chaque programme juste pour parler de ttstart à l'utilisateur soit une idée intelligente?
Et en plus, ton message gaspillerait pas mal de place.

>Non, parce que leur affichage n'a pas besoin de 100 ms tout simplement. Et cela indépendemment de la librairie graphique utilisée. mais si ! Essaye de faire tourner Cf/SMA sous Extgraph alors !

Je n'ai pas le temps d'essayer, mais je pense bien que CF ou SMA pourraient très bien fonctionner avec ExtGraph.

Et SMA est trop rapide de toute façon.

>Quelle 3D? 3D isométrique? Dans ce cas, ce n'est pas vraiment de la 3D (ce sont juste des sprites avec un masque non-rectangulaire), et c'est normal que ça ne rame pas.
3D face pleine En surcouche des maps (2 planes), et des sprites (30 spr 32x32 a l'ecran), plus les fenetres.

Ah bon.
Mais ce n'est qu'un objet, n'est-ce pas? Entre un seul objet 3D et un monde 3D entier, il y a quand-même une différence évidente.

>Parce que les fonctionnalités ne sont pas identiques. On peut lancer le programme de manière plus directe avec le lanceur personnalisé. Mais le format des Pack Archive permet de le lancer directement justement !

Non, il faut installer un kernel, donc on ne peut pas les lancer directement.

>D'ailleurs, il y a aussi AutoStart comme troisième solution. Ça permet de combiner lanceur commun et lancement direct. Le désavantage est qu'il y a un TSR à installer.
C'est à l'utilisateur de choisir entre les 3 méthodes, pas au programmeur. Mais si !

Mais non! C'est quoi cette arrogance de vouloir toujours imposer son choix à l'utilisateur?

>En quoi est-ce un problème? Les fonctions de gray.h sont simples à utiliser et efficace, donc pourquoi dupliquer l'effort en en mettant d'autres dans ExtGraph? D'autant plus que c'est Thomas qui a écrit les routines de TIGCCLIB. Il ne va pas faire de la concurrence à ses propres routines! Ce n'est pas un probleme pour Extgraph, mais tu dois en tenir compte lorsque tu compares avec d'autres libs.

Il reste quand-même cet argument-là: "Les fonctions de gray.h sont simples à utiliser et efficaces, donc pourquoi dupliquer l'effort en en mettant d'autres dans [insérer le nom de la librairie]."

>Il manque quoi (à part les fonctions clippées, ça on le sait déjà)? 1. Les fonctions clippees

Heureusement que j'ai dit "à part les fonctions clippées".

2. La generation du halo.

(i) C'est un effet artificiel, pas beau.
(ii) Les masques sont là pour ça. Et c'est un moyen plus flexible. Par exemple, en codant son propre masque, on peut choisir soi-même la largeur du halo.

3. L'affichage de plane.

2 boucles for imbriquées, une ligne à l'intérieur et c'est bon. Pas besoin de routines de librairie pour cela.
Ou alors 2 dbra si tu es allergique au C.

4. Les routines de link. 5. Gestion joypad.

Ce n'est pas dans ExtGraph parce que c'est une librairie graphique, pas de link ou de lecture du clavier.

Pour le clavier, tu as _keytest, _keytest_optimized et _rowread dans TIGCCLIB.

Pour le link, les ROM_CALLs marchent très bien si on les utilise correctement. Cf. http://members.lycos.co.uk/jesystems/phpBB2/viewtopic.php?t=19.

6. Effets de lumiere.

Il suffit d'utiliser OSContrastUp et OSContrastDn pour avoir des "effets de lumière".

>D'où l'intérêt de ne pas rajouter des fonctions compliquées et à intérêt doûteux (par exemple tes 2 fameuses "super tables") à sa librairie graphique. C'est tres utile. Cf SMA Aquatic Ruins. C'est splendide comme effet !

Mais c'est juste un effet spécial dont on peut très bien se passer. Et y a-t'il d'autres personnes que toi à utiliser ça?

>>>[ExtGraph est] suffisamment rapide pour pratiquement toutes les utilisations pratiques
>>Qui sont ? Des jeux de reflexions ?
>Toutes sortes de jeux ou autres programmes. Mais pas des jeux d'actions.

Si. Il y a bien des jeux "temps réel" codés avec ExtGraph!

>Seulement après avoir installé l'interpréteur du format (c'est-à-dire le kernel).
Parce qu'il y a pas d'autostart ! Faudrait que je fasse Preos en apps.

Bonne change pour le faire signer par TI.

>Il fonctionne très bien! À part pour un programme avec des milliers de relogements (*ahem* CC *ahem*), évidemment. Mais il est sous-optimal ! Toi qui deteste la place perdu, tu devrais t'en rendre compte !

C'est quand-même le format prévu, et donc je l'utilise.

>Elle ne convient pas très bien parce qu'elle n'existe qu'en dynamique. Arg !

>Sauf que mes calculs ont pris des cas moyens, voire des cas qu'on croierait extrêmement favorisants pour les librairies dynamiques, mais qui en fait, calculs faits, ne l'étaient pas du tout. Hein ? Ou ca ?

Partout dans les discussions kernel vs. _nostub précédentes.

>Et ben, je dis que tu te trompes là. Vu la taille de genlib (autour de 16 KO) et vu la taille des routines utilisées d'habitude dans ExtGraph (autour de 2 KO: 1 KO pour les niveaux de gris de TIGCCLIB et 1 KO pour les fonctions de ExtGraph elle-même), il faut au moins 8 jeux avec genlib pour que le fait que genlib est une librairie dynamique soit rentable. Tu oublies toutes les fonctions que l'on doit reecrire par soi meme car ca n'y est pas dans genlib.

1. Je suppose que tu voulais dire "car ca n'y est pas dans ExtGraph."
2. Comme dit plus haut, il n'y a pas tellement de fonctions utiles qui n'y sont pas.

tu oublies la vitesse d'execution.

Je ne vois pas ce que viendrait faire la vitesse d'exécution dans les calculs de taille.

>Or, les jeux avec genlib ont généralement besoin de nettement plus de 655360/8=81920 octets d'archive en tout (cf. SMA, CF, ...), donc la solution de ExtGraph est meilleure. Et la compression n'y changera rien, vu qu'elle compresse genlib et ExtGraph de la même manière.
mais ca permet de mettre a jour genlib pour d'autres machines

1. On peut aussi mettre à jour ExtGraph pour d'autres machines. Il suffit de relinker.
2. Si la taille d'écran change radicalement, le programme devra de toute façon être porté.

>Tu utilises AutoStart si tu veux absolument lancer le programme par son nom seul sans utiliser de lanceur personnalisé. Il prend moins de place que PreOs même en rajoutant la taille de ttstart! Et en ajoutant la taille de Kerno ?

Y-en a marre des "Et en ajoutant ...". Je ne compte que ce qui est vraiment nécessaire pour lancer le programme. KerNO ne l'est certainement pas.

>N'empêche que pas mal de ses fonctions sont inutiles pour la plupart des programmes qui l'utilisent. Attention, je ne dis pas qu'elles ne sont pas utiles pour certains programmes, mais juste qu'elles traîneront inutilisées dans la plupart des cas parce que le principe des librairies dynamiques ne permet pas d'envoyer des fonctions au système de destination ("target", ici la calculatrice) de manière sélective. Lesquelles sont inutilisees ?

Ça dépend de la librairie. Dans userlib et graphlib, il y en a plein qui le sont, ou devraient l'être puisqu'elles sont déjà dans AMS: userlib::idle_loop, graphlib::clr_scr etc. Dans genlib, il y en a certainement aussi (vu le nombre de fonctions qu'il y a), mais je ne connais pas suffisamment genlib et les jeux qui l'utilisent pour pouvoir donner des noms concrets.

>Si, elle est plus compliquée!
Montre le :
genaux_init(GENAUX_DBUFFER|GENAUX_SPR16_TABLE, spr16);
gen_put_sprite_16(16, 16, 0);
gen_wait_key(); genaux_quit();

Elles sortent d'où genaux_init et genaux_quit? Elles n'y sont pas dans la version de genlib.h que j'ai.
Et puis, tu fais comment en cas d'erreur? Tu appelles exit dans genaux_init? Et si le programme a alloué de la mémoire avant, il fait quoi? Obligé d'utiliser atexit? C'est tout sauf pratique.

>Il y en a eu nettement moins. Le mot "bug" apparaît 20 fois (dont 5 fois au pluriel) dans l'historique de genlib, et seulement 4 fois dans celle de ExtGraph. Ce n'est absolument pas le meme degre de complexite.

Donc genlib est trop complexe. Cf. plus haut, je n'ai pas envie de me répéter.

>Mais non. Si la différence de vitesse est négligeable, elle est négligeable! Elle n'est pas negligeable !

Si. Ce n'est même pas un facteur 3/2!

>Je dis qu'il abuse parce qu'il n'adapte pas du tout son usage d'effets spéciaux à la plateforme sur laquelle il programme. Mais ca fonctionne !

Mais c'est lent.

>Dans le Mario à 1 fps, on avance par pas de 5 ou 10 pixels quand on court. ... meme fer3 v3.20 va plus vite que 1 fps.

Parce que tu utilises des lignes et des cercles plutôt que des sprites pour tes personnages.

>Et évidemment qu'un Mario à 1 fps n'est pas comparable à un SMA. Mais un Mario à 10 fps l'est tout à fait! Mario et Sonic sont INCOMPARABLES !

C'est vrai, je préfère de loin Mario. Et c'est parti pour un autre flamewar.

>si on laisse les programmeurs programmer en mode kernel, on empêche aux utilisateurs de ne pas utiliser de kernel. Si on laisse les programmeurs programmer seulement pour AMS, on empêche les utilisateurs de ne pas utiliser AMS.

Et il y a quoi à part AMS? Pedrom? Déjà, ce n'est pas encore sorti, et puis c'est un clône incomplet de AMS. (Attention, je ne veux pas du tout démonter ton projet, tu as fait un travail excellent. Mais ça ne change rien au fait que ce n'est pas une plateforme vraiment différente par rapport à AMS.)

Et puis, "programmer en _nostub" ne veut pas forcément dire "programmer seulement pour AMS". La preuve: Backgammon marche très bien sous Pedrom.

>ma foi, je trouve le switch pr le supprimer très utile
>Dès que je dl une nouvelle version de preOS, je supprime le switch pr HW2tsr, le switch qui permet de supporter les HW2, le switch pr afficher les boites de dialogues à la fin de l'installation... Et je recompile.
>Comme ça, preOS ne contient que ce dont j'ai besoin : il prend moins de place, et j'ai pas de crise de nerfs avec 36 boites de dialogue
(d'ailleurs, PpHd, merci pr ces swithc )
C'est fait pour.
Mais tu auras bientot de nouveaux switchs a ta disposition. Entre autre, ERASE_UNCERTIFIED_LIB.

Argh, tu deviens déjà comme TI, toi...

>Qd j'aurai quitté la communauté, j'aimerai bien qu'un kernel se charge de rendre mes progs compatbiles avec ce qui va arriver dans le futur. CODE EN MODE KERNEL ALORS !

Solution plus simple: sors tes sources, comme ça on pourra les recompiler s'il y a un problème. Si tu ne veux absolument pas les publier, envoie-les à une personne de confiance et qui reste dans la communauté.

>ma foi, je suis assez d'accord... ça serait bien pratique que ce soit intégré au kernel...
>comme ça, on tape directement le nom du ppg dans la ligne d'entrée,
>pas besoin d'appeller ttstart...
>(en supposant que ce soit possible, ce serait bien pratique !) Tu compiles en Pack Archive, tu crees une lib "ttpack", et c'est bon.

Je sens que Thomas ne va pas aimer. Et moi non plus d'ailleurs. Le format PPG est là pour être respecté!

Sinon tu as autostart.

En effet, c'est fait pour.

>la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs C'est pas qu'un polygone. Y'en a 16 je crois.

Mais ce n'est quand-même qu'un objet, pas un monde 3D.

PS :
il parrait que ça a l'air ironique, je precise que PAS DU TOUT.

Raah, il y a toujours pas mal de trucs auxquels je voudrais répondre, mais ça sera pour plus tard. J'ai trop de choses à dire.

>>Comment: No" -> plus pour longtemps. Il y a déjà la spécification préliminaire. Donc encore Yes!
>C'est du vaporware, mon cher, cette techno la.
GTC, GTools, Formula One... c'est du vrai vaporware. Mais là, non. Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ?

> Kerno est un kernel batard.
C'est pas un kernel, surtout... "KerNO is an intentional misspelling of kernel" (readme de KerNO)...

> Va lire le fichier.
Je n'ai pas que ça à faire, surtout quand je vois qu'il est bourré de conneries...

> si gt toi je passerais mon temps à autre chose Kevin ;]
Là, je suis à peu près d'accord...
> Kevin a le doit de se détendre de temps en temps
C'est vrai aussi.

> Mon affirmation est tout a fait juste, c'est un axiome des Ti68K, donc amuse toi a demontrer sons contraire.
Toujours aussi fin, respectueux et donc respectable fin, le TiMad... ARGUMENTE, plutôt que de dire n'importe quoi !

> Les routines de sprites de TIGCCLIB ne sont pas si lentes que ça.
Vrai, mais elles sont plus lentes que celles d'ExtGraph (qui vont, je le répète encore une fois, être améliorées dans une des prochaines versions). C'est inhérent aux tests dûs à la gestion des trois modes dans la même routine.

> Non, les kernels sont considérés dépassés presque unanimement partout sauf sur ce forum.
En effet. Allez voir les comments du thread qui parle de CC sur TI-Net, avant qu'il y en ait un qui se rende compte qu'il y a une version _nostub... Il y a des trucs du genre "I'm not going to put an evil shell on my calculator just for that" (écrit tel quel si je ne me suis pas trompé; le 'evil shell' est écrit, en tout cas), ce qui est somme toute assez clair...

>> Le patch pour faire communiquer tictex / tictexpl
>Ce n'est pas sale. Même Thomas ne dit pas que c'est "dirty", et pourtant ce que Thomas appelle "sale" est toujours nettement plus propre que ce que toi, tu appelles "propre".
Ca n'est pas sale. Ca fait gagner beaucoup de RAM, par contre... Du reste, XPort (un autre shell en grayscale), décharge aussi la plus grosse partie quand un programme est exécuté.
Je pense que PpHd qui dit que ce font les autres est sale, voit la paille dans l'oeil du voisin mais pas la poutre qui est dans son propre oeil...


>>>Ah, je vois (c'est dans le ZIP de Pedrom que tu m'as envoyé pour le problème avec A68k ). Il y a pas mal de trucs qui pourraient nous intéresser (pour la documentation de TIGCC) dans ton Note.txt.
>>C'est fait pour
>Mais il faudra que quelqu'un (probablement moi, ou peut-être Lionel) traduise tout ça du Français raccourci à l'Anglais complet.
Probablement toi, en effet. Il serait improbable que j'aie du temps pour faire autre chose que le strict minimum pour TICT, avant les grandes vacances. En revanche, toi, tu nous démontres brillamment dans ce topic que tu as du temps...
Et bien sûr, il ne faut pas oublier de remercier PpHd pour ce boulot de documentation qu'il fait.


> Et puis, "programmer en _nostub" ne veut pas forcément dire "programmer seulement pour AMS". La preuve: Backgammon marche très bien sous Pedrom
Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...

>> Faudrait que je fasse Preos en apps.
> Bonne chance pour le faire signer par TI.
En effet. Jamais ils ne signeront une horreur pareille. Et puis ça serait trop bête de se limiter aux AMS 2.xx, sur lesquelles un certain nombre de programmes kernel-based ne fonctionne pas du tout...

>>Je sens que Thomas ne va pas aimer. Et moi non plus d'ailleurs. Le format PPG est là pour être respecté!
Je ne vais pas aimer non plus...
De toute façon, il faut recoder l'algorithme, pour pouvoir le mettre on-calc: l'algo nécessite, en RAM, 128 KO + 15 * size of input...
Autrement dit: faire une version différente, pas supportée officiellement... S'il y a des problèmes avec, on se fera un plaisir de dire que ça n'est pas de notre faute, mais celle de quelques personnes qui sont obsédées par les libs dynamiques...

>Il est non seulement tout à fait possible de coder des programmes mathématiques en C sous AMS, ça permet aussi de faire plein de choses qu'on ne peut pas faire en BASIC. Par exemple, rechercher des sous-expressions d'un certain type dans une expression et faire des manipulations sur les sous-expressions trouvées.

On ne dit pas que c'est impossible. Mais plus difficile qu'en basic, pour un avantage pas si evident que ca.

>Mais il n'y a quand-même pas de fortes chances que sprintf change de manière imprévue.
Une simple recompilation en changeant les flags suffira a casser votre hack

>Mais bonjour la taille des routines qui permettent cela...
Je suis sur que tu es capable de le faire en moins de 500 octets.

>De toute façon, la compatibilité binaire parfaite est illusoire. Par exemple, les kernels ont été incapables de garantir la compatibilité binaire entre AMS 1 et 2, il y a eu besoin de changements dans les kernels et de recompilations, de réassemblages, voire de portages assez complexes pour les programmes.
Les programmes accedaient a des variables absolus.
Le format du kernel a bien evolue depuis.

>Alors que les premiers programmes _nostub (on les comptait sur les doigts d'une main à l'époque) n'avaient pas besoin de portage du tout d'ailleurs (sauf pour basiclib qui utilisait des adresses absolues toutes les 3 lignes ).
C'est surtout parce qu'ils ne faisaient rien et qu'ils se comptaient sur les doights d'une main.

>Je fais ça aussi en général. Mais doit-on compter ça comme plusieurs lignes?
Autant que le contraire.

>C'est la meilleure manière de défiler de plusieurs pixels à la fois en horizontale. Le flag X utilisé par roxl/roxr ne peut contenir qu'un bit à la fois.
C'est bien ca le probleme

>Ça ne veut pas dire qu'il n'est pas dépassé! Comme j'ai déjà dit: il y a toujours des nostalgiques pour faire évoluer les systèmes totalement dépassés!
Pour qu'il soit depassee, il faudrait qu'il soit technologiquement inferieur au nostub. Ce qui est absolument le contraire. Technologiquement parlant, le kernel est bien superieur au nostub. La preuve est simple : EX_patch en _nostub, seul suffit. Un kernel de 3Ko (Et bien etudie en taille) est necessaire et suffit pour le mode kernel.

>Le format de base ne change pas parce qu'il n'a pas besoin de changer. Il est très bien comme il est. Et il y a des évolutions à l'intérieur de ce format de base. Par exemple le format de commentaires et autres données qui est en développement.
Ca ne fera jamais parti du format _nostub. Le format _nostub c'est :
SIZE + CODE + TABLE_DE_RELOGEMENT + TAG

>Trop de sprites, trop d'animations => framerate insuffisant. C'est une implication logique.
C'etait ironique.

>Ce que le "NO" signifie, c'est qu'il n'y a pas de support pour le format "kernel" (DoorsOS). À part le support pour ce mode dépassé, il ne lui manque pas grand chose.
Le support desactive de ESC+ON dans AMS

>- Même si c'est le cas, ce n'est pas une raison à elle toute seule de ne pas utiliser les librairies statiques. Déjà, les librairies statiques ont aussi leur manière d'économiser de la taille (ne pas linker les fonctions inutilisées). Et ensuite, même dans le cas très improbable où la librairie statique prendrait plus de place, les avantages des librairies statiques justifient nettement le sacrifice minimal en taille.
Je connais une lib statique qui s'appelle allegro. Et qui meme lorsqu'on ne fait appel qu'aux fonctions d'initialisation/quit prend 400Ko sur ton programme...
Elle est ou l'economie ?

>Encore une fois: je ne vois pas pourquoi il serait si horrible que ça d'avoir plusieurs fois le même code sur une même machine, si toutes les copies sont utilisées. Je trouve bien pire de voir de la mémoire gaspillée pour du code qui traîne complètement inutilisé!
Comment peux-tu etre si sûr qu'il soit inutilise ? Des exemples ?

>- impossible de lancer un programme sans installation préalable d'un programme tiers.
Le programme tiers peut l'installer lui-meme.

>- gaspillage de place en utilisant une surcouche d'émulation par dessus AMS (pour une estimation de la place gaspillée, comparez la taille de PreOs avec celle de KerNO).
+KerNO: 2949 bytes.
PreOS: 6657 bytes. (3706 bytes)
+KerNO:AMS 2.0x.
PreOS: Toutes versions d'AMS.
+KerNO:Anti-Crash par ER_throw (Plante si on le fait dans AMS).
PreOS: Anti-Crash multi-niveau par reset (Ne plante pas (totalement) si on le fait dans AMS).
+KerNOiamond+ON turns off.
PreOS: No. AMS does the job.
+KerNOpeeds up keyboard repeat rates
PreOS: No. FastKeyboard does the job.
+KerNO:Fixes (removes) the slowdown that happens in some games when the calc is turned back on after being turned off during game play
PreOS: No. It is a buggy feature !
+KerNO:Checks the heap
PreOS: Useless.
+KerNO:The Assembly Language size limit
PreOS: Too
+KerNO:Assembly language programs that return values
PreOS: Too
+KerNO:Provides a custom Line 1111 emulator
PreOS: Too

PreOS: Support of Kernel programs (Version 2,3,4 & 5)
PreOS: Can call any program at any-time by pressing SHIFT+ON (Even tictex).
PreOS: Basic Functions can use 'Program only' instruction.

>- complique la vie aux développeurs d'outils de développement à cause de son format difficile à gérer pour le linker.
On en a deja parler. Et c'est de la mauvaise foi.

>- gaspillage de place pour les routines inutilisées des librairies dynamiques.
Quelles routines ?

>Ah bon... Je n'ai jamais essayé CF, il nécessite beaucoup trop de mémoire (à la fois archive et RAM). Pour moi, la limite de l'acceptable en comsommation de mémoire est TI-Chess. Tout ce qui consomme plus consomme trop.
Desole. Les graphismes detailles consomment trop de place.

>C'est à ça que servent les masques. Ils sont aussi plus flexibles.
Mais consomment plus en memoire.

>Certes, mais il propose exactement les fonctionnalités que Uther demandait...
Sauf le plus important

>Je n'exagère pas. Une arme de jeu qui tire 96 missiles à la fois n'est pas du tout adaptée à un processeur à 10 ou 12 MHz.
LOL. Tu n'as vraiment pas du essayer CF, toi

>+KerNO:Fixes (removes) the slowdown that happens in some games when the calc is turned back on after being turned off during game play
>PreOS: No. It is a buggy feature !
Quel bugs as-tu à déplorer ? Peut-être que la dernière version que tu as testée n'est pas la dernière...

>+KerNO:Checks the heap
>PreOS: Useless.
Je ne pense pas...

> PreOS: Can call any program at any-time by pressing SHIFT+ON (Even tictex).
Sans jamais faire de bugs avec le bit in_use ou des trucs comme ça, quand on lance SHIFT+ON quand on édite un texte dans l'éditeur de texte, [je demande de l'info] ?

>>PreOS: No. It is a buggy feature !
>Quel bugs as-tu à déplorer ? Peut-être que la dernière version que tu as testée n'est pas la dernière...
C'est buggue tout simplement. Il faut tester le materiel avant de changer ce port.

>> PreOS: Can call any program at any-time by pressing SHIFT+ON (Even tictex).
>Sans jamais faire de bugs avec le bit in_use ou des trucs comme ça, quand on lance SHIFT+ON quand on édite un texte dans l'éditeur de texte, [je demande de l'info] ?
Si tu veux des bugs, c'est tres simple. Prend un programme qui modifie l'EStack par un HS_popEStack, et ca plantera (un ER_throw).

>Comme je l'ai déjà dit, une notation a partir d'un tableau est une maivaise idée car aucune note ne pourra vraiment représenter la réalité. Mais les commentaire a l'intérieur du tableau sont bons et représentent a peu près tous les avantages et inconvéniants. de chaque méthode.
Je compte l'enlever.

>La c'est vrai mais une DLL Nostub n'est vraiment pas si simple a utiliser qu'une lib dynamique kernel.
Heretique ! Une DLL _nostub n'est la que pour depasser de maniere propre, simple, et efficace, la dure barriere des 64Ko. Comment oses-tu la comparer a des LIB dynamiques ?

>Volées sur un format prétendu dépassé mais qui a été bien plus visionnaire vu qu'il les gère depuis des années.


>Tu ne le respectes pas. Déjà, tu n'utilises pas la table de relogements prévue par le format. Et ensuite, tu mets des trucs dans le fichier sans mettre du code pour les gérer, juste un stub pour appeler un TSR (le "kernel"), dans l'espoir qu'il soit installé. S'il ne l'est pas, ça ne marche pas. Ce n'est pas ce que j'appelle "respecter le format natif".
En quoi ne pas utiliser la table de relogements du format n'est pas le respecter ? Il existe des _nostub qui ne l'utilisent pas aussi.
En quoi faire appel a une fonction externe non-documentee n'est pas respecte le format d'AMS ?

>C'est totalement faux. AMS est conçu pour être programmable!
Il parlait on-calc. Et toi meme, disais la meme chose.

>Je ne vois pas l'intérêt d'utiliser le mode kernel juste pour pouvoir utiliser une certaine librairie graphique dynamique, alors qu'il y a des alternatives _nostub en librairie statique.
parce qu'elle offre des fonctionnalites superieures a ces libs statiques.

>CC utilise un nombre excessif de relogements absolus! Il y a beaucoup trop de variables globales partagées entre plusieurs fichiers source. Un programme conçu spécifiquement pour TI-89/92+/V200 n'utilisera jamais autant de relogements.
>Et puis, CC n'utilisait aucune librairie dynamique, donc ça n'a aucun rapport avec les librairies dynamiques ou statiques. C'est juste une question de relogements.
Et alors ? Justement, cela prouve le caractere technologiquement depasse de ce format.

>Mais ces "équivalents" ne sont pas nécessaires pour lancer les programmes. On peut s'en passer si on veut économiser sa mémoire, ce qui n'est pas le cas du kernel.
C'est a cause d'hw2tsr que je peux pas faire de lanceur kernel (compatible tictex).

>1. C'est tout bête. Il suffit de mettre #define EXECUTE_IN_GHOST_SPACE.
Et cette astuce foirera lorqsue TI mettra plus de 256Ko de RAM.
Remarque, ce sera pas les seuls programmes a ne pas fonctionner.

>2. Cette "astuce" n'est nécessaire que si on programme un shell ou un programme de ce style. Pour tous les autres programmes (jeux, programmes mathématiques, ...), on n'a besoin d'aucune "astuce".
Et en kernel, on n'en a besoin d'aucune.

>Tu appelles 9 KO "pas tant de place"?
Et pas toi ?

>En effet, genlib est trop complexe. C'est une erreur de conception. Ça n'apporte rien, ça la rend juste plus grosse, moins flexible, plus difficile à utiliser et, comme tu viens de le dire toi-même, augmente le risque de bogues.
Que veux-tu ? Entre une simple lib qui affiche des sprites, et une lib de jeux complete, y'a un gouffre de differences.
Et j'avoue que si j'avais a la refaire, je referais quelques trucs.

>J'avais dit cela de manière totalement objective. Ça ne sert à rien parce que au moins 95% des jeux sur TI-89/92+/V200 n'ont aucune difficulté à atteindre les 10 fps nécessaires pour obtenir la fluidité. ExtGraph est suffisamment rapide.
10fps sont LA limite a ne pas franchir. Pour avoir un bon confort d'utilisation, il faut etre a plus de 20 au moins.

>Et alors, si ça n'a aucun intérêt et que c'est un abus du format, on ne le fait pas.
Mais je le fais

>>Une Pack-Archive contenant une centaine de sous-DLL
>- le gaspillage de taille par le système de packs archive. Surtout les noms des DLLs dans le pack archive et dans la table d'importation du programme.
Certes. Mais pas tant que ca.
>- le temps d'extraction. Même si les DLLs ne sont pas compressées, il faut quand-même allouer pas mal de blocs et copier pas mal de données.
>- le temps de relogement
Pas tant que ca. On deplace beaucoup de peu de donnees.

>- le b*rdel que ça va être pour le programmeur (ou pour l'utilisateur) de choisir les bonnes DLLs parmi la centaine disponible pour son pack archive, alors que pour les librairies statiques, le linker s'occupe de cela pour lui.
Faux. Les includes headers mettront cela de maniere transparente, et la lib complete est distribuee sous la forme d'une pack. Par exemple, mon portage de tigcclib en lib dynamique, sera une pack archive (tigcclib) contenant comme fichiers l'ensemble des fichiers objets de tigcclib.a.

>Donc c'est une très mauvaise idée (en plus d'être un hack ).
Ce n'est pas un hack.

>Les librairies statiques résolvent ce problème de manière plus propre et beaucoup plus efficace.
Sauf que l'on repete sans arret la meme chose.

>Comment veux-tu pouvoir choisir la DLL à laquelle appartient la fonction que tu veux appeler si tu charges plusieurs DLLs en même temps et que tu ne les numérotes pas?
Faire une base commune et lors du loading, on charge dans la base commune l'ensemble des adresses.

>Pas tant que ça. Tout le monde ne s'appelle pas PpHd.
Rien qu'en lisant 'dll.h' on sait comment faire

>Je ne pense pas
Moi si. Et heureusement, je prepare le kernel pour corriger cela.

>Donc plus de kernel en développement?
Non. J'ai un remplacant.

>Dans ce cas, il suffira que TI sorte une mise à jour qui empêche à PreOs et Universal OS de fonctionner,
Meme AMS 2.07 n'a pas empecher Preos de fonctionner sans changement des sources.
Seul hw2tsr posait probleme
Les kernels survivront ne serait-ce que grace a toi

>Et donc les programmeurs en mode kernel, auxquels on a promis (à tord) qu'ils ne devront "jamais" recompiler leurs programmes, seront tous obligés à les recompiler... en mode _nostub.
Mais non.

>Mais "Extended Assembly file" ne veut rien dire. Contrairement à toi, nous n'aimons pas les néologismes.
Je sais. Tres terre, a terre. Mais avoue que DLL est un TRES MAUVAIS CHOIX de nom, pour ce qu'elles sont censees faire.

>À la limite on aurait pu les appeler "external code files", mais ça fait quand-même tordu.
moins que DLL.

>Phoenix est aussi un "shoot-em-up" et il affiche beaucoup moins de sprites. Et Alien Invasion en est aussi un et en affiche encore moins.
Phoenix, pas beaucoup de sprites ? Il en affiche parfois 200 par frame !

>Pourquoi? Il y a juste une rangée à redessiner plutôt que l'écran entier, et je pense bien que le scrolling lui-même soit plus rapide que de réafficher l'écran entier, vu qu'il y a beaucoup moins de calculs à faire.
En matiere de lecture/ecriture, y'a autant de lectures / ecritures dans l'un que dans l'autre.
Mais dans l'un on n'est pas obblige de deplacer d'un seul pixel.

>Ça ne veut rien dire. Évidemment qu'une routine d'affichage est optimisée pour l'affichage. Que tu affiches l'écran entier ou juste ce qui a changé n'a aucune importance pour la routine d'affichage: dans les 2 cas, tu affiches.
Evidemment. Je suis bete.

>Non. Dans les 2 cas, il y a juste une paire de coordonnées par plan à changer. C'est exactement la même chose.
Mais ta double boucle for sera bien plus lente que put_plane !

>Pourquoi? Je ne fais qu'appliquer la définition du scrolling différentiel.
Ben je crois que l'on n'a pas la meme definition.

>Évidemment que si le jeu est conçu pour ne marcher correctement qu'avec le maximum d'effets graphiques, on ne verra pas grand chose si on les désactive. Mais c'est un problème de conception. Surtout celle des graphismes: il faut faire en sorte qu'elles soient clairement visibles même sans effets graphiques. Malheureusement, c'est souvent négligé par les développeurs de jeux commerciaux. Mais ça ne concerne pas du tout les jeux pour TI-89/92+/V200.
C'est un point de vue interressant. Mais je n'ai pas le temps d'approfondir. Dommage.

>Évidemment, parce qu'il y a plein d'ennemis. Mais squale92 affiche 96 missiles sans compter ceux des ennemis!
C'est un cas execptionnel qui ne dure pas !

>Peut-être, mais la différence de taille ne vient pas de là.
Certes. Mais cela ne fait que 3ko pour le format kernel pur.

>Aucun intérêt. TI réussira certainement à détruire les choses beaucoup plus que ce que je pourrais imaginer.
On change de processeur. Ou mieux. On installe un vecteur a la con en $30.l

>Comment ça? En changeant le code du programme? On peut faire la même chose en _nostub.
Ca serait totalement transparent en mode kernel

>Comme la taille horizontale a diminué dans mon exemple, ça ne donnera rien de lisible.
L'int se chargerait de reduire la ligne.

>Et la taille de l'écran???
Elle s'en occupe. Elle est concue pour du 240x128 (Meme sur 89).

>Probablement non. Et je parie que tu as encore oublié de compter la taille du kernel.
Et toi tu as oublie que le kernel de ma calc est en ROM

>Il n'y a aucun problème justement. Chaque programme utilise la version pour laquelle il est prévu. Il n'y a aucun conflit!
Et lorsqu'on ne sait meme pas laquelle il faut utiliser ?

>Arrête de boycotter le _nostub! Il n'y a pas de raison!
Si.

>Si, il y a une référence matérielle: le code 68k
Certes. Mais dans ce cas, je jette l'eponge

>N'importe quoi. Ton attitude "si les fonctions sont inutilisées, le programmeur n'a qu'à les utiliser" est arrogante et stupide. Si les fonctions ne lui servent pas, pourquoi devrait-il les utiliser juste pour qu'elles soient utilisées?
1. C'est en dynamique parce que ca permet de centraliser toutes les versions en une seule, d'ou une simplicite de mise a jour pour l'utilisateur qui n'est pas dependant du bon vouloir du programmeur.
2. Donc ces fonctions que le programmeur le veuille ou non, y sont.
3. Pourquoi ne pas rajouter alors un petit bonus pas trop gros qui les utilise ?
C'est un 'Pourquoi pas', pas un 'n'a qu'a'.

> Et tout ceci alors que la solution au problème est très simple: utiliser une librairie statique, comme ça, quand le programmeur n'utilise pas certaines fonctions, l'espace mémoire sera économisé. Ton "Mais elles y sont !" est exactement le problème, auquel tu n'as pas donné de solution parce qu'il n'y en a pas en restant dans le domaine des librairies dynamiques.
Il n'y a aucun probleme si les libs dynamiques sont a jour. Et en plus, c'est tres facile maintenant de les avoir a jour.

>De manière complexe et pas très propre.
Question d'habitude. Je n'ai aucun boggue a cause de cela.

>Tu as bien réussi à te passer de code auto-modifiant dans PedRom!
Bien obblige, non ? Mais :
1. La plupart des constantes sont vraiment constantes.
2. Le reste, c'est des vars globales.

>À condition de tester à chaque fois toutes les routines que tu patches!
Comment veux-tu faire autrement ?

>En d'autres mots, tu es trop paresseux pour faire de l'allocation de registres. Dans ce cas, utilise un compilateur, il s'occupera de ça pour toi.
GCC compile mal. Je passe beaucoup de temps a lui expliquer mon code C de telle facon qu'il est traduit de maniere optimale.

>Mais ce n'est pas du tout dans ton esprit "le kernel gère tout",
Le format est bien evoultif puisqu'il autorise a autoriser ttpack

> ce n'est pas pratique.
Totalement transparent au niveau utilisateur.

> et shrnklib compresse nettement moins bien que ttpack
Pas tant que ca. Et elle decompresse bien plus vite. Ce qui est plus important.

>En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça.
Pourquoi ? La licence me l'interdit ?

>Et puis: exécution automatique au démarrage = possibilité d'avoir un plantage dès le démarrage...
C'est pour cela qu'il existe des touches pour eviter le demarrage automatique.
Et depuis Windows, on n'a plus le choix.

>Kevin a le doit de se détendre de temps en temps
moi aussi, ca me detend.

>En tout cas c'est très interessant à lire (et je suis sincère : j'ai tout lu jusque là)
Moi aussi Bien obblige remarque.

>GTC n'existe pas encore
Tout a fait. Attendons avant de continuer ce debat.
>et d'après ce qui a été dit, ses fonctionnalités ne seront pas tout à fait comparables à celles de GCC.
Certes. Mais suffisantes pour faire de la bonne programmation.

> Parle à Pollux de certaines techniques d'optimisation de GCC et il ne saura même pas ce que c'est...
Les techniciens utilisent parfois du langage obscur pour decrire quelque chose de simple.

>Ce qui n'est pas vraiment le cas pour les programmes pour TI-89/92+/V200 normalement.
J'aimerais le faire. Mais Tigcc m'en empeche.

>Mais il faut dire que tes fonctions n'ont pas toujours la fonctionnalité complète de celles de AMS.
Tout a fait. Mais quand meme !

>Et ne me ressors pas la blague des packs archive avec une DLL par fonction, j'ai déjà montré que ça ne tient pas du tout la route.
Tu n'as rien demontre du tout. Au contraire, tu parlais de quelques inconvenients mineurs, mais en aucun cas que ca ne pouvait pas marcher.

>AMS oui. Windows par exemple, non.
Linux oui.

>Tout le monde ne connaît pas par cœur les numéros de la centaine de fonctions de genlib. Je pense d'ailleurs que même toi, tu ne les connais pas par cœur.
Je n'ai jamais dit que c'etait facile. Mais lisible.

>Et pourquoi?
Un nom est suceptible de changer a cause de la langue (TI-basic), ou de mises en conformite sur ce que fait reellement la fonction.

>Parce que chez nous, la discussion n'est plus entre _nostub et kernel, mais entre _nostub et FlashApps.
Je sais. C'est bien ce que je disais.
Franchement kernel rulez ! kernel >> nostub >> FlashApps

>Non, les kernels sont considérés dépassés presque unanimement partout sauf sur ce forum.
Parce qu'ils (la plupart) ne connaissent que DoorsOs.

>Il n'y a pas que les jeux genlib à être "concus pour etre beaus, riches et complexes", et pourtant les autres ont bien réussi à sortir des versions 1.00 (TI-Chess, Duke68k, ...).
Ti-Chess est un jeu d'echec, donc les graphismes c'est a part.
Duke68k n'est pas beau, desole

>Ce n'était pas le seul problème qu'il avait. Il y avait pas mal de bogues. Il a toujours fallu avoir la dernière version de genlib pour chaque version de Total Destruction.
Et ou est le probleme ? Faire une mise a jour est elle une operation si difficile ?
Il n'y a jamais eu de version de genlib pour faire fonctionner (exclusivement) SMA, et une autre (exclusivement) Total !

>Corollaire: Le futur du mode kernel dépend de la bonne volonté de quelqu'un qui est contre les kernels (moi).
C'est rigolo, non ? Ne t'inquietes pas. Si tu ne fais plus de mises a jour, je saurais me passer de toi.

>Heureusement pour toi que j'ai aussi mes propres TSRs à faire marcher.


>Mais tu ne peux pas faire une API de librairie statique de style:
>SetBuffer(void *buffer);
>If you call this function, then function xyz will write into the specified buffer. If you don't, it will use its own static buffer.
Pas tres propre quand meme

>2. Quand j'en suis déjà au handle, je m'attends à ce que tout le travail sur les HSym et SYM_ENTRY ait déjà été fait, et EM_twinSymFromExtMem en fait partie. Quelle idée que de passer un bloc archivé à une fonction d'exécution! kernel::exec ne devrait pas accepter cela (je sais, c'est trop tard pour changer etc., pas la peine de me dire ça). La méthode propre est d'appeler EM_twinSymFromExtMem avant d'essayer d'obtenir le handle.
Pourquoi ? C'est a elle de se rendre compte que le fichier est archive et necessite un traitement particulier.

>Ce n'est pas sale. Même Thomas ne dit pas que c'est "dirty", et pourtant ce que Thomas appelle "sale" est toujours nettement plus propre que ce que toi, tu appelles "propre".
Je n'ai jamais dit que le code que je faisais etait propre !
Ensuite c'est sale parce que cela depend de la bonne volontee de GCC, qui pourrait le mettre un peu partout.
(Remarque si mes souvenirs sont bons, ca devrait quand meme marcher).

>Mais je parlais de patches pour rajouter du code de démarrage. SET_FILE_IN_USE_BIT et tous les autres exemples que j'ai cités, c'est du code de démarrage.
Pas moi.

>Donc tes jeux ne sont pas si complexes que tu prétends.
Je code en ASM de maniere optimise (en taille et en vitesse).
Et eux en C,

>Bon, je répète en accentuant la locution importante: "Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas."
Et que fais-tu de ceux retires ?

>Ben, s'ils n'en avaient rien à battre de la compatibilité, au moment de la sortie du SDK, ils auraient refait toute la table des sauts pour supprimer toutes les fonctions qui ne sont pas documentées dans le SDK et renuméroter toutes les autres.
Sauf qu'ils sont flemmards, et ont eu la flemme de reecrire la table des sauts

>Le format de quoi?
Le format interne utiliser par les custom.

>Ou que l'offset ne change pas. Il n'y a que 8 instructions devant celle qui nous intéresse, et elles ont toutes peu de chances de changer à moins que TI ne se mette à utiliser l'équivalent de -fomit-frame-pointer.
Moi qui est fait un sprintf avec gcc, je suis obblige de rajouter a la main 2 'nop', pour que ca marche

>D'après ce que j'ai entendu dire (je n'ai pas encore essayé TI-Connect), tu ne peux pas "voir" les fonctions importantes de l'interface de TI-Connect, c'est du drag&drop pur.
J'avoue que je n'ai rien compris a TI-connect

>Il suffit de le mettre dans ttstart. Puis on recompile un nouveau lanceur personnalisé à partir de la mise à jour de ttstart et c'est bon.
Et ttstart deviendrait un kernel non-installable

>Mais les IDEs ont un grand avantage: ils gèrent les projets. Donc ils permettent de chercher et remplacer dans un projet entier, par exemple.
UEDit aussi

>Bah, j'ai codé *scanf (source de 11 KO, routine de 1 KO) en assembleur GNU et je n'ai pas trouvé ça si lourd que ça.
Peut etre, mais a t'entendre, un peu quand meme.
Par ailleurs, il faudrait verifier si le code que j'ai fait de lecture des nombres reels (PedroM / EStack.asm) ne permettrait pas de reduire encore la taille du code (Plus d'appel a Atof).

>>>C'est justement ça ton erreur, à mon avis.
>>Tu veux donc un exemple ou c'est impossible de faire autrement ?
>Si tu en as un, poste-le.
On parle de quoi ?

>Il ne faut pas être surpris que Thomas ne soit pas très pressé pour mettre tes mises à jour si:
>1. Ce n'est pas important.
>2. Des chaînes susceptibles de traduction ont changé
Je ne suis pas surpris. Juste un peu decu.

>Est-il si grave que les 3 ou 4 programmes (je ne pense pas qu'il y en ait plus que ça) qui utilisent les 3 RAM_CALLs maintenant reçoivent un mélange de fontes du boot et de fontes de la ROM?
Je perdrais mon honneur

>C'est une fonctionnalité en moins (le linkage statique), pas une fonctionnalité supplémentaire.
Je parlais des lib dynamiques.

>Pourquoi en aurait-il besoin puisque, vu qu'il utilise la version actuelle, le programme doit forcément être adapté à la vitesse de la version actuelle?
Laisse au programmeur le soin d'en decider.

>>>Les jeux avec FAT Engine ou d'autres techniques 3D tournent souvent autour des 10 FPS. Les jeux en 2D ont des framerates nettement plus élevés.
>>Ils sont plus interressants aussi.
> Hein ?
Ben le FAT engine, ca va 2s.

>Ah tiens, tout d'un coup. Sur un jeu de 33 KO ou plus, les routines de niveaux de gris font 3% ou moins. Donc si tu n'es pas à 3% près, arrête de te plaindre du fait qu'ils utilisent les routines de niveaux de gris en librairie statique.
Oué, sauf que ca me pose des problemes pour faire fonctionner des vieux jeux nostub qui utilisent vos vieilles routines de gray, qui marchent pas sur PedroM ! Et y'a pas les sources !

>Pas sûr.
J'y ai passe du temps, et je confirme. C'est tres transparent.

>Pourquoi? Il y a plus de calculs à faire que pour un simple scrolling...
Tu ne connais pas bien la technique du plane.

>Quelle idée stupide!
>Crois-tu vraiment qu'un nag screen de style shareware au début de chaque programme juste pour parler de ttstart à l'utilisateur soit une idée intelligente?
Oui, sans aucune hesitation.

>Et en plus, ton message gaspillerait pas mal de place.
Tout comme le lanceur !

>Je n'ai pas le temps d'essayer, mais je pense bien que CF ou SMA pourraient très bien fonctionner avec ExtGraph.
>Et SMA est trop rapide de toute façon.
Ok. Tu as les sources de SMA en plus

>Ah bon.
>Mais ce n'est qu'un objet, n'est-ce pas? Entre un seul objet 3D et un monde 3D entier, il y a quand-même une différence évidente.
Certes. Mais c'est quand meme une vingtaine de faces affiches en niveaux de gris en plus du mondes 2D.

>Non, il faut installer un kernel, donc on ne peut pas les lancer directement.
Une fois installe PreOS, tout se lance directement.

>Mais non! C'est quoi cette arrogance de vouloir toujours imposer son choix à l'utilisateur?
ET LES LIBS STATIQUES C'EST PAS UN TRUC IMPOSE A L'UTILISATEUR !
Et si l'utilisateur a envie de mettre a jour son programme favori pour quelques corrections de bogues, il peut facilement mettre a jour la lib externe sans attendre le bon vouloir du programmeur !

>Il reste quand-même cet argument-là: "Les fonctions de gray.h sont simples à utiliser et efficaces, donc pourquoi dupliquer l'effort en en mettant d'autres dans [insérer le nom de la librairie]."
Moi je suis a part, puisque Genlib existait bien avant tigcclib

>(i) C'est un effet artificiel, pas beau.
>(ii) Les masques sont là pour ça. Et c'est un moyen plus flexible. Par exemple, en codant son propre masque, on peut choisir soi-même la largeur du halo.
Plus de memoire consommee.

>2 boucles for imbriquées, une ligne à l'intérieur et c'est bon. Pas besoin de routines de librairie pour cela.
Ou alors 2 dbra si tu es allergique au C.
Performances biens inferieures.

>Pour le clavier, tu as _keytest, _keytest_optimized et _rowread dans TIGCCLIB.
C'est mieux le joypad.

>Pour le link, les ROM_CALLs marchent très bien si on les utilise correctement.
Je dis pas le contraire. C'est juste plus rapide.

>Il suffit d'utiliser OSContrastUp et OSContrastDn pour avoir des "effets de lumière".
Et pour avoir des sources de lumieres ponctuelles ?

>Mais c'est juste un effet spécial dont on peut très bien se passer. Et y a-t'il d'autres personnes que toi à utiliser ça?
Oué.

>Si. Il y a bien des jeux "temps réel" codés avec ExtGraph!
Entre "jeux temps reel" et "jeux d'actions". Il y a une marge importante.

>Bonne change pour le faire signer par TI.
Pourquoi le faire signer par TI ? Pas besoin

>Partout dans les discussions kernel vs. _nostub précédentes.
Je n'ai jamais ete convaincus par ces calculs, surtout qu'avec la base tigcclib commune, beaucoup de programmes partagent les memes routines.

>1. Je suppose que tu voulais dire "car ca n'y est pas dans ExtGraph."
Oui

>2. Comme dit plus haut, il n'y a pas tellement de fonctions utiles qui n'y sont pas.
DrawFace ?

>Je ne vois pas ce que viendrait faire la vitesse d'exécution dans les calculs de taille.
On n'a pas du se comprendre.

>1. On peut aussi mettre à jour ExtGraph pour d'autres machines. Il suffit de relinker.
>2. Si la taille d'écran change radicalement, le programme devra de toute façon être porté
A condition d'avoir les sources.

>Y-en a marre des "Et en ajoutant ...". Je ne compte que ce qui est vraiment nécessaire pour lancer le programme. KerNO ne l'est certainement pas.


>Ça dépend de la librairie. Dans userlib et graphlib, il y en a plein qui le sont, ou devraient l'être puisqu'elles sont déjà dans AMS: userlib::idle_loop, graphlib::clr_scr etc.
Elles sont utilisees par des programmes.

>Dans genlib, il y en a certainement aussi (vu le nombre de fonctions qu'il y a), mais je ne connais pas suffisamment genlib et les jeux qui l'utilisent pour pouvoir donner des noms concrets.
Certes. Tu peux meme aller dans le chapitre "Out Of Date" de la doc de genlib.

>Elles sortent d'où genaux_init et genaux_quit? Elles n'y sont pas dans la version de genlib.h que j'ai.
Nouvelle version (je sais, tu vas dire que c'est du vaporware. Pas la peine de le dire).

>Et puis, tu fais comment en cas d'erreur? Tu appelles exit dans genaux_init? Et si le programme a alloué de la mémoire avant, il fait quoi? Obligé d'utiliser atexit? C'est tout sauf pratique.
Il fait quoi ? Il utilise l'ancienne methode, c'est tout.

>Donc genlib est trop complexe. Cf. plus haut, je n'ai pas envie de me répéter.
Idem !

>Si. Ce n'est même pas un facteur 3/2!
C'est loin d'etre negligeable.

>Mais c'est lent.
Essaye Cf et dis moi si c'est lent.

>Parce que tu utilises des lignes et des cercles plutôt que des sprites pour tes personnages.
Faux. J'utilise des sprites pour mes personnages.

>C'est vrai, je préfère de loin Mario. Et c'est parti pour un autre flamewar.
C'est incomparable. Question de gout. Je prefere Sonic. Beaucoup plus de liberte.

>Et il y a quoi à part AMS? Pedrom? Déjà, ce n'est pas encore sorti, et puis c'est un clône incomplet de AMS.
Certes. Mais il existe aussi le PC.

>(Attention, je ne veux pas du tout démonter ton projet, tu as fait un travail excellent. Mais ça ne change rien au fait que ce n'est pas une plateforme vraiment différente par rapport à AMS.)
Oui.

>Et puis, "programmer en _nostub" ne veut pas forcément dire "programmer seulement pour AMS". La preuve: Backgammon marche très bien sous Pedrom.
Parce que j'y ai mis du mien

>Argh, tu deviens déjà comme TI, toi...
Je veux.

>Solution plus simple: sors tes sources, comme ça on pourra les recompiler s'il y a un problème. Si tu ne veux absolument pas les publier, envoie-les à une personne de confiance et qui reste dans la communauté.
C'est loin d'etre plus simple.

>Je sens que Thomas ne va pas aimer. Et moi non plus d'ailleurs. Le format PPG est là pour être respecté!
En quoi c'est de l'irrespect du format PPG ? Il n'a rien a voir la dedans.

>>C'est du vaporware, mon cher, cette techno la.
>GTC, GTools, Formula One... c'est du vrai vaporware.

>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
Je vois pas en quoi ca peut etre plus propre et mieux definis.

>Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ?
Je n'ai jamais donne de date de sortie.

>> Kerno est un kernel batard.
>C'est pas un kernel, surtout... "KerNO is an intentional misspelling of kernel" (readme de KerNO).
C'est un kernel. Preuves:
1. il utilise les vecteurs du kernel !
2. Toute routine de detection de kernel le detecte !

>Je n'ai pas que ça à faire, surtout quand je vois qu'il est bourré de conneries
Il ne tient qu'a toi de les corriger.

>En effet. Allez voir les comments du thread qui parle de CC sur TI-Net, avant qu'il y en ait un qui se rende compte qu'il y a une version _nostub... Il y a des trucs du genre "I'm not going to put an evil shell on my calculator just for that" (écrit tel quel si je ne me suis pas trompé; le 'evil shell' est écrit, en tout cas), ce qui est somme toute assez clair...
Oui. C'est un extremiste qui ne connait pas ce que le mot 'diable' signifie et qui l'utilise a tord et a travers.
Ou qui ne connait que Doorsos.

>Ca n'est pas sale. Ca fait gagner beaucoup de RAM, par contre... Du reste, XPort (un autre shell en grayscale), décharge aussi la plus grosse partie quand un programme est exécuté.
C'est pas tres propre.

>Je pense que PpHd qui dit que ce font les autres est sale, voit la paille dans l'oeil du voisin mais pas la poutre qui est dans son propre oeil...
Je n'ai jamais dit que le code que je faisais etait propre ! Je prefere Kevin.

>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...
Et ?
De toute facon, pour le moment c'est impossible de programmer specifiquement pour lui.

>En effet. Jamais ils ne signeront une horreur pareille.
Je ne leur demanderais jamais.

>Et puis ça serait trop bête de se limiter aux AMS 2.xx, sur lesquelles un certain nombre de programmes kernel-based ne fonctionne pas du tout...
Tiens ? Tu t'interresses a la compatibilite AMS 1.0x. Je croyais etre le seul.

>Je ne vais pas aimer non plus...
>De toute façon, il faut recoder l'algorithme, pour pouvoir le mettre on-calc: l'algo nécessite, en RAM, 128 KO + 15 * size of input...
>Autrement dit: faire une version différente, pas supportée officiellement... S'il y a des problèmes avec, on se fera un plaisir de dire que ça n'est pas de notre faute, mais celle de quelques personnes qui sont obsédées par les libs dynamiques...
On parlait du decompresseur on-calc.

> C'est buggue tout simplement. Il faut tester le materiel avant de changer ce port.
Bien. A ce moment là, sois sport: suggère à Greg Dietsche de changer ce qu'il a fait.

>>1. C'est tout bête. Il suffit de mettre #define EXECUTE_IN_GHOST_SPACE.
>Et cette astuce foirera lorqsue TI mettra plus de 256Ko de RAM.
>Remarque, ce sera pas les seuls programmes a ne pas fonctionner.
En effet. Les kernels eux-mêmes ne fonctionneront plus non plus...

>Les includes headers mettront cela de maniere transparente, et la lib complete est distribuee sous la forme d'une pack. Par exemple, mon portage de tigcclib en lib dynamique, sera une pack archive (tigcclib) contenant comme fichiers l'ensemble des fichiers objets de tigcclib.a.
Je ne savais pas que tu projetais de faire une telle horreur. Ne faut-il pas l'accord de la TIGCC Team, avant de faire cela. Et puis il y a des moyens simples de t'empêcher de faire ce que tu veux faire...

> Par ailleurs, il faudrait verifier si le code que j'ai fait de lecture des nombres reels (PedroM / EStack.asm) ne permettrait pas de reduire encore la taille du code (Plus d'appel a Atof).
Tu penses vraiment que le support pour PedROM sera ajouté dans TIGCC (à part peut-être pour détecter PedROM et ne pas exécuter le programme le cas échéant, autrement dit alourdir le code de startup pour un truc dont la majorité des personnes n'ont rien à faire) ?
Moi, je ne suis pas dans la TIGCC Team, je n'ai pas pouvoir de décision là-dessus, mais ça m'étonnerait. Et en tout cas, je ne suis pas spécialement favorable à un tel ajout.

>>Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ?
>Je n'ai jamais donne de date de sortie.
A ma connaissance, personne n'a donné de date de sortie pour le standard de commentaires _nostub.

>>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
>Je vois pas en quoi ca peut etre plus propre et mieux definis.
En tout cas, la spec du standard de commentaires _nostub est probablement plus claire et mieux définie que les super specs de certains trucs du kernel (au hasard, les RAM_CALLs de fonts)...

>>Quelle idée stupide!
>>Crois-tu vraiment qu'un nag screen de style shareware au début de chaque programme juste pour parler de ttstart à l'utilisateur soit une idée intelligente?
>Oui, sans aucune hesitation.
Moi aussi, je pense que c'est stupide. Ca bouffe de la place, ça ennuie l'utilisateur...

C'est quoi DrawFace ?

> Il ne tient qu'a toi de les corriger.
Il me semble que c'est ce qu'on est en train d'essayer de faire, dans les derniers posts de ces débat.

> Tiens ? Tu t'interresses a la compatibilite AMS 1.0x. Je croyais etre le seul.
Certainement pas. La TIGCC Team et TICT et d'autres tiennent à la compatibilité AMS 1.xx. Si ça n'était pas le cas, je ne me serais pas fait suer pendant des heures à trouver des wrappers pour que des fonctions qui ne sont dans la table de ROM_CALLs que sous AMS 2.xx ou même 2.04+, fonctionnent sur AMS 1.01 et 1.05 (et peut-être pour certaines sur AMS 1.00 92+, je ne peux pas tester).

>>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...
>Et ? De toute facon, pour le moment c'est impossible de programmer specifiquement pour lui.
Ca veut dire que ça va le devenir ? Incompatibilité power !

XDanger a écrit :
> C'est buggue tout simplement. Il faut tester le materiel avant de changer ce port.
Bien. A ce moment là, sois sport: suggère à Greg Dietsche de changer ce qu'il a fait.

Je lui ai envoye un mail.

>>1. C'est tout bête. Il suffit de mettre #define EXECUTE_IN_GHOST_SPACE.
>Et cette astuce foirera lorqsue TI mettra plus de 256Ko de RAM.
>Remarque, ce sera pas les seuls programmes a ne pas fonctionner.
En effet. Les kernels eux-mêmes ne fonctionneront plus non plus...

Mais ca sera facile de corriger les kernels pour faire fonctionner le reste.

>Les includes headers mettront cela de maniere transparente, et la lib complete est distribuee sous la forme d'une pack. Par exemple, mon portage de tigcclib en lib dynamique, sera une pack archive (tigcclib) contenant comme fichiers l'ensemble des fichiers objets de tigcclib.a.
Je ne savais pas que tu projetais de faire une telle horreur. Ne faut-il pas l'accord de la TIGCC Team, avant de faire cela. Et puis il y a des moyens simples de t'empêcher de faire ce que tu veux faire...

GPL powa !

> Par ailleurs, il faudrait verifier si le code que j'ai fait de lecture des nombres reels (PedroM / EStack.asm) ne permettrait pas de reduire encore la taille du code (Plus d'appel a Atof).
Tu penses vraiment que le support pour PedROM sera ajouté dans TIGCC (à part peut-être pour détecter PedROM et ne pas exécuter le programme le cas échéant, autrement dit alourdir le code de startup pour un truc dont la majorité des personnes n'ont rien à faire) ?
Moi, je ne suis pas dans la TIGCC Team, je n'ai pas pouvoir de décision là-dessus, mais ça m'étonnerait. Et en tout cas, je ne suis pas spécialement favorable à un tel ajout.

Tu n'as pas compris ce que j'ai dit. Je parlais de modifier les routines de scanf en utilisant le code que j'ai developpe.

>>Et si le standard de commentaires _nostub est du vaporware, PedROM, c'est quoi ?
>Je n'ai jamais donne de date de sortie.
A ma connaissance, personne n'a donné de date de sortie pour le standard de commentaires _nostub.

Kevin ne m'a rien repproche.

>>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
>Je vois pas en quoi ca peut etre plus propre et mieux definis.
En tout cas, la spec du standard de commentaires _nostub est probablement plus claire et mieux définie que les super specs de certains trucs du kernel (au hasard, les RAM_CALLs de fonts)...

Arg, tu m'en veux pour ces ramcalls ! Mais pourquoi tant de haine !

C'est quoi DrawFace ?

DrawPolygon.

> Il ne tient qu'a toi de les corriger.
Il me semble que c'est ce qu'on est en train d'essayer de faire, dans les derniers posts de ces débat.

Pas vraiment.

> Tiens ? Tu t'interresses a la compatibilite AMS 1.0x. Je croyais etre le seul.
Certainement pas. La TIGCC Team et TICT et d'autres tiennent à la compatibilité AMS 1.xx. Si ça n'était pas le cas, je ne me serais pas fait suer pendant des heures à trouver des wrappers pour que des fonctions qui ne sont dans la table de ROM_CALLs que sous AMS 2.xx ou même 2.04+, fonctionnent sur AMS 1.01 et 1.05 (et peut-être pour certaines sur AMS 1.00 92+, je ne peux pas tester).

Mais est-ce necessaire ?

>>Oui, mais programmer spécifiquement pour PedROM veut dire programmer pour une petite minorité de gens...
>Et ? De toute facon, pour le moment c'est impossible de programmer specifiquement pour lui. Ca veut dire que ça va le devenir ? Incompatibilité power !

Mais non. Y'aura les kernels pour rajouter une couche d'emulation

Et puis, CC n'utilisait aucune librairie dynamique, donc ça n'a aucun rapport avec les librairies dynamiques ou statiques. C'est juste une question de relogements.

c'est déjà ca! Imagine le gain de place si tigcclib était une lib dynamique .

Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib.

L'inverse est aussi vrai!

J'avais dit cela de manière totalement objective. Ça ne sert à rien parce que au moins 95% des jeux sur TI-89/92+/V200 n'ont aucune difficulté à atteindre les 10 fps nécessaires pour obtenir la fluidité. ExtGraph est suffisamment rapide.

Oui mais les 5% de jeux qui restent valent plus que tes 95% de jeux restants

Donc plus de kernel en développement? Dans ce cas, il suffira que TI sorte une mise à jour qui empêche à PreOs et Universal OS de fonctionner, et hop, plus de mode kernel. Et donc les programmeurs en mode kernel, auxquels on a promis (à tord) qu'ils ne devront "jamais" recompiler leurs programmes, seront tous obligés à les recompiler... en mode _nostub.

PreOS est open-source non? N'importe qui d'assez doué pourra faire les modification nécéssaires.

Peut-être, mais la différence de taille ne vient pas de là.

Bien sur le kernel permet bien plus de chose.

Comme la taille horizontale a diminué dans mon exemple, ça ne donnera rien de lisible. Et puis, on peut faire exactement la même chose en _nostub.

tant pis dans le cas d'un écran plus petit(ce dont je doute fortement), il faudrait tronquer. Et en Nostub il faudrait rajouter un patch ou une des nombreuses TSR qu'il faut ajouter pour "approcher le format du kernel.

Je parlais de la comparaison DLL Windows / DLL kernel, pas des DLLs _nostub.

ha d'accord, dans ce cas la c'est en effet comparable.

En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça.

Et c'est monsieur je désassemble des routines de gray qui nous dis ca!

> Je lui ai envoye un mail.
C'est bien. Je n'en attendais pas moins de toi, qui es en général sympa avec les autres (malgré les séquences 'spécial énervement du Kevin'...).

>>Et puis il y a des moyens simples de t'empêcher de faire ce que tu veux faire...
>GPL powa !
Certes. Mais ce que j'ai dit reste (par exemple passer tigcc.a au-dessus de 64K, même compressé; d'accord, on ne le fera pas exprès juste pour t'embêter, mais c'est possible, par exemple en incluant ExtGraph dans TIGCCLIB).

> Arg, tu m'en veux pour ces ramcalls ! Mais pourquoi tant de haine !
Je ne t'en veux pas à toi, j'en veux aux RAM_CALLs, ce qui n'est pas tout à fait la même chose... Et je ne les aime pas car ils sont lents, ils ne reflètent pas ce que l'utilisateur peut faire sous AMS 2.xx.
Un truc que tu pourrais faire, au lieu de rechercher le sprite, c'est un OO_GetAttr/OO_CondGetAttr des attributs 0x300, 0x301 et 0x302, dans OO_SYSTEM_FRAME (0xFF000000). Ca serait plus propre et plus rapide...


>>C'est quoi DrawFace ?
>DrawPolygon.
OK.

> Mais est-ce necessaire ?
Peu de programmeurs les utiliseront. Mais le but, c'est d'être une doc complète, la plus complète possible par les descriptions de fonctions et par le nombre de fonctions/variables. TIGCCLIB est très au-dessus de tiams.h/TIFS/la doc de TIFS là-dessus (sauf pour des topics qui n'intéressent presque personne dans TIGCC, notamment les FlashApps).

> Mais non. Y'aura les kernels pour rajouter une couche d'emulation
Super !


> PreOS est open-source non?
Encore heureux ! Il est temps que le closed source s'arrête, dans le bien de la communauté toute entière...

>Et en Nostub il faudrait rajouter un patch ou une des nombreuses TSR qu'il faut ajouter pour "approcher le format du kernel.
Et quel intérêt ? Le format kernel a des avantages, mais il a le lourd inconvénient de n'être utilisé que par une minorité, et de nécessiter un kernel (= pas de lancement possible sans kernel installé, ce qui n'est pas le cas des programmes _nostub, qui nécessitent parfois un décompresseur, mais c'est tout)...

>>En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça.
>Et c'est monsieur je désassemble des routines de gray qui nous dis ca!
Peux-tu dire quel rapport il y a entre les deux phrases, s'il te plaît ?

Et je ne les aime pas car ils sont lents, ils ne reflètent pas ce que l'utilisateur peut faire sous AMS 2.xx.
Les accès aux attributs d'applications sont aussi très lent (quoi qu'ils ont mis en place un table de hachage pour accélerer la lecture des attributs qui étaient souvent accèdés, j'ai trouvé ça marrant que pour une fois TI optimise un peu quand je suis tombé là-dessus ).
Et qui modifie ses fonts de toute façon ?

XDanger a écrit :
>>Et puis il y a des moyens simples de t'empêcher de faire ce que tu veux faire...
>GPL powa !
Certes. Mais ce que j'ai dit reste (par exemple passer tigcc.a au-dessus de 64K, même compressé; d'accord, on ne le fera pas exprès juste pour t'embêter, mais c'est possible, par exemple en incluant ExtGraph dans TIGCCLIB).

Je ferais 2 libs alors. tigc1lib et tigc2lib. Facile.

> Arg, tu m'en veux pour ces ramcalls ! Mais pourquoi tant de haine !
Je ne t'en veux pas à toi, j'en veux aux RAM_CALLs, ce qui n'est pas tout à fait la même chose... Et je ne les aime pas car ils sont lents, ils ne reflètent pas ce que l'utilisateur peut faire sous AMS 2.xx.

J'ai propose de rajouter d'autres RAM_CALL.

Un truc que tu pourrais faire, au lieu de rechercher le sprite, c'est un OO_GetAttr/OO_CondGetAttr des attributs 0x300, 0x301 et 0x302, dans OO_SYSTEM_FRAME (0xFF000000). Ca serait plus propre et plus rapide...

Marche pas sur AMS 1.0x

> Mais est-ce necessaire ?
Peu de programmeurs les utiliseront. Mais le but, c'est d'être une doc complète, la plus complète possible par les descriptions de fonctions et par le nombre de fonctions/variables. TIGCCLIB est très au-dessus de tiams.h/TIFS/la doc de TIFS là-dessus (sauf pour des topics qui n'intéressent presque personne dans TIGCC, notamment les FlashApps).

Ils manquent quand meme plein de trucs.

Le format kernel a des avantages, mais il a le lourd inconvénient de n'être utilisé que par une minorité, et de nécessiter un kernel (= pas de lancement possible sans kernel installé, ce qui n'est pas le cas des programmes _nostub, qui nécessitent parfois un décompresseur, mais c'est tout)...

L'avant-derniere version de PreOs supporte l'auto installation du kernel.

>>En le compilant en une librairie dynamique? Thomas va te tuer si tu fais ça.
>Et c'est monsieur je désassemble des routines de gray qui nous dis ca! Peux-tu dire quel rapport il y a entre les deux phrases, s'il te plaît ?

Ben tu sais bien que TN a dessassembler les routines de gray d'UniOs pour tigcclib sans demander l'autorisation de JM (Qui a ete obblige de la donner apres parce que sinon ca mettrait un beau bordel). Donc lui gueuler parce que je prend ces routines qu'il a place en 'je-sais-pas-trop-quoi' licence, humhum