genSlib (Genesis Static Library) - Page 2

>PpHd: C'est comme je t'ai deja dit. Les static optimisent la place pour un progamme. Or l'optimisation maximale de chaque programme n'est pas recommande pour que leur somme soit minimale.

1. Mes calculs ont montré que même en présence de Total, SMA, Chrono et un hypothétique Pang d'Aghnar converti pour genlib, en admettant que les estimations de Dark Angel sur le pourcentage d'utilisation de genlib par les programmes soient à peu près correctes, convertir genlib en librairie statique permettrait d'épargner 1 KO.

2. Dès que tu parles de somme, tu présumes déjà qu'il y a quelque chose à sommer! Il faudrait peut-être éviter de partir du principe que tout le monde a plusieurs jeux utilisant genlib sur sa calculatrice.
Regarde cette configuration hypothétique, mais tout-à-fait plausible:
* maxmem ou hw2patch: 2 KO
* Universal OS: 12 KO
* petit jeu utilisant 30% de genlib: 20 KO
* petit jeu utilisant 40% de genlib: 15 KO
* genlib: 17 KO
* 3 jeux utilisant graphlib pour les niveaux de gris uniquement: 50 KO
* 10 jeux en _nostub+ExePack: 200 KO
* 5 petits jeux en _nostub non compressé: 50 KO
* 7 utilitaires résidents en mémoire en _nostub (gardés en archive pour d'éventuels plantages): 50 KO
* utilitaires de mathématiques et de physique en TI-BASIC: 150 KO
* lecteur d'e-books: 8 KO
* e-books divers: 50 KO
* utilitaires divers (par exemple organizer, ...) en TI-BASIC: 16 KO
Total: 640 KO, archive pleine
(Non, ce n'est pas la mienne, ni celle de quelqu'un que je connais, mais juste un exemple que je viens d'inventer.)
Faut-il vraiment que je te calcule l'espace gaspillé dans cette configuration par le fait que genlib et graphlib sont des librairies dynamiques?
[edit]Edité par Kevin Kofler le 15-06-2001 à 22:06:44[/edit]

PPHD,Vu k ca apparait mort pour genSlib, tu pourrais pas ameliorer extgraph en faisant du copier coller a partir de tes sources (avec quelques motifs bien sur ) ?

Kevin Kofler & Aghnar > pkoi croire que les libe c'est pas efficace.

essayons d'imaginer windows sans DLL.

voyons voir pour faire un simple logiciel par exemple un browser web.

sans librairies de A à Z donc : des mois de travail intensif, il faut tout refaire (IO, cad TCP/IP, graphisme, TOUT) prog de 5mo, programme tres incompatible etc..

avec librairies DLL : quelques semaines de travail, application de 300ko.

est-ce un cas extreme ?

>Kevin: Ton programme sera plus facile a faire que le mien.
>Kevin: Tes calculs sont faux car tu ne tiens pas compte de l'architecture interne de genlib.

>maxmem ou hw2patch: 2 KO
Tu peux l'enlever une fois installe.
Ca sert plus a rien !

> Universal OS: 12 KO
Ttttt.

> petit jeu utilisant 30% de genlib: 20 KO
> petit jeu utilisant 40% de genlib: 15 KO
J'aime bien le terme 'petit'

> genlib: 17 KO
Tadam !

> 3 jeux utilisant graphlib pour les niveaux de gris uniquement: 50 KO
Ok.

> 10 jeux en _nostub+ExePack: 200 KO
Et le lecteur de Exepack ?

> 5 petits jeux en _nostub non compressé: 50 KO
Mettons.
Mais perso j'ai aucun jeu nostub sur ma calc.

> 7 utilitaires résidents en mémoire en _nostub (gardés en archive pour d'éventuels plantages): 50 KO
Ok. (J'en ai aucun).

> utilitaires de mathématiques et de physique en TI-BASIC: 150 KO
Ok.

> lecteur d'e-books: 8 KO
>e-books divers: 50 KO
Ok (Jamais essaye).

> utilitaires divers (par exemple organizer, ...) en TI-BASIC: 16 KO

> Total: 640 KO, archive pleine
Ok.
>(Non, ce n'est pas la mienne, ni celle de quelqu'un que je connais,
> mais juste un exemple que je viens d'inventer.)
J'ai remarque. Y'a des incoherences.

>Faut-il vraiment que je te calcule l'espace gaspillé dans cette configuration
>par le fait que genlib et graphlib sont des librairies dynamiques?
Forcement.
5 jeux kenrel contre 15 jeux nostub.
Si les jeux nostub utilisaient graphlib et genlib,
on economiserait vraiment de la place.
Je suis pas sur que ca soit un bon exemple.

Sinon, tu connais Runc ?
Il fait la compression des libraries dynamiques => Genlib + graphlib + ... + TOUTES LES LIBS POSSIBLES en 30 Ko.
Il fait la compression des programmes Ti-Basics en multiples archives.

Resultat :
Si t'avais choisis la config kernel + runc, tu aurais economise plus de places, et ca serait compatible avec plus de calcs.

>Si t'avais choisis la config kernel + runc, tu aurais economise plus de places

D'abord, tout le monde n'a pas 20 jeux sur sa calculatrice comme dans l'exemple. Mais revenons à notre exemple: Qui a dit que tous ces jeux étaient en niveaux de gris? Un jeu peut être en blanc et noir et se servir uniquement des ROM calls. Dans ce cas, n'importe quelle librairie graphique serait un gaspillage vu que les fonctions sont déjá dans la ROM. De plus, le grayscale support de TIGCC prend 1 seul KO. Si la seule fonction hors ROM utilisée est l'usage des niveaux de gris, même pour 17 jeux, la place utilisée serait moins que la taille de genlib, et si en prend en considération genlib+n'importe quel kernel, il faudrait plus que 20 jeux pour qu'utiliser genlib pour les niveaux de gris uniquement soit profitable, ce qui n'est pas le cas dans cet exemple.

>et ca serait compatible avec plus de calcs.

Lesquelles? Ta calculatrice bidouillée?
Non, franchement, les programmes en _nostub marchent en général sur toutes les calculatrices sauf les TI-92+ AMS 1.00, et les miens marchent même sur cette version, alors que DoorsOS et certains jeux ou autres programmes ne la supportent pas (à cause des ROM calls manquants).
Je ne connais aucun cas reporté où un de mes programmes ne marchait pas et où il ne s'agissait pas d'un bogue stupide que j'ai pu corriger en quelques minutes.
De plus, les programmes en _nostub marchent même sur HW2 AMS 2 non patchée. (Dans le cas de mes TSRs, j'intègre mon propre support de TSRs en un fichier .h qui fonctionne à peu près de la même manière qu'une librairie statique et qui ne prend que 450 octets.)
Si les programmes en _nostub ne marchent pas sur ta calculatrice, je suis désolé, mais il suffisait de ne pas rajouter de la mémoire ou n'importe quel autre type de matériel sur la plage d'adresses $40000-$fffff, ou $40000-$1fffff pour être vraiment sûr. Et puis, même dans TeOS, on peut lire: lea $40008,a1 pour modifier les interruptions...
[edit]Edité par Kevin Kofler le 18-06-2001 à 13:06:25[/edit]

Quel duel au sommet !!

Un extrait de tigcclib traduit : "Les fonctions graphiques de Ti sont tres tres lentes".
C'est pas moi qui l'ai dit, c monsieur Z.

Donc il faut des routines performantes.
Par ailleurs, mais 90% des jeux sont en niveau de gris. Ce chiffre est peut-etre faux, mais je le pense seieusement.

Je suis d'accord qu'utiliser Genlib rien que pour les niveaux de gris seraient du gaspillage. Mais on peut aussi faire du recentrage d'image, du scrolling, de l'affichage, du linkage, bref, tout le truc de Genlib. Oui mais le prog n'en a pas besoin. Oui, mais alors il pourra ameliorer son prog apres.

Par ailleurs, genlib peut etre archive pour economiser de la place :P

Ta calculatrice bidouillée?
Oui effectivement. C assez frustrant de devoir toujours editer les prog. Si il y avait une lib en dynamque, je n'aurais eu qu'a le faire une fois.

Mais j'avais envie de rajouter de la memoire sur ma calc, et ou voulait tu que je la mettes ?
Et puis pour Teos, j'ai corrige chez moi.

Il n'a ete ecrit nulle part dans les docs de Ti, que la plage d'adresses $40000-$fffff, etaient un mapping de la zone precedente. Ca peut tres bien changer.
Et ca sera source d'incompatibilite.

>pphd :
tu ne me réponds pas. Vas tu booster extgraph ?

>Segaman et tous les autre ki croit k je suis "anti lib" :

je n'aime pas le concept de librairies statiques, je prefere (comme la majorité des programmeurs)
le concept des librairies dynamiques.
Je pense que pour tout programmeur qui se respecte, l'avantage des librairies dynamiques est une evidence, il n'ya pas besoin de disserter 15 ans la dessus.

Maintenant, tout ceci appartient à la théorie.
En pratique, les choses varient, et s'adaptent à la plateforme concernée.

En effet, si sur PC, la gestion des librairies est quasi transparentes, gérees par un OS multitache
tres puissant (windows, ou linux pour ceux ki préfèrent) et k l'installation d'un jeu se résume
à cliquer sur install.exe et à suivre les instructions qui suivent, sur TI la gestion des librairies et des OS se fait par l'utilisateur,
c'est à dire bien vérifier si telle ou telle librairie est la bonne, verifier les versions
(en + il ya eu 36 versions mais elles ne sont sont pas indexées...), réinstaller l'OS apres chaque plantage... (imaginez vous à réinstaller windows apres chaque reset !!)

Enfin sur TI il n'y a pas de developpeur professionnel, ce ki fait k de nvx shells, librairies ou kernels meurent et naissent à chaque nouvelle evolution de la TI (au niveau hardware ou software)
car les programmeurs sont des etudiants et generalement arrivent tres vite à un stade ou ils doivent quitter la communauté TI.

Pour moi ce n'est pas un probleme, je suis l'actualité de pres comme tous ceux ki participent à ce forum, je n'ai d'ailleurs jamais lutter pour installer tel ou tel programme.
Le probleme se situe au niveau du grand public, des utilisateurs, ki eux sont intéressés par les programmes (plutot les jeux)
mais ne sont pas forcément au courant des kernels, des patchs, des libs à appliquer pour faire fonctionner le jeu.

A l'epoque de fargoII, je me rappelle k c'etait la croix et la banniere pour expliquer comment installer des jeux à mes potes, et bien souvent je m'occupait de tout à leur place, le probleme c k ca plantait souvent et k tres vite ils ont prefere
ne pas installer de jeux pour pas perdre leur pompes ou autres.

Avec l'evenement du nostub, j'ai meme eu du mal à leur expliquer comment lancer un programme
nostub compressé. Ils me posaient à chaque fois les memes questions :

"C koi la syntaxe deja pour lancer le jeu ,unpacker("pang") c ca ? parck j'ai oublié "
"C koi ppg ? C pas de l'assembleur alors ?"
"MAis comment ca se fais k'il ya pas besoin de doors ?"
"Le programme marche meme en archive ? "
"C koi les fichiers INI ou HSC ki sont arrivés dans le VAR LINK ? C pas des virus j'espere !"
"T sur k je peux avoir des jeux sur ma 89 ? parck k'un copain a dit que m'a TI on pouvait pas installer doors dessus" (le syndrome HW2)
"Non je veux pas de jeux avec doors ca plante tout le temps j'ai pas envie de paumer mes programmes ou de bousiller ma calc" (la stabilité de doors est passé à la postérité)

Bon y en a bien sur d'autres mais je vais m'arreter la.
Ils posent effectivement des questions supra debiles, mais tout à fait légitimes pour des gars ki ne se servent de leur ti k pour les maths et les pompes.
Ce sont loin d'etre des neuneus, simplement ils ne sont pas informé et c'est donc la galère pour eux de faire fonctionner un jeu.

Donc, sur TI je pense que le nostub est evidemment bien plus intéressant au nivo grand public
et utilisateurs.
Bloozed resume d'ailleurs tres bien ce probleme du grand public :
"Le choix du nostub pour un jeu peut se justifier de façon très simple depuis quelques temps :
sur ticalc.org, qui est le plus gros site de download TI, les programmes nostub sont accessibles dès l'entrée dans la section "games", alors que les programmes
kernels nécessitent en plus de penser à cliquer sur la sous-section "doorsos",
sachant que minimum 50% des gens ne savent pas ce que c'est à priori"

C bien de se baser sur des OS et des libs, mais la TI n'est pas du tout adpatée
à ce genre de systeme. Le seul truc ki serait bien ce serait un truc style Gtools, ki remplacent vraiment le TIOS et s'incruste dans la flash, gerant toutes les bibliotheques possibles de facon transparentes.
Maintenant, tout le monde sait k ce style de projet est irréalisable sur TI (enfin je parle surtout de Gtools, ki annonce des caractéristiques proches du portnawak meme si je ne remet pas en cause le projet et son auteur Pollux Troy)

Bref :

Les kernels et les librairies dynamiques oui c bien en théorie, mais sur TI c'est un beau bordel !

Nostub definitely rules !

Non, je n'ameliorerais pas ExtGraph.
C pas a moi, et je ne peux rien y faire.

Je trouve perso que les kernels et les libs sont tres clean. Ce qu'il manque, c un verificateur automatique de numero de version. Ok je l'avoue. Et franchement le nostub me fait CHIER, car c'est la que c'est le veritable bordel.

Je crois k tu es le seul à avoir une TI modifié ou le nostub marche pas !
Je suis d'accors ,je le répète, k le kernel et les libs c'est tres propre, mais c pas cool pour le grand public... (cf mon post précédent)
[edit]Edité par Aghnar le 18-06-2001 à 16:06:15[/edit]

M'en fous. Dans mon univers, qui est ma realite avec ma verite, c ma ti qui est la + importante de toutes les ti.

arf..

oui le nostub a pas mal apporté de merdes, surtout des progs de 20ko pour un helloworld

tant que y a qu'un kernel et des libs a installer + un browser qui gere la compression et l'archivage ben je trouve que c'est tres simple, ce que je trouve complique c'est les jeux qui ont plusieurs fichiers ça le grand public y est inpropice: sprit_a.89z sprit_b.89z, level1.89_z, lib_a.89z, end.89z, menu.89z etc etc
vive le static comme la GB, mais avec les libs pour économiser un max de place et faciliter les choses pour les programmeurs.
je vous raconte pas le plaisir intense quand j'ai découvert graphlib & util quand j'ai commencé l'ASM, bien sur c'etait le bordel, graphlib est nul est lent, si j'était tombé sur genlib si ça existait ça aurait été autre chose :-) (bien que genlib ne soit pas du tout significatif pour un débutant).

enfin je veux dire fo vraiment le savoir que genlib c'est une lib pour faire des jeux ! et meme avec un pseudo pareil !!!

Ben genlib c pour les fans de snes et de genesis

>segaman: oui le nostub a pas mal apporté de merdes, surtout des progs de 20ko pour un helloworld

Il est où ton "hello world" de 20 KO???
À moins de mettre des instructions inutiles exprès, je ne vois pas comment un "hello world" peut dépasser 2 KO, même en C, en _nostub et en niveaux de gris. En blanc et noir, même en C _nostub, le programme sera toujours largement inférieur à 1 KO! Et il n'aura besoin que de AMS, qui est déjà installé sur toutes les TI-89/92+, pas d'un kernel et/ou de librairies dynamiques à installer en plus et qui remplissent de la mémoire supplémentaire (par exemple 12 KO pour Universal OS qui inclut les librairies dynamiques les plus communes).

>segaman: je vous raconte pas le plaisir intense quand j'ai découvert graphlib & util quand j'ai commencé l'ASM

Plus de 90% des fonctions de graphlib et de util sont déjà dans la ROM!
Le problème est qu'il n'y a pas (encore?) de tutorial pour le _nostub en assembleur. Ce n'est pas aussi compliqué que ça.
Un autre problème est que le format objet utilisé par l'assembleur le plus populaire, A68k, n'est pas compatible avec celui de TIGCCLIB. On peut s'en sortir avec un fichier GNU as supplémentaire, mais c'est compliqué et il faut compter sur le linker spécial de TIGCC (de Xavier Vassor) qui a une assez mauvaise réputation en ce qui concerne le linkage de plusieurs fichiers objets. Si une solution à ce problème est trouvée, le _nostub pourrait devenir plus attractif même pour les programmeurs en assembleur, car les moins de 10% des fonctions de graphlib et util qui ne sont pas dans la ROM (comme les niveaux de gris) sont dans TIGCCLIB.

>Aghnar:

Je suis d'accord avec toi sur le fait que le plus grand problème des librairies dynamiques est le fait de mettre toute la charge sur le dos de l'utilisateur.

Cependant, contrairement à toi, je préfère en général les librairies statiques aux librairies dynamiques. En effet, il y a pour moi 3 solutions au problème des routines communes à plusieurs programmes:
* réécrire la routine à chaque fois: Toute la charge est sur le dos du programmeur, donc c'est normal et compréhensible qu'il trouve cette solution peu pratique.
* les librairies dynamiques: Ici, le problème de la duplication d'effort de la part des programmeurs est résolu. Il y a un seul programmeur (ou une seule équipe de programmeurs) qui travaille sur les librairies. Cependant, ici, toute la charge est sur le dos de l'utilisateur, qui doit faire en sorte d'avoir toujours les librairies qu'il faut, et de plus en une version suffisament récente pour tous les programmes, ce qui rend problématique même la pratique de diffuser les librairies avec les programmes (que ce soit par un archive ZIP ou par un installateur automatique) en raison des conflits de version. (En théorie, ces problèmes ne devraient pas exister avec des systémes de versionnement comme ceux utilisés par Windows ou par les systèmes Unix. En pratique, ces problèmes sont toujours présents.)
* les librairies statiques: La solution idéale. Ici, on a l'avantage des librairies dynamiques (pas de duplication d'effort) sans son désavantage (charge sur le dos de l'utilisateur). Toute la charge est sur le dos du compilateur, un programme! On a donc réussi a automatiser le problème des librairies! Ni le programmeur, ni l'utilisateur ne travaille plus que nécessaire. Je trouve donc c'était une très mauvaise idée de Microsoft d'introduire les DLLs sous Windows. Je retiens la solution des librairies statiques techniquement supérieure.

>Aghnar: Les kernels et les librairies dynamiques oui c bien en théorie,

Désolé, mais je ne suis pas d'accord avec toi sur ce point-là.

>Aghnar: mais sur TI c'est un beau bordel !

En effet.

>Aghnar: Nostub definitely rules !

Entièrement d'accord.
[edit]Edité par Kevin Kofler le 19-06-2001 à 17:06:18[/edit]

Kevin Kofler > je me plie ! tes arguments sont trop bons

toutefois, les ROMCALL c'est vraiment trop lent, et si la ROM change et les ROMCALLS changent il faut refaire l'I/O du prog !

ce que j'entendait pour un hello world de 20k c'est une librairie linkée dans sa totalité. ex genlib lié a chaque prog.

Bon moi je suis devenu 100% nostub, pourquoi?

1: Pas de probleme au niveau de l'utilisation, c'est simple, 1 fichier 1 programme (en general)
il y a un reset, on a pas besoin de faire de manip (meme si bientot un prog modifiant la rom donc potentiellement dangereux le fera automatiquement)


2: Le nostub de tigcc n'est pas vraiment ce que l'on peut appele un nostub, car il y a un minikernel introduit au debut de chaque programme... on a donc une perte de memoire certe, mais je la trouve minime face au confort d'utilisation.
L'avantage, c'est que ca permet d'eviter que chaque programmeur le fasse.... donc un petit gain de temps...

3: Les lib dynamiques sont la cause de pas mal de probleme... desarchivage dezipage..... en bref alors qu'il suffit de deziper qu'un fichier, la on doit deziper toute les lib.. et les copier en ram... franchement, est-ce raisonable?

4: Les meilleurs programmaes sont en general programmer par les meilleur programmeurs (ce qui ne veut pas dire que ...) et en generale, ces programmeurs preferent faire leur propre lib... (cf sma,smq,sf2t,sor3c...) donc vu que l'on a en generale que les meilleurs prog sur notre caltos, on a des tonnes de lib, que l'on ne peut pas dire qu'elle soient vraiment communes et donc que l'on gagne de la place...



pphd: c'est pas de ma faute si ta calc n'acceptent pas les nostub

>Nhdpp:

>1

Entièrement d'accord.

>2

Il suffit de définir NO_EXIT_SUPPORT et de ne pas définir SAVE_SCREEN, OPTIMIZE_ROM_CALLS ou RETURN_VALUE pour avoir un _nostub "pur" sous TIGCC. (Il y aura une seule instruction, un jra _main, rajoutée puisqu'elle est nécessaire pour des raisons techniques.)

>3
>4

Entièrement d'accord.

>Nostub ROULEZZZZZZZZZZZZZZZ

Entièrement d'accord là aussi, même si ce n'est pas très objectif comme remarque.

>Plus de 90% des fonctions de graphlib et de util
>sont déjà dans la ROM!
Pas vraiment. Et puis c'est compatible avec les 92, au moins.

>Le problème est qu'il n'y a pas (encore?) de
>tutorial pour le _nostub en assembleur.
>Ce n'est pas aussi compliqué que ça.
Y'en a-t-il vraiment besoin ?

>Un autre problème est que le format objet
>utilisé par l'assembleur le plus populaire,
>A68k, n'est pas compatible avec celui de
>TIGCCLIB. On peut s'en sortir avec un fichier
>GNU as supplémentaire, mais c'est compliqué et
>il faut compter sur le linker spécial de TIGCC
>(de Xavier Vassor) qui a une assez mauvaise
>réputation en ce qui concerne le linkage de
>plusieurs fichiers objets. Si une solution à ce
>problème est trouvée, le _nostub pourrait
>devenir plus attractif même pour les
>programmeurs en assembleur, car les moins de 10%
>des fonctions de graphlib et util qui ne sont
>pas dans la ROM (comme les niveaux de gris) sont
>dans TIGCCLIB.
Et voila. Et hufflib, et ziplib, et linelib, et fglib et engilib et genalib et systlib et api92 et ...


>Je suis d'accord avec toi sur le fait que le
>plus grand problème des librairies dynamiques
>est le fait de mettre toute la charge sur le dos
>de l'utilisateur.
Non il faut un administrateur.

>Cependant, contrairement à toi, je préfère en
>général les librairies statiques aux librairies
>dynamiques. En effet, il y a pour moi 3
>solutions au problème des routines communes à
>plusieurs programmes:
>(En théorie, ces problèmes ne devraient pas
>exister avec des systémes de versionnement comme
>ceux utilisés par Windows ou par les systèmes
>Unix. En pratique, ces problèmes sont toujours
>présents.)
>* les librairies statiques: La solution idéale.
>Ici, on a l'avantage des librairies dynamiques
>(pas de duplication d'effort) sans son
>désavantage (charge sur le dos de
>l'utilisateur). Toute la charge est sur le dos
>du compilateur, un programme! On a donc réussi a
>automatiser le problème des librairies! Ni le
>programmeur, ni l'utilisateur ne travaille plus
>que nécessaire.
Et vlam. C incompatible avec un nouveau materiel.

> Je trouve donc c'était une très
>mauvaise idée de Microsoft d'introduire les DLLs
>sous Windows. Je retiens la solution des
>librairies statiques techniquement supérieure.
A le malade !!!!
Avec tous les drivers differents qui existent, faut etre malade de penser comme ca.
il y a moins 1 centaine de modems avec des protocoles differents.
Des dizaines de cartes graphiques incompatibles entre elles.
Les souris sont jamais au meme encdroit (port serie, PS2, usb). Pareil clavier.
Les disques durs sont aussi a part.
Les grauveurs idems.
Le systeme d'affichage des fenetres ? On le refait a chaque fois !
Etc, etc, etc.
C pas pour dire, mais c'est quand meme pas pour rien, si tous les systemes d'exploitation actuels utilsent des libraries et des drivers independants.
Ca soulage enormement le programmeur.
Sinon, ca serait inutile de developer sur Pc.
Avec des EXE de la taille de 100 de mega-octets pour des progs de base...

>>Aghnar: Les kernels et les librairies
>>dynamiques oui c bien en théorie,
>Désolé, mais je ne suis pas d'accord avec
>toi sur ce point-là.
Oui desole.
Mais alors faut aussi considerer la rom de ti comme un kernel qu'il faut virer la.

>>Aghnar: mais sur TI c'est un beau bordel !
>En effet.
Pas chez moi en tout cas.
J'ai vraiment aucun conflit de ce point de vue la. Forcement, si on telecharges les libs de ticalc, ca peut se comprendre

>>Aghnar: Nostub definitely rules !
>Entièrement d'accord.
Absolument contre !


>1: Pas de probleme au niveau de l'utilisation,
>c'est simple, 1 fichier 1 programme (en
>general )
Qui marche pas...
>il y a un reset, on a pas besoin de faire de
>manip (meme si bientot un prog modifiant la rom
>donc potentiellement dangereux le fera
>automatiquement)
Arg, trop dur. Je me meurs.

>2: Le nostub de tigcc n'est pas vraiment ce que
>l'on peut appele un nostub, car il y a un
>minikernel introduit au debut de chaque
>programme... on a donc une perte de memoire
>certe, mais je la trouve minime face au confort
>d'utilisation.
qui est nul.

>L'avantage, c'est que ca permet d'eviter que
>chaque programmeur le fasse.... donc un petit
>gain de temps...
Pardon ?

>3: Les lib dynamiques sont la cause de pas mal
>de probleme... desarchivage dezipage.....
>en bref alors qu'il suffit de deziper qu'un
>fichier, la on doit deziper toute les lib.. et
>les copier en ram... franchement, est-ce
>raisonable?
Didonc ? Tu as quel kernel la ?
PlusShell v0.40 alpha ?
Parce que tu dates beaucoup.
Enormement meme.

>4: Les meilleurs programmaes sont en general
>programmer par les meilleur programmeurs (ce qui
>ne veut pas dire que ...) et en generale, ces
>programmeurs preferent faire leur propre lib...
>(cf sma,smq,sf2t,sor3c...)
Sma -> Genlib.
Smq -> Graphlib (Yes, tu as tord).
Sf2t -> Graphlib Houpla boum.
Sor3c -> graphlib + rv_lib.
Ben quoi. Y'a graphlib et genlib.
C tout. rv_lib ne les remplace pas (sert a autre chose) et est reutilise par tous ces programmes.

> donc vu que l'on a en generale que les
>meilleurs prog sur notre caltos,
>on a des tonnes de lib,
Un seul fichier suffit mon ami : libcpka !

> que l'on ne peut pas dire qu'elle soient
>vraiment communes et donc que l'on gagne de la
>place...
Ben si.
A cause du nostub par contre...

Bon. Vous avez des REELS aruguments, parce que je m'ennuis.


[edit]Edité par PpHd le 20-06-2001 à 15:06:10[/edit]

Moi, je dis : RESPECTEZ LES CHOIX DE CHAQUE PROGRAMMEUR !!!
Si vous voulez pas utiliser de programmes de type nécessitant un Kernel, eh bien, passez-vous en !
Si vous voulez utilisez des programmes avec Kernel, et bien, faites le !

Cela dit, laissez chaque programmeur choisir ce qu'il préferre !

Si ppHd veut faire des progs kernel, libre à lui.
Si d'autres veulent faire des progs nostub, libres à eux !

De toutes façon, il y a des avantages et inconvénients au 2 :
* Kernel : prend - de place
* Nostub : prend + de place
MAIS : * kernel peut prendre + de place à cause des librairies...

* Kernel : + évolutif... en général, mais y'a des prog qui marchent plus comme ça !

Et y'a encore d'autres arguments, du style "Anti-crash", oui, mais le nostub est pas buggé.... tout dépend du porgrammeur !!!


Franchement, vous faites chier avec vos engueulades à la con !
Laissez chacun d'entre nous choisr ce qu'il veut, et sans faire chier :
si le programmeur veut faire du kernel, et bien, installez un kernel, ou n'utilisez pas son prog...
si il veut faire du nostub, et bien, ne soyez pas anti-nostub, ou n'utilisez pas son prog...

> Je trouve donc c'était une très
>mauvaise idée de Microsoft d'introduire les DLLs
>sous Windows. Je retiens la solution des
>librairies statiques techniquement supérieure.

Au secours !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

>JM: Je vois que tu es d'accord avec moi.

>Squale92: Laisse nous nous taper dessus dans cette discussion sterile et sans interet autre que se taper dessus Kevin et moi (Et lui il a deja fait appel plusieurs fois a son perso cache, Aghnar)... J'ai l'avantage. Il me reste JM comme mega-breaker sous la main

Arf c la saison ou quoi ?
Apres les trolls sur linuxfr, venez retrouvez les trolls sur TiFR

Et franchement, critiquer les libs dynamiques à cause de la place, ça va pas loin. Il y en a quand même pas mal de la place sur le Ti. J'ai commencé sur Ti92. La d'accord, il y avait pas bcp de place, mais les 89 et 92+ fo pas pousser.

Pour la facilité d'utilisation, avec Fargo, c'était récupérer un backup, mettre fargo dedans, le renvoyer, avec toutes les applis ensuite. C'était pas vraiment plus simple. Et puis aux débuts de fargo II, c'était souvent qu'il fallait le faire parceque c'était pas stable !

JM>

Et merdre ! Universal OS ne gaspille pas de place !!

TEOS+graphlib_hw1+graphlib_hw2+linelib+util+userlib+gray4lib+gray7lib = 10 ko

Universal OS = 11 ko

En plus, j'ai rajouté des ramcalls et des foncions.

On garde peut-être pas graphlib_hw1 et graphlib_hw2 en même temps sur sa calc ? Ben pour Universal OS, c'est pareil : il gère ça automatiquement pour le confort de l'utilisateur, et il n'installe en mémoire que le code nécessaire.

Je crois que je vais mettre un version light d'Universal OS : pas de menu reset. Je vais surtout virer des fonctions internes qui n'ont absolument jamais servi (au début je les avais laissé par mégarde et après je ne me suis pas occuper de les virer.

-- double post --
[edit]Edité par JM le 20-06-2001 à 15:06:04[/edit]

Bon, alors on imagine un instant que graphlib et gray4lib aient été statiques : à l'apparition du HW2, plus aucun jeu n'aurait affiché de niveaux de gris, alors que grâce au fait que ces librairies sont statiques, il a suffit d'en proposer des versions modifiées pour que tous les jeux qui les utilisaient fonctionnent correctement sans nécessiter l'intervention de chaque programmeur.

Toujours avec graphlib et les HW2 : je vous rapelle que les niveaux de gris n'ont pas toujours été parfait, et que nous avons pu voir leur qualité s'améliorer au fil du temps. Avec une graphlib statique, chaque développeur de jeu aurait dû proposer une version recompilée de son programme à chaque update !
J'ai la flemme de chercher d'autres exemples mais ça fait déjà beaucoup en faveur des libs dynamiques je trouve.

Par contre je me demande comment on peut dire que les dlls Windows auraient dû être dynamiques. On râle déjà à propos de la taille des programmes Windows, alors imaginez ! De plus, cela empêcherait d'avoir des programmes automatiquement localisés. Un programme compilé par un allemand afficherait des menus en allemand chez tout le monde. Et plein d'autres arguments...
[edit]Edité par Blue_Z le 20-06-2001 à 16:06:34[/edit]

A propos d'Universal OS, comptez qu'il fait 9.87 ko !

heu comme ca au moins ca favorise l'opensource

JM> ouais, vire le menu reset, on s'en sert jamais et c'est lourd de faire deux fois [2nd]+droite+gauche+[on] pour un reset ...

Kevin> Un jeu peut être en blanc et noir et se servir uniquement des ROM calls. Dans ce cas, n'importe quelle librairie graphique serait un gaspillage vu que les fonctions sont déjá dans la ROM.

Bah non, justement ... l'utilisation d'une librairie dynamique ne gache pas de place puisqu'elle deja sur la calc ... ceci dit, les ROM_CALLs ne gachent pas de place non plus (mais du temps )

Aghnar> Donc, sur TI je pense que le nostub est evidemment bien plus intéressant au nivo grand public et utilisateurs.

Le grand public, je m'en fout.
Quand j'ai fait Total Annihilation, je voulais faire un Total Destrucrion, pas un Starcraft. Starcraft est grand public, Total est beaucoup mieux pour les connaisseurs.

Quand je programme, c'est pas pour avoir le plus possible de downloads sur ticalc (je ne leur pas envoyé total, en fait si, je leur ai envoyé pour faire une news, ils ne m'ont repondus -> qu'ils aillent se faire foutre s'il ne veulent que des programmes et/ou programmeurs connus), c'est pour faire un programme qui me plait (en plus du plaisir de programmer, bien sur). Et les programmes grand public me plaisent rarement.

Donc c'est pas pour plaire au grand public que je me mettrait a faire du nostub (et franchement, c'est pas plus compliqué d'envoyer la version de genlib du zip et l'exe que d'envoyer le prog et un lanceur (pour HW2, ou parceque c'est compressé) (d'autant plus que le nom de la lib est explicite, alors que le nom du lanceur et des datas peuvent porter a confusion pour le grand public)



Et surtout, (meme si ca deja ete dis), les lib dynamiques sont evolutives:
* quand PpHd sort une version de genlib plus optimisée, tous les jeux qui utilisent genlib en profitent, meme si l'auteur a disparu ou a abandonné le projet.
* quand une nouvelle verion de TiGCC soprt (avec les gray de JM, par exemple), les ancien jeux n'en profitent pas, alors que les jeux en kernel ont tous des beaux nvg (sauf ceux qui font du kernel sans utiliser de librairie, mais c'est pas tres malin)
* quand TI nous sortira un nouveaux HW ou une nouvelle ROM, les ancient jeux continueront a fonctionner quand le kernel et les libs auront ete adapté. les nostub nececiterons une recompilation, voir plus si des ROM_CALLs sont modifié (en C, il suffit d'utiliser des marcos, mais en asm, ca peut foutre un beau bordel)

Et pour finir, pour ceux qui pretendent que ré-installer le kernel est une corvée, j'ai sortit auto-inst qui resoud ca ... (c'est encore en beta, mais ca fait 1 mois que je n'ai pas réinstallé de kernel a la main)

>Dark Angel: * quand TI nous sortira un nouveaux HW ou une nouvelle ROM, les ancient jeux continueront a fonctionner quand le kernel et les libs auront ete adapté. les nostub nececiterons une recompilation, voir plus si des ROM_CALLs sont modifié (en C, il suffit d'utiliser des marcos, mais en asm, ca peut foutre un beau bordel)

>BlueZ: Bon, alors on imagine un instant que graphlib et gray4lib aient été statiques : à l'apparition du HW2, plus aucun jeu n'aurait affiché de niveaux de gris, alors que grâce au fait que ces librairies sont statiques [(je suppose que tu voulais dire: "dynamiques")], il a suffit d'en proposer des versions modifiées pour que tous les jeux qui les utilisaient fonctionnent correctement sans nécessiter l'intervention de chaque programmeur.

L'argument de compatibilité est cité souvent... Cependant:

1. Quand AMS 2 est sorti, de nombreux jeux en assembleur (à cette époque pratiquement tous en mode kernel) n'ont plus marché, alors que CReversi, un jeu en _nostub publié avant la sortie de AMS 2.03, a fonctionné sans modifications. L'important est surtout que les jeux ou programmes soient programmés proprement. Dans les sources de kernels et de jeux pour kernel, on trouve généralement au moins autant de saletés que dans les sources en _nostub. (Je sais que mes programmes résidents en mémoire ne sont pas un bon exemple en ce qui concerne la programmation propre, mais je n'ai utilisé les adresses absolues que là où je n'ai pas eu le choix.)

2. Le premier jeu en assembleur de ma connaissance à marcher sur HW2 AMS 2 était CReversi, un jeu en _nostub (et de taille inférieure à 8 KO).

3. Il y a eu une longue période où les kernels n'ont pas marché sur HW2 AMS 2 (jusqu'à la sortie du HW2Patch de JM). Pratiquement tous les programmes en assembleur dépendaient des kernels. Le résultat: Il n'y avait pratiquement aucun programme ou jeu en assembleur qui tournait sur HW2 AMS 2. Les seuls jeux à faire exception à cette règle étaient CReversi et CBlaster, programmés en C _nostub par Zeljko Juric.

4. Pour les niveaux de gris, de nombreux programmes pour kernel (tetris par exemple) n'ont plus marché avec les nouvelles librairies pour HW2 parce qu'ils partaient du principe que plane0=LCD_MEM.

5. TI jusqu'à présent n'a modifié des ROM calls que pour des changements au niveau interne. Les seuls changements incompatibles dont je suis au courant: des fonctions EM_ ont été supprimées pour ne pas user inutilement la ROM Flash lors du passage à AMS 2, et les fonctions OSVRegisterTimer et OSVFreeTimer ont été supprimées dans AMS 2.04 parce que ces timers n'existent plus dans l'architecture AMS.

Bref, on n'est jamais à l'abri des modifications internes, quelle que soit la méthode de programmation employée (kernel ou _nostub).
Quant à l'argument de compatibilité pour les kernels, il doit faire ses preuves avec les prochaines versions de AMS. Pour l'instant, les kernels n'ont pas un passé très heureux en cette direction-là, et je trouve donc que ce n'est pas une très bonne idée de dire en ce moment que les programmes pour kernel sont plus compatibles que les programmes en _nostub.
[edit]Edité par Kevin Kofler le 20-06-2001 à 18:06:39[/edit]