XLib, GraphX, Extgraph ou Genlib ??? - Page 3

Thibaut a écrit :
Lionel Debroux :
- Et puis tu te permet d'insulter les programmes [cowboy]nostubs[/cowboy] et de mépriser leurs auteurs... enfin voilà quoi, mentalité maternelle.

y'a pas comme ki dirait une pitite erreur ?

Certainement.

Merci du renseignement. (Je me disais aussi )

Kévin>si c'est la méthode qui est de copier tous les caractères en mem pour les afficher plus rapidement : je l'utilise déjà : je l'ai déjà repiqué sur une routine TICT...

> si c'est la méthode qui est de copier tous les caractères en mem pour les afficher plus rapidement : je l'utilise déjà : je l'ai déjà repiqué sur une routine TICT...

Ce qui m'a donné l'idée de compléter la famille de routines de TICT, je t'en remercie.

Tu fais du scrolling ligne par ligne ? Une sorte de memmove inline (surtout pas memmove d'AMS, elle est lente) est très bien pour cela (mais je suppose que tu le fais déjà).

en parlant de TICT, j'ai posté un patch à TN qui utilise la font moyenne (en option à la compilation)
sur le ebook reader sur 92+ et qui strech l'image de titre
(il sera mis dans la prochaine version m'a t'il dit)

Kevin> quand je dis 30ko ça comprend pas que les routines graphiques
et puis, c'etait pour faire un peu de promo à XLib et grphx qui debutent
alors si tout ce que tu sais faire c'est casser les programmeurs qui ont d'autres conceptions que la tienne au lieu de les encourager
je croyais que tu avais changé ces derniers temps à ce sujet

grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
pt1 1000 sprites de plus par seconde c'est negligeable pour toi KK!!

Franchement ca fait pitié.
Extgraphlib ne fait pas le poid fasse aux autres librairies graphique.
D'ailleur la difference entre l'ams et Extgraphlib est equivalent a la difference entre Extgraphlib et Xlib.

Non mais faut vraiment pas etre tres intelligent pour raconter ce genre de connerie....
C'est comme l'histroire de la dll...
Et puis XLib ne change pas de prototype.. la version dll est la version 1.05 sont 100% compatible niveau code sauf pour les fonctions qui n'ont pas eté reimplanter.

Et puis si tu me fait chier avec la dll, et que tu me dit que ca prend de la place, alors je la mettrai en kernel, a oui, le format kernel et bien plus propre comme tu le dit si bien que ces methodes de boff pour les dll!

XDanger> pour le scrolling, c'est du ligne par ligne oui : encore une routine repiquée de TICT (je n'ai bien sur pas manqué de sité l'origine de ces routines dans mes sources !)

XDanger
a écrit : surtout pas memmove d'AMS, elle est lente

Non, les ROM_CALLs memcpy et memmove sont très rapides (mais on peut certainement faire mieux).

TiMad a écrit :
grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr pt1 1000 sprites de plus par seconde c'est negligeable pour toi KK!!

Oui, 1000 sur plusieurs dizaines de milliers, c'est négligeable.

Franchement ca fait pitié. Extgraphlib ne fait pas le poid fasse aux autres librairies graphique.

C'est ton avis personnel.

D'ailleur la difference entre l'ams et Extgraphlib est equivalent a la difference entre Extgraphlib et Xlib.

Ce n'est pas ce que disent mes benchs à moi. (BitmapPut est très lente...)

Non mais faut vraiment pas etre tres intelligent pour raconter ce genre de connerie....

Sans commentaire...

Et puis XLib ne change pas de prototype.. la version dll est la version 1.05 sont 100% compatible niveau code sauf pour les fonctions qui n'ont pas eté reimplanter.

C'est quand-même une incompatibilité. Et puis il y a aussi les fautes de frappe (cf. XJoypad vs. XJoyPad).

Et puis si tu me fait chier avec la dll, et que tu me dit que ca prend de la place, alors je la mettrai en kernel, a oui, le format kernel et bien plus propre comme tu le dit si bien que ces methodes de boff pour les dll!

1. C'est faux, le format kernel n'est pas plus propre.
2. Même si c'était vrai, ça serait normal, vu que notre support de DLLs est prévu seulement pour les cas exceptionnels (plus de 64 KO de code), pas pour le partage de code routinier.

C'est ça qui nous énerve !

Parceque vous avez conçu ce format en pensant cette unique chose, en croyant que comme vous êtes les maîtres, forcément cette seule chose est la seule valable, maintenant que quelqu'un (TiMad) a trouvé une utilisation tout aussi intéressante, vous nous faites chier.

Lamentable.

En y réfléchissant un peu, Kévin, c'est un super compromis, la version DLL :
on met dans la DLL les fonctions qui sont utilisées par à peu près touts les progs (Xon, Xoff, XnewGPlan, XGPlanc, XJoyPad, ...) et en statique les fonctions plus différentes que tout le monde n'utilisera pas forcément.
Enfin, ça n'est avantageux que si le code nécessaire pour prendre en compte la DLL n'est pas plus gros que la DLL elle-même.
Puis c'est vrai que c'est un peu chiant, ça fait un fichier de plus...
Mais ça peut vraiment être pratique : ça donne les avantages de la prog kernel (lib dynamique, donc pas besoin de recopier des fonctions dans chaque prog, donc pas de perte de mémoire due à ça) et ceux du _nostub (pas de kernel à installer ni de librairies, juste une DLL, et seules les fonctions que tu utilises (en dehors de celles de la DLL) seront recopiée, donc on ne perd pas non plus de mémoire....)

Kevin > pour infos, en utilisant très PEU de fonctions de la statique, je pers 5.5 Ko par rapport au prog utilisant la DLL alors quand j'utiliserai le Joypad ect, mes progs seront considérablement moins gros en format DLL qu'en static.

Et quand on a pas envie de perdre 5.5 Ko (ou +) par prog Xlib (car c du gachi pur et dur de tout rajouter à chaque prog), et ben on préfère largement la DLL
tous les avantages du kernel en _nostub

Thibaut a écrit :
C'est ça qui nous énerve !

Parceque vous avez conçu ce format en pensant cette unique chose, en croyant que comme vous êtes les maîtres, forcément cette seule chose est la seule valable, maintenant que quelqu'un (TiMad) a trouvé une utilisation tout aussi intéressante, vous nous faites chier.
Lamentable.

On sait très bien qu'on peut utiliser les DLLs comme ça, pas besoin de nous le montrer. La preuve: il y a écrit dans notre documentation qu'il ne faut pas le faire et pourquoi il ne faut pas le faire!

>jackiechan, Pim89

Arrêtez cette discussion absurde: XLib version DLL est un abus de notre système de DLLs, et il n'y a rien à discuter là-dessus.

jackiechan a écrit :
En y réfléchissant un peu, Kévin, c'est un super compromis, la version DLL : on met dans la DLL les fonctions qui sont utilisées par à peu près touts les progs (Xon, Xoff, XnewGPlan, XGPlanc, XJoyPad, ...) et en statique les fonctions plus différentes que tout le monde n'utilisera pas forcément.

Ce n'est pas un "super compromis", c'est une solution bâtarde qui empire le problème (parce qu'il reste un petit bout de 8 KO en DLL - ridicule!).

Enfin, ça n'est avantageux que si le code nécessaire pour prendre en compte la DLL n'est pas plus gros que la DLL elle-même.

Plus précisément: ça n'est avantageux que si le code nécessaire pour prendre en compte la DLL n'est pas plus gros que les functions vraiment utilisées de la DLL. Parce que les fonctions que TiMad prétend être indispensables sont loins de l'être! Et ce n'est pas vraiment le cas ici. Si la différence de taille existe, elle est négligeable (2 ou 3 KO sur un jeu de 32 KO ou plus, c'est négligeable).

Puis c'est vrai que c'est un peu chiant, ça fait un fichier de plus...

Un fichier de plus pour 8 KO, c'est très chiant.

Mais ça peut vraiment être pratique : ça donne les avantages de la prog kernel (lib dynamique,

Je n'ai jamais retenu ceci comme un avantage. Les librairies dynamiques nécessaires pour lancer un programme sont un inconvénient. Il faut penser à l'utilisateur!

donc pas besoin de recopier des fonctions dans chaque prog, donc pas de perte de mémoire due à ça)

Mais perte de mémoire dûe aux fonctions inutilisées et au code de chargement de la DLL. Et il ne faut pas non plus oublier que le code en DLL ne disparaît pas "magiquement", mais qu'il est juste dans un fichier différent, donc on n'a rien gagné.
Et puis, l'appel de fonctions en une DLL _nostub est plus lent qu'en une librairie statique. (Notre système de DLLs n'est pas du tout fait pour les fonctions exécutées des milliers de fois par seconde!)

et ceux du _nostub (pas de kernel à installer ni de librairies, juste une DLL,

Bel oxymore...
Une DLL est une librairie!
Donc on a déjà perdu presque tous les avantages du _nostub.

et seules les fonctions que tu utilises (en dehors de celles de la DLL)

Justement... "en dehors de celles de la DLL" ...

seront recopiée, donc on ne perd pas non plus de mémoire....)

Si, pour les fonctions inutilisées dans la DLL. Et pour le code de chargement de 1 ou 2 KO.

Pim89 a écrit :
Kevin > pour infos, en utilisant très PEU de fonctions de la statique, je pers 5.5 Ko par rapport au prog utilisant la DLL alors quand j'utiliserai le Joypad ect, mes progs seront considérablement moins gros en format DLL qu'en static.

N'importe quoi. La DLL fait 8 KO, donc si tu utilises l'équivalent en statique, au maximum, tu te retrouveras avec 8 KO de plus. Et avec le code de chargement (1 ou 2 KO) en moins. Donc ça te fait 6 ou 7 KO de plus en statique qu'avec la DLL. Et donc en total, en comptant la taille de la DLL (qui ne disparait pas "magiquement", je rappelle), tu as gagné 1 ou 2 KO (la taille du code de chargement) en passant en statique.

Et quand on a pas envie de perdre 5.5 Ko (ou +) par prog Xlib (car c du gachi pur et dur de tout rajouter à chaque prog), et ben on préfère largement la DLL

Qui te dit que tout le monde a plusieurs programmes faits avec XLib sur sa calculatrice? Vu qu'il n'y a pas beaucoup de programmeurs disponibles pour utiliser une librairie qui abuse le système de DLLs de TIGCC, ce n'est pas très probable.

tous les avantages du kernel en _nostub

Tous les inconvénients du kernel en _nostub. Et plus aucun des avantages du _nostub. Ce n'est plus du _nostub, ce que vous faites.

allez, je reviens, donc je mets mon grain de sel...

le pb des libs dynamiques, comme le dit Kevin, c'est que c'est un fichier de plus. Or comme en plus ils ne permettent plus de mes utiliser officiellement...
Ensuite, je dirais aussi que si ils ne l'ont plus mis, c'ets peut-être aussi pour accélérer le chargement et la rapidité en cours des fonctions.
Le problème, c'ets que, contrairement au PC, on a pas tant de place que ça sur la calculatrice, et plusieurs fonctions se retrouvent plusieurs fois en mémoire.

Donc, il aurait fallu un compromis, c'ets à dire effectivement mettre les fonctions les plus courantes en statique et en DLL et le reste en statique. Pourquoi les deux ? parce que parfois, il est plus économique en place de passer en statique à cause du code de lancement et aussi parce que par rapport au gain de place, la perte de place est trop importante.

- question à Kevin : avec ce système, on peut quand même avoir du nostub, mais parfois, si les gens veulent vraiment et si les gens le souhaitent, avoir des DLLs sans grêver le code des fichiers nostub purs, non ? -

Donc, s'il y avait une manière propre et officielle, afin de contenter un maximum de monde, j'en serais ravi et cela permettrait peut-être d'éviter els disputes dommageables pour la communauté qui se dérouelent à chaque fois qu'une conversation telle que celle-ci se déroule.
La seule chose, c'est que ces libertés devraient être limitées afin de ne pas se retrouver avec le même système que doors : des libs dans tous les sens... et des doublons partout dans les DLLs...

Si on ne veut pas ce genre d'utilisation de nos routines de DLLs (bien que, comme le montre XLib 1.00, c'est techniquement possible), c'est exactement parce que, comme tu le dis, "ces libertés devraient être limitées afin de ne pas se retrouver avec le même système que doors : des libs dans tous les sens... et des doublons partout dans les DLLs..."

La solution à ce genre de problèmes (surnommé souvent "DLL hell") est de tout mettre en statique sauf si la limite de 64 KO le rend impossible.

je comprend votre attitude vis à vis des gens qui ne savent pas se limiter...
Mais y aurait-il un moyen de le faire quand même sous couvert de TIGCC, et officieusement ? - genre, cette partie des sources n'est pas open -

Je te signale qu'il y a bien un support de DLLs dans TIGCC 0.94 beta 18 (c'est ce que TiMad utilise) et que celui-ci restera (parce que le supprimer ne servirait à rien: les abuseurs sauraient toujours s'arranger).

Je ne vois pas ce que tu veux que nous fassions de plus pour le support des DLLs.

ben alors, pourquoi y a-t-il eu cette dispute ???

Comprend plus rien, moi...

Parce que TiMad abuse de notre système de DLLs pour faire quelque chose pour laquelle on dit exprès qu'il ne faut en aucun cas la faire (faire une DLL commune entre plusieurs programmes, nous relançant ainsi dans le plein milieu de la "DLL hell")!

>>surtout pas memmove d'AMS, elle est lente
> Non, les ROM_CALLs memcpy et memmove sont très rapides (mais on peut certainement faire mieux).
Ben, il me semble qu'il y a des cas où memmove est lente. Pas plus tard qu'hier, 'ai essayé de changer un peu le code du tutorial de TICT S1P6. En remplaçant le memmove 'inline' qui y était par un appel au memmove système, pour voir la différence de vitesse, j'ai vu que le compteur de cycles de VTI me donnait une grosse différence (plus de 27000 au lieu de moins de 9000)! Je sais très bien que le compteur de cycles n'est pas parfaitement précis, mais quand même...
(J'ai revérifié mes informations avant de poster ceci).

Et voila encore une preuve de la debilité des representant de l'équipt tigcc!

bon deja pour KK:
"Oui, 1000 sur plusieurs dizaines de milliers, c'est négligeable. "

MDR. tu racontes vraiment n'importe quoi, et tu espere que ca va passer.
Le jour ou une routine de sprite depassera les 7 Khz en maské tu m'appelles (ouia bonil se pourai que dans la version 2.00 ca s'en approche, mais je pense que c'est encore loin...)
Extgraphlib doit faire un truc du genre 2-3Khz .. soit 2/3 ksprites seconde.. donc faux vraiment que t'arrete de sortir des CONNERIE pour mettre en avant une lib c qui n'est pas du tout optimisée pour la programmation graphique!
D'ailleur maintenant je me pose la question si tu sait faire des bench parce que trouver une routine qui dessine des milliers de sprites par seconde , t'es vraiment une mass
D'ailleur Extgraphlib n'as plus lieu d'etre cité pour faire des jeu, car il y a GX/Gen/X qui la depasse largement...

Pour l'histoire de la dll, je m'en tappe completement que ce soit votre support. Tigcc est une aide aux programmeurs.. et on en fait ce que l'on veut!
D'ailleur le format Kernel est bien plus propre que le format dll! et ca ne va pas dire le contraire.. ( ou alors sort une connerie grosse comme le monde comme pour l'histoire des sprite ).
Si j'utilise votre format dll, c'est tout simplement parce que j'ai pas le temps d'en developper un autre.
La raison etant que je suis en prepa.. et qu'on bosse , si il y a des erreurs de frappes dans le header de XLib v1.05, c'est tout simplement parce que je l'ai convertit en tres tres peu de temps (j'ai meme pas eut le tmps de convertir toutes les fonctions...).

Ca me fait vraiment rire ces arguments a la con qui me font pensé au gosses qui raconte n'importe quoi pour essayer d'avoir raison.
Et puis si on a une dll c'est toujours du nostub.. alors arrete d'etre ***.
D'ailleur si je met un kernel dans mon prog ce sera quand meme du nostub ( neu²)!

Je trouve la critique de certains bien facile alors que quand on voit certains bouds de code, il y a de quoi s'inquietter...

> Je trouve la critique de certains bien facile alors que quand on voit certains bouds de code, il y a de quoi s'inquietter...
Lesquels ? Cite-les, ça te permettra peut-être de dire quelque chose de constructif, d'être utile à TIGCC...

Kevin Kofler a écrit :
jackiechan, Pim89

Ce n'est pas un "super compromis", c'est une solution bâtarde qui empire le problème (parce qu'il reste un petit bout de 8 KO en DLL - ridicule!). Plus précisément: ça n'est avantageux que si le code nécessaire pour prendre en compte la DLL n'est pas plus gros que les functions vraiment utilisées de la DLL. Parce que les fonctions que TiMad prétend être indispensables sont loins de l'être! Et ce n'est pas vraiment le cas ici. Si la différence de taille existe, elle est négligeable (2 ou 3 KO sur un jeu de 32 KO ou plus, c'est négligeable).

Il est vrai que 8ko ce n'est pas énorme. Surtout si comme tu le dis plus bas TiMad ne met pas vraiment les fonctions indispensables.

Je n'ai jamais retenu ceci comme un avantage. Les librairies dynamiques nécessaires pour lancer un programme sont un inconvénient. Il faut penser à l'utilisateur!

Je suis d'accord.

Mais perte de mémoire dûe aux fonctions inutilisées et au code de chargement de la DLL. Et il ne faut pas non plus oublier que le code en DLL ne disparaît pas "magiquement", mais qu'il est juste dans un fichier différent, donc on n'a rien gagné.

Si on a plusieurs progs qui utilisent Xlib, ça évite de recopier du code. et si timad ne met des fonctions inutiles dans la DLL, ça ne gaspille aucune place !

Et puis, l'appel de fonctions en une DLL _nostub est plus lent qu'en une librairie statique. (Notre système de DLLs n'est pas du tout fait pour les fonctions exécutées des milliers de fois par seconde!)

Ça, je ne le savais pas. c'est vrai que c'est dommage.

Une DLL est une librairie!

Oui, excuse-moi. Je voualsi avoir plusieurs exemples à donner avant les pts de suspensions donc j'ai mis ça sans réfléchir

Justement... "en dehors de celles de la DLL
" ...

Oui, mais normalement, "celles de la DLL" sont des fonctions très utilisées, donc ça revient au même niveau place que si on les avaient mises en statique.
Le fait qu'il y ait un bout de code pour prendre en charge la DLL, ne dis pas que c'est de la place gaspillée, vu que ça permet d'avoir la DLL, donc de ne pas recopier les fonctions plusieurs fois, si on a plusieurs programmes qui utilisent xlib.


Voilà, je trouve qu'utiliser une DLL peut se révéler très pratique, mais en fait, dans le cas de Xlib, la dll ne fait que 6ko (8-2 pour la prise en charge), sur un prog de plusieurs dizaines de ko, c'est inutile.
Ce serait utile dans le cas du FAT engine : la dll contient des infos que (enfin, ça je ne suis pas sûr, mais de toute façon, avec le 2ème argument ça tient quand même debout) tu es obligé d'utiliser (tables de précalcul) pour faire ton raycaster, donc il n'y a pas vraiment de perte de place (de toute façon, un prog qui utilise le FAT engine ferait plus 64ko si le FAT engine était en statique, donc on serait obligé d'avoir 2 fichier, comme là, sauf que plusieurs progs peuvent se servir de 2ème (la DLL quoi), ce qui ne serait pas le cas en statique).
Mais je pense qu'il pourrait être utile d'utiliser une DLL si la taille des fonctions OBLIGATOIREMENT utilisées est supérieure à 10ko. Là, ça offrirait un gain de place si plusieurs progs se servent de la lib.

TiMad
a écrit : Et voila encore une preuve de la debilité des representant de l'équipt tigcc!

bon deja pour KK:
"Oui, 1000 sur plusieurs dizaines de milliers, c'est négligeable. "

MDR. tu racontes vraiment n'importe quoi, et tu espere que ca va passer.
Le jour ou une routine de sprite depassera les 7 Khz en maské tu m'appelles (ouia bonil se pourai que dans la version 2.00 ca s'en approche, mais je pense que c'est encore loin...) Extgraphlib doit faire un truc du genre 2-3Khz .. soit 2/3 ksprites seconde.. donc faux vraiment que t'arrete de sortir des CONNERIE pour mettre en avant une lib c qui n'est pas du tout optimisée pour la programmation graphique!

C'est quoi ce bench?! Selon mes benchs à moi, XLib est loin d'être 2 fois plus rapide que ExtGraph!
Je me suis peut-être trompé en parlant de plusieurs milliers de sprites par seconde (je me rappelais mal des nombres de sprites par seconde de mes benchs, mais je me rappelle très bien des rapports de vitesse ExtGraph/GenLib/XLib), mais si c'est le cas, ça veut également dire que tes 1000 sprites par seconde de différence sont probablement exagérés. En tout cas, je veux voir ton bench qui te donne ce résultat!

D'ailleur le format Kernel est bien plus propre que le format dll!

En quoi le format DLL de TIGCC n'est-il pas "propre"?

Et puis si on a une dll c'est toujours du nostub.. alors arrete d'etre ***.

Techniquement oui, mais ce n'est plus vraiment du _nostub en pratique.

D'ailleur si je met un kernel dans mon prog ce sera quand meme du nostub ( neu²)!

Non, ce n'est plus du _nostub, parce que le nom dit "no stub"! Si tu mets un kernel dans le programme, il y a un stub!

jackiechan
a écrit : Voilà, je trouve qu'utiliser une DLL peut se révéler très pratique, mais en fait, dans le cas de Xlib, la dll ne fait que 6ko (8-2 pour la prise en charge), sur un prog de plusieurs dizaines de ko, c'est inutile.

En effet.

Ce serait utile dans le cas du FAT engine : la dll contient des infos que (enfin, ça je ne suis pas sûr, mais de toute façon, avec le 2ème argument ça tient quand même debout) tu es obligé d'utiliser (tables de précalcul) pour faire ton raycaster, donc il n'y a pas vraiment de perte de place (de toute façon, un prog qui utilise le FAT engine ferait plus 64ko si le FAT engine était en statique, donc on serait obligé d'avoir 2 fichier, comme là, sauf que plusieurs progs peuvent se servir de 2ème (la DLL quoi), ce qui ne serait pas le cas en statique).

Je n'ai jamais contesté le fait que FAT Engine soit une librairie dynamique. Vu sa taille de presque 64 KO, c'est clairement nécessaire. Il ne resterait plus rien pour le programme si elle était en statique. FAT Engine est un exemple d'utilisation correcte de DLLs.

Mais je pense qu'il pourrait être utile d'utiliser une DLL si la taille des fonctions OBLIGATOIREMENT utilisées est supérieure à 10ko. Là, ça offrirait un gain de place si plusieurs progs se servent de la lib.

Là, je ne suis pas d'accord. Je pense plutôt qu'il pourrait être utile d'utiliser une DLL si la taille des fonctions qui ont de fortes chances d'être utilisées (il n'y a presque pas de fonctions "obligatoirement" utilisées dans une librairie!) est supérieure à 32 KO (32 KO parce que c'est la moitié de la taille maximale d'un programme). Et j'ai bien dit "il pourrait". Si les programmes qui utilisent la librairie seront en général de taille inférieure à x KO (x<=32, je précise) sans compter la taille de la librairie, alors mettre la librairie en DLL n'est une bonne idée que si elle fait plus de 64-x KO.

ah ça ce que fait la tict c parfait et dans les règles

Kevin Kofler a écrit :
Là, je ne suis pas d'accord. Je pense plutôt qu'il pourrait être utile d'utiliser une DLL si la taille des fonctions qui ont de fortes chances d'être utilisées (il n'y a presque pas de fonctions "obligatoirement" utilisées dans une librairie!) est supérieure à 32 KO (32 KO parce que c'est la moitié de la taille maximale d'un programme). Et j'ai bien dit "il pourrait". Si les programmes qui utilisent la librairie seront en général de taille inférieure à x KO (x<=32, je précise) sans compter la taille de la librairie, alors mettre la librairie en DLL n'est une bonne idée que si elle fait plus de 64-x KO.

Oui, mais imagine une lib pour utilise un moteur 3D. On met des trucs dedans (tables de précalcul de cos, sin, ... et fonctions très utilisées).
Si ça se trouve, la DLL ne fait que 20ko, toi, tu fais ton jeu qui fait 30 ko (ça fait au total 50 ko, ce qui est inférieur au 64ko).
Donc, d'après ce que j'ai compris, tu penses que c'est mieux d'avoir une lib statique au lieu de la DLL.
Mais dans ce cas, si deux progs utilisent la lib (statique donc) 3D, on se retrouve avec des fonctions recopiées plusieurs fois. sur les 20 ko de la lib, on n'en utilise que 15, par ex, ça fait 30ko au lieu de 22ko (20+code chargement) si elle avait été en DLL.
Rien que là, ça fait une différence de 8ko, ce qui est tout de même plus que les 5ko de fonctions inutilisées...
Vala.
Bon, d'un autre côté, c'est rare d'avoir plusieurs jeux qui utilisent la même lib sur sa TI.
et dans ce cas, on perd 5ko de fonctions inutilisées + 2 ko de code de chargement (soit 7ko au total, ce qui n'est pas négligeable).

La DLL n'est utile que si l'utilisateur a plusieurs progs qui l'utilisent, sinon ça ne sert strictement à rien.
La solution serait de faire 2 versions du prog, une avec DLL et une avec la lib statique. Et si l'utilisateur utilise 1 seul prog se servant de la lib, il envoie la version statique, mais si il en utilise plusieurs, il envoie les versions DLL de chaque prog.
Ce serait chiant pour les programmeurs, mais les utilisateurs seraient gagnants à tous les coups, au niveau de la place occupée.

Je vois d'ici les newbies arriver en criant pour utiliser des jeux!

j'avoue

Mais je pense aussi que faire deux versions pour chaque prog serait, sinon la meilleure, au moins une bonne solution. Mais je doute que beaucoup de gens le fasse. A moins de rajouter une fonction automatique dans le compilo qui génèrerait automatiquement (bah oui si c'est une fonction automatique) les deux version.