Je rappelle juste que je boycotte les programmes 'nostub' sur ma calc (sauf un).
>>et l'anticrash il sert a quoi?
>À rien. Il laisse la calculatrice dans un état instable
1. Rien que pour ceux qui developpe, l'anticrash a eviter d'archiver/desarchiver sans arret leurs sources et tester leur programmes.
2. L'anticrash de Preos rend souvent la calc dans un etat tres stable.
>Une librairie dynamique est une perte de place, pas un gain de place, par rapport à une librairie statique.
Tiens en furetant sur le net j'ai trouve la secte des adeptes des libraries statiques dont voici le gourou : Richard A. Burgess
>Ceux qui prétendent que c'est un gain oublient que la taille des librairies fait partie de la taille du programme, qu'elles soient statiques ou dynamiques.
Et toi tu oublies toujours qu'on ne les compte qu'une et seule fois.
>Arrête de changer d'avis tous les 6 mois et d'insulter tout le monde qui ne partage pas ton avis de la saison. Il y a quelques mois, tu disais exactement le contraire. C'est quoi qui t'a fait changer d'avis?
LOL. Tu connais pas encore Timad ?
>Avec une librairie statique, seules les fonctions réellement utilisées se retrouveront sur la calculatrice.
Faux. Seuls les fichiers objets rellement utilises sont sur la calculatrice
Donc ca obblige au passage a faire des sauts longs entre les fichiers objets.
>2 * la taille de genlib - la taille du kernel de différence.
+ La taille de ttstart
>genlib n'est pas du tout optimisée en taille,
Faux. Genlib est optimise en taille et en vitesse. Sinon je vois pas pkoi je ferais du self modifing code pour reduire la taille.
>PpHd dit que "de toute façon il n'y a qu'une copie, donc on se fiche de la mémoire gaspillée"
Je n'ai jamais dit ca. Genlib fait partis des libs consommant le moins de memoire (contrairement a Xlib ou GraphX) contrairement aux idees recues. (Mais plus qu'extgraph, ca te va ?).
>Une librairie statique gaspillera nettement moins de place.
Avec un programme, avec une librarie, oui.
Mais avec 2 programmes, la non.
(Tu fais toujours la meme erreur, c'est lassant).
>Il n'y a pas de double-buffering automatique
HumHum. Il manque le timer... Et c'est tout pour que ca soit niquel.
>il y a une tentative de rajouter un support pour du double-buffering de manière sale, en permettant au programme de changer les adresses des plans, de la part de PpHd, mais seulement dans PreOs, et puis ce n'est pas du double-buffering automatique
Faux. C'est dans Teos, DoorsOs et Unios aussi. C'est TRES standard.
>pas de synchronisation
Tu en veux ? En 1 minute je te l'ajoute.
>Plus de la moitié de ses fonctions ne sont que des wrappers autour de ROM_CALLs ou des réimplémentations de ROM_CALLs.
Les fonctions bitmap/ligne sont au moins 8x plus rapide que les fonctions Bitmap/ligne d'AMS.
>c'est une implémentation médiocre des niveaux de gris
En bon francais, on dit Implantation
> mais aussi un gaspillage de mémoire absurde.
500 octets de perdus (si mes souvenirs sont bons).
>Mais bon, l'anticrash _nostub de PreOs marche très bien. (Normal, ce sont ExtendeD et moi qui avons codé la moitié. PpHd n'était pas très motivé là-dessus. Moi si. )
Hum... Tu es de mauvaise foi. Tu as fait la restauration des TSR apres le crash. Extended a fait la liberation des DupScreens. J'ai fait tout le reste ce qui n'est pas rien.
>Enfin, j'avoue que je ne sais pas exactement ce qu'il fait, ni ce qu'il ne fait pas. Donc peut-être qu'il a des trucs que PreOS ne fait pas. Mais dans le cas contraire, je ne vois vraiment pas pourquoi ce programme existe (et ne réponds pas : "pour gagner 5 ko")
+ Il fait la remise a jour du timing de la RAM apres le trap #4 (Source de plantage a mon avis, car il ne teste pas l'etat des piles).
+ Il fait un Heap Check pour verifier si la Heap est corrompu apres un plantage et t'avertir (Interet reel ?)
>Le résultat est simple : dans un cas le programme est autonome, dans l'autre il ne l'est pas.
Je peux te pondre du kernel qui s'execute directement !
Et je te rappelle que la plupart des programmes nostub sont :
+ compresse : donc il faut un lanceur, donc ce n'est plus autonome.
+ >24K : Donc il faut un lanceur sur AMS 2.0x.
>C'est clair. Moi, de toute façon après un "Crash Intercepted", je reset toujours la TI (après avoir archivé les quelques trucs que je veux garder et qui ne l'étaient pas déjà)
D'ou l'interet de l'anticrash !!!!!!
>La calculatrice peut planter à tout moment, même avec un anticrash! Il faut donc toujours archiver les fichiers qu'on veut garder!
Meme avec AMS seulement. Ca tombe bien Preos recupere meme les bogues d'AMS.
Et parfois on modifie sans arret un fichier. donc on n'a pas interet a l'archiver tout le temps.
>La seule fonctionnalité en moins, c'est le support pour un format de programmes dépassé (émulation Fargo, appelée aussi "mode kernel").
Desole de te contredire, mais "l'emulation fargo" comme tu l'appelles n'emule aucun programme ecrit pour Fargo.
>>de plus su tu ajoute la compression, il faut ajouter le decompresseur...
>Pour les 2 versions (_nostub, kernel), donc ça s'annule quand on fait la différence.
Pas tout a fait.
Le decompresseur kernel peut etre lui meme compresse par une autre lib plus petite
>Des librairies comme XLib ou genlib ne sont pas suffisamment flexibles pour convenir pour tous les usages.
Je n'ai jamais dit que genlib servait a autre chose qu'a faire des jeux !
Liste des jeux/programmes sortis avec genlib :
+ SMA
+ CF
+ Total Destruction.
+ Pokered
+ Kirby
+ Mapmaker
+ sprmaker
+ Small
Et y'a encore plein de jeux qui ne sont pas encore sortis mais qui l'utilisent (megaman, seiken, Super Monster anhiliation, ...)
>Le meilleur jeu de tous les temps existe déjà et n'a pas besoin de kernel.
Tout le monde n'a pas les memes gouts.
>ce n'est pas dépassé, puisque c'est encore utilisé
>et c'est encore moins dépassé, vu que c'est encore en évolution
Clap Clap.
>>ça risque pas dendommager la flash que d'archiver sans cesse ?
>Non.
Je ne suis pas sur. Le segment de Garbage risque d'avoir une usure bien superieure aux autres segments...
>>ce n'est pas dépassé, puisque c'est encore utilisé
>DOS est encore utilisé, donc DOS n'est pas dépassé???
>Ce n'est pas parce que quelque chose est encore utilisée que ce n'est pas dépassé.
Si on recherche un systeme ne consommant pas de ressources pour rien, alors non, DOS n'est pas depasse.
>>et c'est encore moins dépassé, vu que c'est encore en évolution
>DOS est encore en évolution, donc DOS n'est pas dépassé???
>Il y aura toujours des nostalgiques (comme PpHd, ou comme les développeurs de FreeDOS) qui
>feront évoluer les systèmes totalement dépassés.
Pour moi, c'est le format _nostub, le truc archaique. Y'a rien dans ce format.
De la relocation ! C'est tout. La belle affaire. Et la tigcc team doit rajouter des disaines de patche pour faire le loader 'nostub'....
Qui essaye de faire evoluer son format vers le format kernel ? Qui a rajoute les DLL parce qu'il bavait devant les brillantes libraries kernels ?
Pas le kernel...
>Le système de kernels et de librairies dynamiques a été créé:
>- pour remplacer les ROM_CALLs, mal documentés à l'époque. Ce n'est plus le cas depuis
>janvier 2000 (sortie de la documentation de TIGCC).
>- pour faciliter le portage des vieux programmes Fargo.
C'est COMPLETEMENT FAUX ! Le kernel a ete cree :
+ Pour le support des libs dynamiques.
+ Pour eviter d'avoir ce support dans chaque programme.
+ Pour mettre a jour facilement le kernel.
>Il n'y a vraiment pas de raison de le ressortir pour lui faire faire plein d'autres choses pour lesquelles il n'est pas prévu et pour lesquelles il y a des solutions meilleures (librairies statiques, fichiers de données externes etc.).
Developpe plus.
>Je ne vois pas la différence fondamentale entre les 2 classes de librairies que tu distingues. La seule différence est que ExtGraph est plus flexible et que ses fonctions sont suffisamment bien conçues pour ne pas être interdépendantes. On peut faire un jeu avec exactement la même facilité qu'on utilise une librairie de style ExtGraph ou une librairie de style genlib.
Justement. C'est ca le probleme. Tu ne vois pas.
>Une librairie conçue de la même manière que ExtGraph (statique, fonctions indépendantes entre elles), mais avec des routines clippées, serait suffisamment flexible pour convenir pour pratiquement tous les jeux que j'ai vus. Les routines de sprites clippées sont la seule chose qui manque à ExtGraph.
Faux. Demande a squale. Faudrait supporter les ecrans virtuels de differentes tailles en plus. Et ce n'est qu'un ajout.
>Non, je dirais même que c'est plus simple avec ExtGraph. Quand j'essaie de bencher une fonction que j'ai écrite avec les fonctions déjà existantes d'ExtGraph ou d'Xlib ou de GraphX, pour comparer avec ExtGraph, ça met 2 secondes, il n'y a qu'à trouver la fonction équivalente, mais avec les autres libs, je suis obligé de regarder la doc parce qu'il y a toujours plein de trucs à faire pour initialiser la lib allouer un écran virtuel, puis le sélectionner, etc...
Avec Extgraph tu dois initialiser les niveaux de gris, allouer un deusieme ecran virtuel pour le Double Buffering, selectionner l'ecran virtuel correspond, puis utiliser l'appel de fonctions ? Ou est la difference avec une autre lib ?
Que Extgraph est plus flexible dans le nombre de ces parametres. Oui. Mais plus lourd aussi (Le prix a payer pour tous ces arguments). Et puis perso j'utilise aussi extgraph de temps en temps, donc je ne la critique pas.
>Ce ne sont pas des programmes DOS, ce sont des programmes console Win32.
Les programmes console win32 sont plus chiants que les programmes dos.
Au moins, les progs dos n'effacent pas automatiquement la fenetre texte apres leur fin.
>genlib essaye un peu de "faire le café" et ce n'est pas vraiment une bonne idée. Pour l'allocation de mémoire, les fonctions de la ROM marchent très bien si on les utilise correctement (c'est-à-dire si on n'alloue pas 10000 nœuds de listes chainées dans des blocs séparés).
Ben oui. Mais dans le cas contraire, lorsqu'on A BESOIN de faire des allocations/desallocations de maniere tres intensives, genalib est LA solution a vos problemes. Je vous rappelle que Nitro/Dark Angel ont boostes les performances de leurs programmes de 50% juste en remplacant malloc par geanlib__alloc (attention il ne s'agissait pas dee programmes de bench mais de vrais programmes)... ce qui laisse imaginer le gain de vitesse reel entre les deux fonctions.
>Et il y a plein de solutions pratiques pour gérer le clavier (_keytest de TIGCCLIB par exemple.
Le Joypad est bien plus pratique. Sur V200, le joypad de genlib a ete adapte suivant la config de touches pour ne pas utiliser F1...F8, mais des touches bien plus pratiques.
Et cela, tout en restant compatible avec la premiere version de genlib qui date de plus de 3 ans.
>Mais genlib ne te permet pas de faire cela, mais t'oblige à utiliser son propre joypad...
Tu es assez grand pour le faire toi meme. Moi j'en propose un bien concu, et utilisable immediatement.
>Là, c'est un effet purement matériel, et je ne vois pas en quoi l'utilisation de genlib y changerait quelque chose.
Peut etre un choix des touches judicieux qui empechent l'apparition de touches fantomes...
>Et ben, tu le rediriges. Mais tu ne peux pas utiliser une lecture de clavier bas niveau quelle qu'elle soit avec l'AI5 de AMS qui tourne, sinon les bogues sont garantis (le curseur vers le haut est pris pour [ESC] et des trucs du genre).
Si tu peux. Tu fais un OSSetSR(0x500); avant puis un OSSetSR(0x0000); apres.
Et d'ailleurs je pense que c'est mieux car tu laisses tourner certains timers importants (les ramwaits par exemple).
>_keytest et les pseudo-constantes RR_... de compat.h sont faits pour ça.
Bonjour la taille du code genere.
>n'importe lequel d'ailleurs - ExtGraph est suffisamment flexible pour cela; il y a même des gens qui utilisent des routines de ExtGraph sur les DScreens de genlib),
Ce qui prouve que genlib est extgraph sont parfaitement compatibles
>Mais XLib et genlib sont loin d'être des librairies de jeux complètes. Ce sont juste des librairies graphiques auxquelles on a rajouté quelques fonctions par ci, par là pour "faire le café", alors qu'il y a des solutions meilleures pour la même chose (test de touches par exemple - il y a plusieurs méthodes, toutes plus flexibles que le joypad de genlib).
Demande a PAD s'il ne pense pas que genlib est une librarie de jeux.
Bon une librarie graphique orientee jeux, ca te va ?
Et je prefere 100x le joypad de genlib a ton keytest.
Une librairie graphique est quelque chose comme ExtGraph. Une librairie qui gère tout d'un jeu est quelque chose de différent. On peut l'appeler "librairie de jeux" par exemple, mais certainement pas "librairie graphique".
6 d'un coup, c'est pas mal !
