Kernel vs Nostub? - Page 9

Au fait Kevin je tiens à te dire (et je sais que je ne suis pas le seul à penser ça) que Genlib n'est pas dur d'utilisation. C'est juste la doc qui est grosse, nuance (et paradoxe).

On va dire que son utilisation à l'avantage de ressembler à une API connue ...

Ok... donc le mode kernel est celui que j'utilisais avec Fargo, et le mode _nostub utilise les possibilités assembleur données par texas depuis la 92+, c'est ça ?
Je comprend mieux les avantages et les désavantages de l'un et de l'autre, si la table des relogements est différente sur le mode kernel.

Sinon, tu refuses la librairie de fonctions sous le couvert qu'il faille remplacer un fichier "comme avant"... je ne parlais pas spécialement de prog TI, mais aussi de prog PC. SI une DLL est bien écrite, la remplacer elle seule permet de ne remplacer qu'un fichier de petite taille (dll de fncts<(dll données ou programme))... J'admet que le problème c'est que les DLL windows sont souvent mal écrites et qu'une nouvelle version (notamment du temps de W3xx et la célèbre lib CTL3D ou des libs VBXXX) implique malheureusement des changements complets. A priori, le support des versions de dll (vérification d'une version avant remplacement) à partir de W95 et + fait que les programmeurs font bcp plus attention lorsqu'ils implémentent leurs librairies.

nEUrOne
a écrit : On va dire que son utilisation à l'avantage de ressembler à une API connue ...

Et quelle est cette "API connue"? La Genesis/Megadrive que genlib est censée imiter n'en est certaiment pas une.

Nil
a écrit : Ok... donc le mode kernel est celui que j'utilisais avec Fargo, et le mode _nostub utilise les possibilités assembleur données par texas depuis la 92+, c'est ça ?

Oui. (Même si PpHd va encore me gueuler dessus si je ne précise pas qu'il y a quand-même quelques petites différences entre Fargo et les kernels sur TI-89/92+/V200. Mais ces différences ne changent pas grand chose.)

Je comprend mieux les avantages et les désavantages de l'un et de l'autre, si la table des relogements est différente sur le mode kernel.

En effet, la table des relogements est différente. AMS n'utilise les relogements que pour ce que les relogements sont censés faire: reloger des adresses absolues à l'intérieur du programme. Les kernels relogent aussi plusieurs types d'importations: librairies, ROM_CALLs, RAM_CALLs. En _nostub, on accède aux ROM_CALLs à travers une table exportée par AMS, et dont l'adresse est placée en l'adresse constante 0xc8 (dans la table des vecteurs). Les RAM_CALLs n'existent pas et on utilise des ROM_CALLs à la place. (D'ailleurs, ces noms sont mal choisis: un RAM_CALL ne correspond pas forcément à une adresse en RAM, et un ROM_CALL ne correspond pas forcément à une adresse en FlashROM. La vraie différence est que les ROM_CALLs sont dans la table des sauts de AMS, alors que les RAM_CALLs sont dans une table du kernel.) Quant aux librairies dynamiques, si on en veut, on doit les importer soi-mêmes.

Sinon, tu refuses la librairie de fonctions sous le couvert qu'il faille remplacer un fichier "comme avant"... je ne parlais pas spécialement de prog TI, mais aussi de prog PC. SI une DLL est bien écrite, la remplacer elle seule permet de ne remplacer qu'un fichier de petite taille (dll de fncts<(dll données ou programme))...

Une DLL contient normalement des tas de fonctions que le programme n'utilise pas forcément, donc le fichier à remplacer n'est pas vraiment de petite taille.

La bonne solution au problème du temps de téléchargement des mises à jour est de réduire la taille des programmes. Les programmes pour PC sont souvent immenses. Les raisons sont en général:
- langages de programmation inefficaces. Le C++ est encore parmi les moins pire qu'on rencontre, et pourtant c'est déjà une catastrophe du point de vue de l'efficacité.
- abus d'animations ou d'autres types de ressources multimédia.
- compilation avec les mauvais flags (optimisation en vitesse plutôt qu'en taille). Il faut compiler en -Os. Et ne pas oublier de stripper les exécutables: les informations de débogage n'ont rien à faire dans une version release d'un programme.
- compression inadaptée des fichiers à télécharger (ZIP ou pire). bzip2 n'est pas là pour les chiens.

J'admet que le problème c'est que les DLL windows sont souvent mal écrites et qu'une nouvelle version (notamment du temps de W3xx et la célèbre lib CTL3D ou des libs VBXXX) implique malheureusement des changements complets.

En effet.

A priori, le support des versions de dll (vérification d'une version avant remplacement) à partir de W95 et + fait que les programmeurs font bcp plus attention lorsqu'ils implémentent leurs librairies.

Tu penses vraiment? Je n'ai pas l'impression. Le "DLL hell" est loin d'avoir disparu avec Windows 95.
(D'ailleurs, PreOs utilise aussi un numéro de version de DLL.)

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

C'est bien ce que je voulais dire. Emuler le format kernel doit être plus lourd que de l'utiliser simplement

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

Dans Preos c'est une très bonne idée car ca permet de l'utiliser une fois et un seule et on est tranquille
[/cite]

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

Je le comprends très bien. on a juste un point de vue différent, pour un fois je pense plus a assister le débutant que toi c'est tout.

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

Encore un qui crois en ce mythe que les libs statiques feraient gagner de la place. La taille du programme nostub augmente et finit par dépacer la taille du prog kernel+lib si des fonction sont réutilisées dans plusieurs programmes.

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

Oui mais preos contient HW2TSR et plein de chose supplémentaire qui font que 5ko s'est vraiment négligable. Pour s'en passer en nostub, il faudrait plein de TSR qui au final finiraient par consommer autant de place.

Je ne dis pas qu'elle est plus rapide, je dis qu'elle est:

-plus flexible: certes mais rien ne t'empeche d'utiliser d'autre lib en supplément des fonction que tu trouverait trop restrictives de plus elle convient sans problèmes à la plus grande majorité des jeux
-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.
-probablement plus stable : affirmation gratuite sans aucun fondement -> poubelle
-suffisament rapide pour pratiquement toutes les utilisations pratiques: certes mais genlib l'est encore plus.

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

Je suis d'accord avec toi c'est plus logique de laisser les DLL au code , mais si ca arrange le programmeur de faire comme cela, je vois pas ce qu'il y a de vraiment gennant vu que de toute facon les LIB ne peuvent pas etre édité ou executé(en tout cas c'est plus propre qu'un ASM ou EXPR)
Vouloir contraindre le programmeur est totalement stupide et égocentrique comme position.

Une DLL contient normalement des tas de fonctions que le programme n'utilise pas forcément, donc le fichier à remplacer n'est pas vraiment de petite taille.

c'est une DLL mal concue alors

La bonne solution au problème du temps de téléchargement des mises à jour est de réduire la taille des programmes. Les programmes pour PC sont souvent immenses. Les raisons sont en général:
- langages de programmation inefficaces. Le C++ est encore parmi les moins pire qu'on rencontre, et pourtant c'est déjà une catastrophe du point de vue de l'efficacité.
- abus d'animations ou d'autres types de ressources multimédia.
- compilation avec les mauvais flags (optimisation en vitesse plutôt qu'en taille). Il faut compiler en -Os. Et ne pas oublier de stripper les exécutables: les informations de débogage n'ont rien à faire dans une version release d'un programme. - compression inadaptée des fichiers à télécharger (ZIP ou pire). bzip2 n'est pas là pour les chiens.

Tout a fait d'accord mais bzip2 sous Windows c'est pas le pied.

tiens au fait, a propos de stripper lee executables, il y a bien strip sous unix qui vire tous les commentaires du compilateur, mais l'equivalent sous windows c'est quoi?

heu et puis:

"- compilation avec les mauvais flags (optimisation en vitesse plutôt qu'en taille). Il faut compiler en -Os."

depuis quand "il FAUT" ? en lisant ca on dirait que ceux qui compilent avec -O3 font une erreur... dans ce cas pourquoi ne pas simplement supprimer le flag -O3 hein? si il est inutile et si c'est mal de l'utiliser....
nimporte quoi ton raisonnement... bcp de monde se contrefout de la taille finale, surtout sur pc (bon ok c'est chiant a downloader) et prefere nettement la vitesse d'execution...

Allegro?

Ben, je n'ai pas beaucoup de temps pour programmer, améliorer ExtGraph... Il faut que je m'occupe aussi de tthdex...

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

oui, sauf que si l'image arrive aprés la "réactualisation" de l'image, elle est zapper, donc la suivante est décaler
C pour ça que la valeur reste théorique et que tu trouve que 20 fps, c mieux

XLIB POWERRRRRRRRRRRRRRRRRRRRRRR!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Bon, je reprends à partir du post 233...
(page 8, donc)

/me a dit

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

et jackiechan a réondu en se lolant de rire...
je disais ça de façon assez sérieuse, en fait
Dans KII, pour l'instant, j'utilise Extgraph pour les menus, et Xlib pour le reste (au moment où j'ai commencé, Xlib travaillait avec des GPlan plus gd que l'écran, ce qui était peu pratique pr les menus... il va de soi que, en passant à une version récente de Xlib, je ferai tout avec Xlib, afin de ne pas bouffer de mémoire à utiliser d'autres fonctions graphiques qui ne me sont pas indispensables )

/me a dit

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

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

certes, elle devrait l'être, il me semble aussi
mais elle ne l'était pas à l'époque
(et ne l'est, je crois, toujours pas actuellement)

/me cite Kevin (post 233 et suivants)

Mais maintenant, le support des DLLs y est déjà

oué, mais il me semble qu'on ne peut avoiur d'une seule Dll par programme, non ?

(en parlant des RC de gestion des menus Custom du TI-BASIC) Déjà, ce sont des cmd_*, qui sont prévus avant tout pour l'usage interne de l'interpréteur BASIC, mais qui sont exportés parce qu'ils peuvent aussi être utiles pour les programmeurs C

Certes, ils sont prévus pr l'usage d l'interpréteur... cela dit, utiles pr le codeur C ?
il me semble qu'on ne peut pas définir de menu custom à partir du C qui reste valide depuis le TIOS ensuite...
(du moins, c ce qu'on m'avait répondu voila bien longtemps, qd j'avais posé la question)
alors, l'utilité pr le codeur C.......

(parlant de vcbprintf) Et elle est très facile à trouver sous n'importe quelle version de AMS

Je croyais qu'il ne fallait pas se fier sur des "hacks" de ce style...
ceux proposés par PpHd marchent aussi sous n'importe quelle version d'AMS... et pourtant, tu n'en veux pas...
il fo te rappeler ce que tu dis à PpHd : n'importe quelle version d'AMS EXISTANTE
(erf... je cherche pas à être méchant, et tu vas surement trouver un moyen de me contrer ça... mais ça me titillait )

Mais franchement, fprintf(stdout ou fprintf(stderr (l'utilisation la plus courante de std*) n'apporte pas grand chose en fonctionnalité par rapport à un simple printf(

je me trompe peut-être, mais il me semble qu'il est possible de rediriger stderr, stdout et stdin vers (ou depuis) des fichiers, alors qu'on ne peut pas avec printf ?
(pas sûr qu'on puisse pas avec printf, remarque...)

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

Disons que, sur ce point, tout le monde n'a pas ta perfection

Imagine un écran 128×128, et une matrice clavier qui n'a rien à voir avec celle de la TI-89 ni avec celle des TI-92+/V200

je croyais qu'il fallait attendre au moins 2006 avant un nouveau modèle de machine...
Et qui sait ce qu'on sera et ce qu'on fera en 2006

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

ça dépend de combien de fois 10 secondes, et de 10 secondes tous les combiens de temps

(en parlant du BitMapPut de pedrom) Ta routine n'est même pas clippée

ma foi, puisque le biutmapput d'AMS n'est pas clippé, je ne vois pas l'utilité de le clipper dans pedrom, qui est destiné à faire tourner des progs fonctionnant sous ams (sauf pr la mémoire, pr l'instant)...
(heu... enfin... en supposant que celui d'ams n'est pas clippé... sinon, si ça l'est dans ams, il serait bon que ça le soit dans pedrom )

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

on alloue une deuxième bloc
(solution bourrin...)

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

que tu empoie le terme "Dll", ça veut tout de suite dire "Windows", dans la tête de celui qui entend...
et, par extension, le "mising dll... réinstaller l'application peut corriger le pb" (ou qqc dans ce stuyle)

(en parlant de TN qui met deux mois avant de corriger tictex) Patience, il n'a pas que ça à faire

Ben, qd PpHd a mis 2 mois pr corriger le pb que tu lui avait reporté dans SMA, tu as gueulé... PpHd lui aussi a pas que ça à foutre, je suppose !
Qd c'est ppHd qui fait attendre les autres, tu gueules, et qd c'est TN qui les ait attendre, c'est "patience, il a pas que ça à faire" ?
(je m'emporte )

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

bof, mis à part les instructions préprocesseur, tu peux mettre tout ton prorgramme en une seule ligne... c'est un des immenses avantages du C/C++ : tu n'a pas besoin de perdre plein de mémoire en faisant des fichiers énormes à cause des caractères de retour à la ligne

(en parlant de la super-arme de KII qui génére 96 missiles simultanément) Ben, si on est démesurés, il ne faut pas s'attendre à que ce soit rapide

je ne cherche pas à ce que ce soit "rapide", mais à ce que ça ne ralentisse pas beaucoup !
(parce que "rapide", codé en C, sur un CPU à 10MHz (j'ai une HW1), en plein écran (j'ai une 92+), avec tout ce qu'il y a à gérer, je pense que ce soit possible, du moins vu ce que j'appelle "rapidité" ! Mon but est donc que ça ne rame pas, ou que ça ne rame qu'un strict minimum... (en considérant que ça rame en dessous des 100 fps (je dois en être à 20 en moyenne, maximum, et ça peut descendre à 5 avec 120 missiles du joueur à l'écran plus 10/15 de l'ennemi; plus le boss, plus l'arrière plan)

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

c aussi grave plus lent
et les fonctions de scrolling de Extgraph forcent tout l'écran à scroller à la même vitesse, dans la même direction... ce qui ne peut être pour un jeu d'action... (du moins, pas pour K, ni KII)

Pour un shell, AMS suffit

si tu veux le faire en grays, non
si tu veux faire une compression à la ziplib (compatible ziplib), non, à moins recoder ziplib en statique
...

/me cite Kevin, post 235

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

et après, tu te plaint que ta calc ait la mémoire pleine...

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

c'est d'ailleurs bien dommage...

Aucun de ces jeux n'a vraiment de difficultés à atteindre les 10 FPS

Krypton, que tu cite, à parfois un peu de mal (encore que... peut-être pas qd même pr 10 fps )... mais je dois reconnaitre que je n'ai que des algos merdiques
KII, qui propose bcp plus de choses, tourne parfois à moins de 10 fps dans les moments ritiques... mais il y a des algos que je pense pouvoir optimiser (parce que là, j'utilise des trucs un peu barabarres et pas malins)

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

Pour l'effet graphique
96 missiles, même s'ils ne sont pas très puissants, mais qu'ils partent dans toutes les directions, cela a quelque chose d'impression du point de vue visuel Je m'en suis bien rendu compte en faisant tourner KII auprès de quelques potes et en regardant leur tête qd ils appuyaient pr la première fois sur la détente de cette super-arme
Cela dit, ce n'est qu'une des trois super-arme que j'ai dans KII
J'en ai une autre, qui est un super gros missile, qui tue tous les ennemi à l'écran, et détruit la moitié des murs destructibles. l'effet graphique est moins impressionnant... mais c'est limite plus efficace... quoique cette arme ait besoin d'un délai pour agir (comment faire souffrir le joueur qui, désespéré, tire sa dernière super-arme... et qui se rend compte qu'il lui faut plus de deux secondes pour devenir active #sadique#)
Et la dernière sert à paraliser les ennemis... ils ne se déplacent plus, mais peuvent encore tirer... celle là, je l'ai implémentée juste pr le fun (il me restait un bouton dont je ne savais pas quoi faire, d'une ()), et, de deiux, cette arme enlève un point d'énergie qd on l'utilise... je m'amuse, qd je code, en pensant au "povre petit joueur" )

/me cite jackiechan, 236

Pour le plaisir d'avoir une arme qui tire vraiment partout !

et voila

Mais c'est vrai qu'avec 96 missiles, ça fait beaucoup... Il pourrait en mettre le quart (24) et ça suffirait

moué... mais on verrait plus que c une super-arme, vu le nombre de missiles que les autres armes "normales" sont capables de générer
(qd on a toutes les armes, il doit y avoir plus de 25 missiles à l'écran simultanément, j'estime... rien qu'avec le drone (8 missiles), les doubles tris avant, les tirs sur les côtés, le lance-fusées, le laser... et qui retirent en général une, deux, voire trois fois avant que les premiers missiles soient sortis de l'écran...)

/me cite Uther, 237

(réondant à Kevin, qui critiquait mes 96 misiles ) Et pourquoi pas faire un jeu en mode texte! S'il veut faire des effet visuel qui rendent bien c'est son droit!

merci de ton soutient
Je me permet de rajouter que KII, c'est pour me faire plaisir en codant, d'une, et pr m'éclater en y jouant (enfin, vu le peu de niveau qu'il y a, je m'éclate pas vraiment...) ; et les effets visuels me servent bien pr ça
Les murs animés, ils ne sont que pour ça, d'ailleurs, pr les effets visuels ; des murs non animés (qui sont plus nombreux que ceux animés, je le précise) auraient suffit... mais un peu de mouvement au milieu fait de l'animation )
Le scrolling d'arrière plan, pareil, il ne sert qu'à faire joli...
J'ai une arme qui tire des missiles en hélice (elle tire en haut, puis en haut à droite, puis à droite, puis en bas à droite, etc... avec un délai entre chaque tir => ça dessine une hélice )... Elle est pas particulièrement utile : le drone tire lui aussi dans en gros toutes les direction, et retire dans chaque direction plus vite que l'hélice (qui doit faire une rotation compléte)... mais l'effet visuel de l'hélice est clairement plus joli !)

/me cite Kevin, 239
[cite]N'oublie pas que PreOs prend plus de 5 KO en archive et plus de 3 KO en RAM[cite]
je considére que ça ne fait que très peu de "sacrifice" de mémoire à faire par rapport à tous les avantages apportés...

(en parlant d'extgraph par rapport à genlib (ou Xlib ou graphx)) suffisamment rapide pour pratiquement toutes les utilisations pratiques

sauf pour les jeux demandant bcp de puissance...
Qd tu cherche à optimiser tes algos pr gagner quelques millisecondes à donner à d'autres trucs que tu veux rajouter, c pas pr qu'une librairie d'affichage graphique te bouffe un temps fou !


/me passe à la page 9

(nEUrOne, parlant de genlib, ou Xlib) On va dire que son utilisation à l'avantage de ressembler à une API connue

clair que qd tu passe à allegro et que tu réussi à l'utiser, c pas grace à l'exemple de extgraph
(si tant est que tu parlais d'allegro... je sais pas trop, mais vu que le #include<std_disclaimer.h>W de genlib ressemble fort à celui d'allegro....)

/me cite Uther, 244

Oui mais preos contient HW2TSR et plein de chose supplémentaire qui font que 5ko s'est vraiment négligable. Pour s'en passer en nostub, il faudrait plein de TSR qui au final finiraient par consommer autant de place

... voire plus

(parlant à Kevin)Je suis d'accord avec toi c'est plus logique de laisser les DLL au code , mais si ca arrange le programmeur de faire comme cela, je vois pas ce qu'il y a de vraiment gennant vu que de toute facon les LIB ne peuvent pas etre édité ou executé(en tout cas c'est plus propre qu'un ASM ou EXPR)

de toute façon, il n'y a que TRES PEU de gens parmis les utilisateurs des programmes qui sauront si la Dll contient des donnée ou du code (du moins, si tu ne le dis pas ouvertement )
dans KII, je n'utilise pas de Dll, mais je met des fonctions (donc, du code ) dans un de mes fichiers externe qui est conçu pr contenir des données... cela dit, si je ne le dis pas, personne ne le sait... (d'autant plus que le tout est compressé )

/me cite Ximoon, 247

Allegro?

enfin un qui pense comme moi



/me n'a pas vu de post après le 250
(page enregistrée, puis commentaires rédigés hors connexion, sur la base de que qui avait été écrit (jusqu'au post 250, donc) au moment de l'enregsitrement)

Je n'ai jamais utilisé Allegro mais rien que le readme, ça suffit

[EDIT]me suis planté de topic en postant
movaise fenêtre
(et encore, heureusement que yAro a été sympa et a ajouté les titres aux fenêtres de posts )

Ximoon> oué, c vrai que le readme comence avec le "include <std_disclaimer.h>
pour mon projet de fin d'iut, j'utilise Allegro (peut-être pas des plus puissantes, je sais pas, mais elle fait ce dont j'ai besoin, et elle est simple d'emploi )...
=> j'ai mis cet include (en commentaire, bien sur), ainsi que le petit texte qui va avec dans tous mes sources les profs qd ils vont regarder les sources, il vont pas se poser des questions

Euh... je crois qu'en fait ça n'est pas le bon topic

oué, je m'en suis rendu compte juste après avoir fait alt+entrée pr envoyer le post

>>Mais franchement, fprintf(stdout ou fprintf(stderr (l'utilisation la plus courante de std*) n'apporte pas grand chose en fonctionnalité par rapport à un simple printf(
>je me trompe peut-être, mais il me semble qu'il est possible de rediriger stderr, stdout et stdin vers (ou depuis) des fichiers, alors qu'on ne peut pas avec printf ?
(pas sûr qu'on puisse pas avec printf, remarque...)
les flux c'est très pratique sur PC mais sur calculette je vois mal t'interet.

>et jackiechan a répondu en se lolant de rire...
Il faisait sans doute ca car releger un lib que la TICT veut un concurent de Xlib,genlib,GraphX au menus n'est pas très valorisant.

>oué, mais il me semble qu'on ne peut avoir d'une seule Dll par programme, non ?
Bien sur Kevin le repete assez les DLL n'ont pas étés ajoutés pour une utilisation normale en lib dynamique mais pour contourner le problème de la limite a 64Ko. Si tu veux utiliser de vraies lib dynamiques, le mode kernel est vraiment prévu pour.

> Imagine un écran 128×128, et une matrice clavier qui n'a rien à voir avec celle de la TI-89 ni avec celle des TI-92+/V200
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. Et s'il y a un changement de resolution de l'écran ca m'étonnerais que ce soit pour une résolution inférieure. Par contre je ne vois vraiment pas comment le nostub pourait s'en sortir.

> (en parlant du BitMapPut de pedrom) Ta routine n'est même pas clippée
Le but est d'avoir un fonctionnement très proche de celui d'AMS ce n'est donc vraiment pas grave

> Ce n'est pas parce que cette abbréviation est utilisée par Windows qu'on ne peut l'utiliser pour rien d'autre
Certes mais DLL n'est utilisée que sous Windows alors quand on de ce nom a un système de lib dynamique il faut s'attendre a ce type de comparaison

>>Les autres auront beaucoup plus de chances de l'utiliser si tu la mets en statique. La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub
>c'est d'ailleurs bien dommage...
C'est bien vrai mais un jeu comme krypton gagnerai a etre en kernel tu ne le fais pas c'est dommage

Il faisait sans doute ca car releger un lib que la TICT veut un concurent de Xlib,genlib,GraphX au menus n'est pas très valorisant.

certes.
et je présente mes excuse à ceux que mes propos ont pu vexer
(mais ce que j'ai dit n'est (pour l'instant ) que vérité pour le cas de KII)

Bien sur Kevin le repete assez les DLL n'ont pas étés ajoutés pour une utilisation normale en lib dynamique mais pour contourner le problème de la limite a 64Ko. Si tu veux utiliser de vraies lib dynamiques, le mode kernel est vraiment prévu pour

pr ce qui est du kernel, je suis d'accord.
pr les dll... ma foi... c dommage

C'est bien vrai mais un jeu comme krypton gagnerai a etre en kernel tu ne le fais pas c'est dommage

qu'est-ce que j'y gagnerai ?
(parlons de KII plutôt que de K, je préfèrerai, vu que KII est plus complet... mais si tu veux parler de K dont des versions sont sorties, pas de pb )

>Une DLL contient normalement des tas de fonctions que le programme n'utilise pas forcément, donc le fichier à remplacer n'est pas vraiment de petite taille.
Tout depend de la conception de la DLL.

>La bonne solution au problème du temps de téléchargement des mises à jour est de réduire la
>taille des programmes. Les programmes pour PC sont souvent immenses.
Oué.

> Les raisons sont en général:
>- langages de programmation inefficaces. Le C++ est encore parmi les moins pire qu'on
>rencontre, et pourtant c'est déjà une catastrophe du point de vue de l'efficacité.
Tout depend comment il est utilise.

>- abus d'animations ou d'autres types de ressources multimédia.
Ok.

>- compilation avec les mauvais flags (optimisation en vitesse plutôt qu'en taille).
>Il faut compiler en -Os. Et ne pas oublier de stripper les exécutables:
Compilation en O3 ou plus. Un O2 suffit largment a mon avis.
Sauf pour certaines parties du code. Mais tout compiler en plus qu'en O2 me parait abuser.

> les informations de débogage n'ont rien à faire dans une version release d'un programme.
Ok.

>- compression inadaptée des fichiers à télécharger (ZIP ou pire). bzip2 n'est pas là pour les chiens.
Je veux bien distribuer en bz2, mais je sens que des personnes vont gueuler

>On ne sait jamais. Il pourrait toujours y avoir une erreur dans tes macros.
Mais dans ce cas, l'erreur ne pourrait surgir a cause d'une mise a jour materielle.

>Oublier ce qu'on a programmé et publié??? Moi, je sais très bien ce que j'ai publié vu que
>ça traîne encore sur mon site (sauf pour DB92, parce que ma version n'est plus à jour -
>hwti l'a repris en partant de mes dernières sources).
Ben par exemple Fer3 v2.30 ou fer3-tibasic.
On ne peut pas dire que je les mets a jour souvent

>Mais alors pourquoi ta réponse "Mais alors pourquoi tu en tiens compte dans tes calculs ?"?
Je repondais a ta reflexion.

>On peut le faire en plusieurs fichiers.


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

>Ce n'est plus la peine.
C'est ce que je veux dire depuis trois jours !

>Ce que je dis, c'est que les développeurs de kernels de l'époque auraient dû le faire.
Tout a fait d'accord !

>Ils ne l'ont pas fait. Maintenant, c'est trop tard, parce que de toute façon plus personne
>n'utilise ces ROM_CALLs. (Si quelqu'un utilise ces fonctions maintenant, il utilise les versions dans tigcc.a.)
Ou ils programment en ASM.

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

>On voit que je n'ai pas du tout l'habitude de compter en cycles.
Tu vois qu'il y a des cas ou ca peut se discuter. Je ne dis pas que pour un shell ca soit insuffisant.
Il faut des reponses adaptees aux besoins.

>Ça dépend de ce qu'on entend par "lent". À 1 FPS, ça ne doit pas rendre très bien
>(alors qu'un Mario à 1 FPS passe encore).
A condition de faire des niveaux tres adaptes !

>Mais un Sonic tournant en le tiers de la vitesse de SMA serait tout à fait jouable à mon avis.
> (SMA est trop rapide. Du moins sur VTI, avec "Restrict to actual speed" évidemment.)

Je suis un rapide ! J'adore les jeux rapides !

>Et si on n'en a pas besoin?
On rajoute un petit effet d'intro pas trop cher en memoire et joli.

>Et ben, tu "spilles" un registre sur la pile, tu l'utilises pour tes calculs et tu le restaures.
>GCC fait ça systématiquement s'il a besoin de plus de registres qu'il n'y en ait de disponibles.
Mais ca ralentit plus et consomme plus de place que de faire des modifications de constantes.
(Quoique la place, ca puisse se discuter).

>Tant pis, tu consommes un registre de plus en global et tu "spilles" tes registres en local.
Ce n'est pas une solution que j'aprecie.

>LOL, c'est la première fois que tu es en faveur d'une accélération de ExtGraph.
Je n'ai jamais ete contre une acceleration d'ExtGraph. Mais c'est pas moi qui le fera.
Quoique en fait ?

>Plus la peine de tester alors?
si quand meme.

>Il pourrait utiliser un ST_helpMsg plutôt qu'un DlgMessage, ça serait probablement moins dangereux.
Je pense aussi.

>J'en vois sur Internet, pas dans mon entourage immédiat.
Et bien convertit a Preos

>Mais SMA n'est plus compatible avec DoorsOS, par exemple.
La premiere version de SMA n'a jamais fonctionne avec DoorsOS
Je ne fais que respecter la legende

>Ce que je veux dire, c'est que pour toi, "centraliser" = imposer.
Si je voulais imposer, ca fait longtemps que j'aurais fait un virus
Et je n'impose rien. Pas meme la librairie de compression.
Rien n'empeche JM, Xavier ou Olivier, ou un autre de mettre a jour
leurs kernels. Je suis l'un des rare a tenir a jours les modifications
du format dans des docs.

>1. Tu envoies le kernel à la calculatrice.
>2. Tu envoies les librairies (par exemple le pack stdlib) à la calculatrice.
>4. Tu envoies le programme à la calculatrice.
C'est trois etapes s'effectuent en meme remps.
>3. Tu exécutes le kernel. C'est surtout ça qui est totalement contre-intuitif.
>On s'attend à ce que le programme marche sans avoir lancé quoi que ce soit avant.
Pourquoi ? Je connais des programmes DOS qui ne fonctionnent qu'apres avoir lances certains drivers ou autres choses

>5. Tu exécutes enfin le programme.

>En _nostub, c'est beaucoup plus simple.
>1. Tu envoies le programme à la calculatrice.
Tu envoies les fichiers de donnees.

>2. Tu exécutes le programme.
>C'est totalement intuitif.
L'autre aussi.

>- Pas assez de RAM pour faire tourner un bon compilateur C (comme GCC).
>- Processeur trop lent pour faire tourner un bon compilateur C (comme GCC).
Ben il suffit d'utiliser d'autres compilateurs C moins gourmand en ressource.
J'ai deja dit que je trouvais GCC sur-dimensionne.

>- Pas assez d'archive pour pouvoir stocker de grandes sources.
Bon Pedrom arrive

>Et à ces problèmes matériels vient s'ajouter la limite de taille des fichiers
>trop petite pour de grandes sources.
Arg. Je peux le corriger dans Pedrom mais adieux la compatibilite anterieure
des fichiers > 64K.

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

>Ça économise de la place, mais c'est un hack
En quoi c'est un hack ? Tu trouves que tout ressemble a un hack ces temps ci

>Le problème, c'est que tu essayes de faire évoluer un vieux système dépassé.
Il n'y a que toi pour le trouver depasser. Je pense que meme TN ou ZJ ne
pensent pas qu'il est depasse (ca veut pas dire qu'ils l'aiment !)

>Ça, ça ne change rien au principe général. C'est d'ailleurs un changement négatif.
Je suis d'accord sur le second point.

>Mais on devrait au moins essayer de le faire.
C'est ce que je fais.

>Et ça n'explique toujours pas la corrélation que j'ai observée entre l'utilisation de genlib
>et le fait que les jeux restent bloqués en état de bêta.
Hum.
Tu veux que je cites 100 jeux restes en beta qui sont sur ticalc ?

>Les bogues seraient-ils dus à genlib?
Hum.
Quels bogues ?

> genlib a eu longtemps une réputation d'être boguée, donc ça ne m'étonnerait pas.
Eh bon ? Je n'en jamais entendu parler. C'est la premiere fois.
Des bugs occasionnels il est vrai.

>Si, c'est possible. N'oublie pas qu'on est sur un système sans MMU, donc rien ne m'empêche
> de trouver et de traffiquer ta sauvegarde des vecteurs et/ou de EV_hook.
C'est impossible a cause de la specification qui l'interdit.

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

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

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

>Ce n'est pas une blague. Les programmes TICT sont vraiment codés de manière très propre.
Moins que tu ne le penses.

>J'ai déjà assez de patches à GCC à maintenir comme ça.
Les patches de pragma ne sont pas si dur


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

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

>En effet, maintenant, ton idée devrait être implémentable. Mais maintenant, le support des DLLs y est déjà.
Rien n'empeche de les virer et de faire avec mon idee.

>Et alors? Je m'en fiche si c'est dans la table des sauts.
>Tant que c'est dans la ROM et que ce n'est pas dur à trouver, je ne vois pas le problème.
Tu ne vois pas le probleme ? Je parle de la coherence de l'API avec elle meme, et tu ne
vois pas le probleme ?

>D'autant plus que c'est exporté depuis AMS 2.00, et que donc le hack est sûr à 100%
>(parce qu'il n'y aura pas de nouvelles versions 1.0x).
Qui te dis qu'une nouvelle version d'AMS n'exportera pas moins de fonctions ?

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

>Oui, mais c'est plus compliqué et plus lent.
C'est plus simple
Plus lent, cela reste a voir.

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

>Mais franchement, fprintf(stdout ou fprintf(stderr (l'utilisation la plus courante de std*)
>n'apporte pas grand chose en fonctionnalité par rapport à un simple printf(.
Juste une compatibilite ANSI

>Ça ne devrait pas changer quoi que ce soit. As-tu comparé les 2 fichiers pour voir ce qui a changé?
Je voulais le faire. Mais je ne l'ai pas fait. Tout ce que je sais c'est que ca marche bien avec les chaines
de caracteres (les chaines de caracteres de SMA sont parfaitement transmissibles via graphlink, d'ou je
subodorre ticonnect - surcouche de graphlink).

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

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

>Peu importe quand il arrive, on fait quoi quand il arrive?
>Les EXTRA_RAM_CALLs sont totalement inadaptés à la situation.
Elles sont prevus pour 2 machines, c'est vrai. Et alors ? Au moins elles sont modifiables
facilement.

>Non! Si le nombre d'entrées des EXTRA_RAM_CALLs change en fonction des flags mis,
>ça sera l'horreur à gérer dans le linker!
LOL. Tu sais que tu es un grand comique toi.
if (flag_big_extraram)
WriteNewExtraRam();
else WriteOldExtraRam();

>Les versions récentes de TIGCC IDE recherchent automatiquement dans tous les fichiers de ton projet.
Je suis bete. Je n'utilise aucun IDE.

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

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

>Ta routine n'est même pas clippée.
Extgraph non plus

>Et si on a besoin d'allouer plus de 65520 octets en tout?
Question floue (Choisie la reponse ):
1. C'est impossible. De toute facon, c'est pour des allocs rapides, donc en generale pas tres grosses.
2. On alloue deux handles et on les relie entre eux a l'iniailisation. La taille totale geree est donc 2*64Ko - qqs octets.

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

>>Heu... Je prefererais que ca soit moi. sebastian@tigcc.ticalc.org nan ?
>Oui.
Encore oublie

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

>Patience, il n'a pas que ça à faire.
Les corrections etaient pretes a l'emploie

>Non, surtout pas. C'est déjà assez chaotique comme ça.
ah !

>Mais je ne vois pas du tout l'intérêt d'exporter les fontes du boot et pas celles utilisées par AMS (qui ne sont pas
>nécessairement celles dans AMS lui-même d'ailleurs, cf. Font Installer Demo), sauf pour _RAM_CALL_00E à cause
>des equates débiles utilisant les offsets du boot.
Parce que c'est comme ca depuis le debut, et la compatibilite m'y obblige

>C'est un seul appel de fonction, donc c'est une ligne.
En C tu peux faire d'un programme une seule ligne

>Tu as toujours une excuse...
Tu as vu le nombre de projets sur lequel je bosse ?

>Vu la manière de laquelle tu "expliques" ça dans la documentation, ça m'étonnerait.
Expliques donc toi maintenant que tu as compris !

>Ben, si on est démesurés, il ne faut pas s'attendre à que ce soit rapide.
Pourquoi ? C'est encore plus fun

>Parce qu'on tourne autour des 10 FPS en 3D. Alors qu'on en est généralement loin en 2D.
Sur quelle machine tu parles la ? Excuse moi je suis perdu.

>Mais elle compresse mieux! (Mes tests l'ont montré.)
Statitiquement, a peine.

>Mais si.
Mais non.

>Ben, évidemment que si on met plein d'effets spéciaux, c'est lent.
>Mais on n'a pas besoin d'une tonne d'effets spéciaux pour qu'un jeu soit jouable.
Y'a aucun effet special dans Ultima 8. Ca rame quand meme

>XDanger, tu ne peux pas nous rajouter des fonctions clippées? Tout le monde râle à cause de ça.
Ca m'arrangerait moi aussi

>Un jeu n'a pas du tout besoin de fonctionner par plans.
C'est vrai.

>Il est beaucoup plus simple de travailler avec le scrolling de ExtGraph.
TOTALEMENT FAUX !

>Pour un shell, AMS suffit.
C'est vrai.

>C'est ça le problème.
Ou la solution

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

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

>C'est totalement stupide et égocentrique comme position.
N'est-ce pas stupide et egocentrique de les laisser dans l'ignorance.
Qu'ils le fassent par choix et tout a fait respectable !
Qu'ils le fassent par ignorance, non.

>Aucun de ces jeux n'a vraiment de difficultés à atteindre les 10 FPS.
parce qu'ils utilisent des libraries vraiment rapides !

>Les seuls jeux TI-89/92+/V200 où la vitesse est un vrai problème que j'ai rencontrés
>jusqu'à présent étaient des jeux 3D.
Cf a des scenes 3D. Et ca rame pas trop

>Non, c'est très utile. Ça rend mes TSRs autonomes. D'ailleurs, même PpHd linke h220xTSR statiquement dans PreOs.
Je pense que ca arrange pas mal de mondes. Mais je peux l'enlever aussi
Vous voulez ?

>Je n'évite pas du tout le sujet. C'est toi qui ne me comprends pas. Il peut économiser de la place avec ExePack,
>en utilisant ttstart. La différence est qu'il n'est pas obligé d'économiser de la place.
Et pourquoi choisirait -t-il de perdre de la place a fonctionnalites identiques ?

>S'il trouve les lanceurs personnalisés plus pratiques, il a le droit de les utiliser.
Mais s'il ne connait aucune autre solution ?

>Alors qu'avec ta méthode, il est obligé d'utiliser le lanceur unique (PreOs + shrnklib, ce sont 2 fichiers d'ailleurs,
>et leur taille totale est 3 fois celle de ttstart).
Si c'est juste 3x, c'est bon.

>Je ne dis pas qu'elle est plus rapide, je dis qu'elle est:
>- plus flexible
>- plus facile à utiliser
Non ! Il faut quand meme utiliser tigcclib pour inialiser les grays et autres trucs du genre !

>- plus petite, surtout grâce au système de librairies statiques qui ne linke que les fonctions réellement utilisées
Probablement.
Mais c'est surtout car il manque des fonctions

>- probablement plus stable
Plus c'est petit, plus c'est facile a debogguer.

>- suffisamment rapide pour pratiquement toutes les utilisations pratiques
Qui sont ? Des jeux de reflexions ?

>Le format _nostub est le format d'exécutables natif de AMS. Le format kernel utilise un format émulé.
Une surcouche.

>Une comparaison vague est de comparer le mode kernel à Cygwin et le mode _nostub à MinGW.
>Mais il y a des différences. Cygwin est nettement plus utile que les kernels sur TI-89/92+/V200,
>et son format d'exécutables n'est pas aussi non-natif que celui des kernels sur TI-89/92+/V200.
Non-natifs. Qui s'executent quand meme bien sur la plateforme.

>Le format kernel est vraiment totalement non-natif. Il n'utilise même pas la table de relogements
>prévue par AMS, mais laisse cette table vide et en met une autre en un autre format.
Parce que le format de la table d'AMS est pourri !

A quand KII?

TiMad> va falloir que l'on parle de XLib

pkoi?

> Parce que le format de la table d'AMS est pourri !
Mais c'est le format natif standard qu'il faudrait respecter... 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...

Uther Lightbringer
a écrit : C'est bien ce que je voulais dire. Emuler le format kernel doit être plus lourd que de l'utiliser simplement

D'où mon conseil de laisser tomber genlib et d'utiliser une librairie graphique statique.

>Non, c'est très utile. Ça rend mes TSRs autonomes. D'ailleurs, même PpHd linke h220xTSR statiquement dans PreOs.
Dans Preos c'est une très bonne idée car ca permet de l'utiliser une fois et un seule et on est tranquille

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

Je le comprends très bien. on a juste un point de vue différent, pour un fois je pense plus a assister le débutant que toi c'est tout.

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.

Encore un qui crois en ce mythe que les libs statiques feraient gagner de la place. La taille du programme nostub augmente et finit par dépacer la taille du prog kernel+lib si des fonction sont réutilisées dans plusieurs programmes.

... 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).

Oui mais preos contient HW2TSR et plein de chose supplémentaire qui font que 5ko s'est vraiment négligable. Pour s'en passer en nostub, il faudrait plein de TSR qui au final finiraient par consommer autant de place.

Je te signale que ttstart (et donc aussi les lanceurs personnalisés) n'a besoin d'aucun TSR pour fonctionner! 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.

-plus flexible: certes mais rien ne t'empeche d'utiliser d'autre lib en supplément des fonction que tu trouverait trop restrictives de plus elle convient sans problèmes à la plus grande majorité des jeux

Mais ça prend encore plus de place! genlib en prend déjà trop toute seule!

-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.

Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib. 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.

-probablement plus stable : affirmation gratuite sans aucun fondement -> poubelle

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.

-suffisament rapide pour pratiquement toutes les utilisations pratiques: certes mais genlib l'est encore plus.

Mais ça ne sert à rien.

Je suis d'accord avec toi c'est plus logique de laisser les DLL au code , mais si ca arrange le programmeur de faire comme cela, je vois pas ce qu'il y a de vraiment gennant vu que de toute facon les LIB ne peuvent pas etre édité ou executé(en tout cas c'est plus propre qu'un ASM ou EXPR) Vouloir contraindre le programmeur est totalement stupide et égocentrique comme position.

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.

>Une DLL contient normalement des tas de fonctions que le programme n'utilise pas forcément, donc le fichier à remplacer n'est pas vraiment de petite taille. c'est une DLL mal concue alors

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.

Tout a fait d'accord mais bzip2 sous Windows c'est pas le pied.

Quel est le problème?
http://sources.redhat.com/bzip2/ - Il y a des binaires pour beaucoup de plateformes, et Windows en fait évidemment partie.
http://jrfonseca.dyndns.org/projects/gnu-win32/software/untbz2/index.html - un décompresseur de .tar.bz2 pour Windows en 23 KO seulement

sBibi
a écrit : tiens au fait, a propos de stripper lee executables, il y a bien strip sous unix qui vire tous les commentaires du compilateur, mais l'equivalent sous windows c'est quoi?

strip.exe de MinGW. Ou alors tu passes -s à MinGW GCC.

sBibi a écrit :
heu et puis:

"- compilation avec les mauvais flags (optimisation en vitesse plutôt qu'en taille). Il faut compiler en -Os."
depuis quand "il FAUT" ?

Il faut si on veut réduire au minimum la taille du téléchargement.

en lisant ca on dirait que ceux qui compilent avec -O3 font une erreur... dans ce cas pourquoi ne pas simplement supprimer le flag -O3 hein? si il est inutile et si c'est mal de l'utiliser....

Déjà ce n'est pas moi qui décide des flags qui sont dans GCC. Et ensuite, ce flag sert si on veut optimiser en vitesse. Mais on n'optimise pas en vitesse si on veut optimiser le temps de téléchargement (et/ou l'espace pris sur le disque dur).

nimporte quoi ton raisonnement... bcp de monde se contrefout de la taille finale, surtout sur pc (bon ok c'est chiant a downloader) et prefere nettement la vitesse d'execution...

Je sais, mais je n'en fais pas partie en tout cas. TIGCC est compilé entièrement en -Os (la version Windows comme la version Linux).

squale92
a écrit : oué, mais il me semble qu'on ne peut avoiur d'une seule Dll par programme, non ?

Oui, et c'est fait exprès pour:
- 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)
- 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!)

Certes, ils sont prévus pr l'usage d l'interpréteur... cela dit, utiles pr le codeur C ?
il me semble qu'on ne peut pas définir de menu custom à partir du C qui reste valide depuis le TIOS ensuite...
(du moins, c ce qu'on m'avait répondu voila bien longtemps, qd j'avais posé la question) alors, l'utilité pr le codeur C.......

Il y a certainement un moyen de le faire. Si c'est possible en BASIC, c'est aussi possible en C.

> (parlant de vcbprintf)
>Et elle est très facile à trouver sous n'importe quelle version de AMS

Je croyais qu'il ne fallait pas se fier sur des "hacks" de ce style...
ceux proposés par PpHd marchent aussi sous n'importe quelle version d'AMS... et pourtant, tu n'en veux pas...
il fo te rappeler ce que tu dis à PpHd : n'importe quelle version d'AMS EXISTANTE
(erf... je cherche pas à être méchant, et tu vas surement trouver un moyen de me contrer ça... mais ça me titillait )

Quels "hacks proposés par 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.

je me trompe peut-être, mais il me semble qu'il est possible de rediriger stderr, stdout et stdin vers (ou depuis) des fichiers, alors qu'on ne peut pas avec printf ? (pas sûr qu'on puisse pas avec printf, remarque...)

On peut avec printf sur PC. Pas avec TIGCCLIB évidemment.

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

Le problème est justement là, pas là où vous le cherchez (compatibilité binaire imparfaite).

je croyais qu'il fallait attendre au moins 2006 avant un nouveau modèle de machine...
Et qui sait ce qu'on sera et ce qu'on fera en 2006

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

ça dépend de combien de fois 10 secondes, et de 10 secondes tous les combiens de temps

Ben, le contexte, c'était:

>>>>>>>Mais alors là pas du tout. Avec un fichier de données de type personnalisé, tu obtiens rapidement un pointeur sur les données (avec les ROM_CALLs de vat.h - ça prend 4 lignes de C avec les vérifications de non-nullité), et tu peux faire tout le reste avec des x(an). Si tu n'arrives pas à te rappeller des offsets, utilise des equates. Tu as aussi besoin d'equates pour les "libs read-only" de toute façon.
>>>>>>2. Ca s'eneleve tout seul lorsque tu n'importes plus rien.
>>>>>Ça arrive si souvent qu'on arrête d'utiliser un fichier de données où on l'utilisait à un moment? Dans les rares cas où ça arrive, est-il vraiment si dur de retirer 4 lignes ou de les mettre sous #if 0 (ou ifne 0)???
>>>>Ca arrive. Et dans ce cas, il faut rechercher l'importation du fichier de donnees dans le code source.
>>>[Ctrl]+[F]SymFindPtr[ENTER]
>>Et dans plusieurs fichiers ? Non, je ne dis pas que ca soit difficile. C'est plus long c'est tout.
>On n'est pas à 10 secondes près quand on programme.
ça dépend de combien de fois 10 secondes, et de 10 secondes tous les combiens de temps

La situation dont on parle n'arrive vraiment pas souvent. Il est même improbable qu'elle arrive même une fois.

ma foi, puisque le biutmapput d'AMS n'est pas clippé, je ne vois pas l'utilité de le clipper dans pedrom, qui est destiné à faire tourner des progs fonctionnant sous ams (sauf pr la mémoire, pr l'instant)...
(heu... enfin... en supposant que celui d'ams n'est pas clippé... sinon, si ça l'est dans ams, il serait bon que ça le soit dans pedrom )

BitmapPut de AMS est clippé! À ton avis, il sert à quoi, le paramètre SCR_RECT *clip?

BitmapPut puts a bitmap BitMap (which was taken using BitmapGet) on the screen at position (x, y), using the attribute Attr. The drawn bitmap will be clipped at the boundaries of the area given by parameter clip. See SetCurClip for more info about clipping areas.

on alloue une deuxième bloc (solution bourrin...)

genalib gère-t'elle ça de manière transparente?

squale92
a écrit : que tu empoie le terme "Dll", ça veut tout de suite dire "Windows", dans la tête de celui qui entend...

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, par extension, le "mising dll... réinstaller l'application peut corriger le pb" (ou qqc dans ce stuyle)

Ben, à part:
- réinstaller l'application
- récupérer la DLL quelque part
je ne vois pas d'autres solutions pour résoudre ce problème.

Ben, qd PpHd a mis 2 mois pr corriger le pb que tu lui avait reporté dans SMA, tu as gueulé... PpHd lui aussi a pas que ça à foutre, je suppose !
Qd c'est ppHd qui fait attendre les autres, tu gueules, et qd c'est TN qui les ait attendre, c'est "patience, il a pas que ça à faire" ?
(je m'emporte )

PpHd a mis bien plus de 2 mois pour corriger le problème, et puis c'était une seule instruction d'assembleur à rajouter.

bof, mis à part les instructions préprocesseur, tu peux mettre tout ton prorgramme en une seule ligne... c'est un des immenses avantages du C/C++ : tu n'a pas besoin de perdre plein de mémoire en faisant des fichiers énormes à cause des caractères de retour à la ligne

. Mais un appel de fonction est quand-même une ligne logique.

je ne cherche pas à ce que ce soit "rapide", mais à ce que ça ne ralentisse pas beaucoup !
(parce que "rapide", codé en C, sur un CPU à 10MHz (j'ai une HW1), en plein écran (j'ai une 92+), avec tout ce qu'il y a à gérer, je pense que ce soit possible, du moins vu ce que j'appelle "rapidité" ! Mon but est donc que ça ne rame pas, ou que ça ne rame qu'un strict minimum... (en considérant que ça rame en dessous des 100 fps

Tu mets un 0 de trop!

(je dois en être à 20 en moyenne, maximum, et ça peut descendre à 5 avec 120 missiles du joueur à l'écran plus 10/15 de l'ennemi; plus le boss, plus l'arrière plan)

Ben, évidemment, si tu abuses des sprites pour remplir l'écran entier, il est normal que ce soit lent.

c aussi grave plus lent

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

et les fonctions de scrolling de Extgraph forcent tout l'écran à scroller à la même vitesse, dans la même direction... ce qui ne peut être pour un jeu d'action... (du moins, pas pour K, ni KII)

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. Si tu fais la même chose, le scrolling différentiel devient trivial.
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):

ScrollLeft(fond1);
ScrollLeft(fond1);
ScrollLeft(fond1);
ScrollLeft(fond2);
ScrollLeft(fond2);
ScrollLeft(fond3);
FastCopyScreen(fond3,LCD_MEM);
Sprite8X_OR(0,0,128,fond2,30,LCD_MEM);
Sprite8X_OR(0,0,128,fond1,30,LCD_MEM);

et voilà, un scrolling différentiel.

>Pour un shell, AMS suffit si tu veux le faire en grays, non

1. Quel intérêt d'utiliser des niveaux de gris pour un shell?
2. TIGCCLIB suffit pour les niveaux de gris.

si tu veux faire une compression à la ziplib (compatible ziplib), non, à moins recoder ziplib en statique

Ça n'a aucun rapport avec l'affichage. J'aurais apparemment dû être plus précis:
"Pour un shell, AMS suffit pour l'affichage."
mais je pensais que c'était clair d'après le contexte.

Et puis, de toute façon, la compression de ziplib est très mauvaise par rapport à celle de ttpack.

>Ça ne t'empêche pas de la mettre en statique. J'utilise h220xTSR dans "presque tous mes programmes" et je le linke quand-même statiquement et après, tu te plaint que ta calc ait la mémoire pleine...

Ce n'est vraiment pas ça qui remplit la mémoire de mes calculatrices (je rappelle que j'ai une TI-89 et une TI-92+). Ça ne remplit même pas 2% de ma mémoire archive (2% de 655360 = 13107 octets, une copie de h220xTSR ne fait que 1,5 KO, et je n'en ai pas 8 copies). Ce qui remplit vraiment ma mémoire archive, ce sont de gros programmes comme AS et CC (que je vais d'ailleurs supprimer parce que je ne les utilise jamais ) ou comme les livres d'ouverture de TI-Chess.

>La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub c'est d'ailleurs bien dommage...

Pourquoi dommage? C'est très bien! Et ce n'est que l'évolution normale. Ce n'est pas étonnant du tout qu'on arrête de programmer pour les formats dépassés.

Krypton, que tu cite, à parfois un peu de mal (encore que... peut-être pas qd même pr 10 fps )...

Ben, c'est ce que je dis (la partie "encore que... peut-être pas qd même pr 10 fps").

mais je dois reconnaitre que je n'ai que des algos merdiques

En plus.

KII, qui propose bcp plus de choses, tourne parfois à moins de 10 fps dans les moments ritiques...

Ben, vu la manière de laquelle tu abuse d'effets spéciaux (scrolling différentiel, écran rempli de sprites, ...), ça ne m'étonne pas.

mais il y a des algos que je pense pouvoir optimiser (parce que là, j'utilise des trucs un peu barabarres et pas malins)

En plus.

Pour l'effet graphique

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. Et de toute façon, ces effets graphiques ne changent rien à la jouabilité.

>Mais c'est vrai qu'avec 96 missiles, ça fait beaucoup...
>Il pourrait en mettre le quart (24) et ça suffirait
moué... mais on verrait plus que c une super-arme, vu le nombre de missiles que les autres armes "normales" sont capables de générer (qd on a toutes les armes, il doit y avoir plus de 25 missiles à l'écran simultanément, j'estime... rien qu'avec le drone (8 missiles), les doubles tris avant, les tirs sur les côtés, le lance-fusées, le laser... et qui retirent en général une, deux, voire trois fois avant que les premiers missiles soient sortis de l'écran...)

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.

merci de ton soutient
Je me permet de rajouter que KII, c'est pour me faire plaisir en codant, d'une, et pr m'éclater en y jouant (enfin, vu le peu de niveau qu'il y a, je m'éclate pas vraiment...) ; et les effets visuels me servent bien pr ça

Je ne vois pas ce que les effets visuels apportent pour la jouabilité.

Les murs animés, ils ne sont que pour ça, d'ailleurs, pr les effets visuels ; des murs non animés (qui sont plus nombreux que ceux animés, je le précise) auraient suffit... mais un peu de mouvement au milieu fait de l'animation )
Le scrolling d'arrière plan, pareil, il ne sert qu'à faire joli...
J'ai une arme qui tire des missiles en hélice (elle tire en haut, puis en haut à droite, puis à droite, puis en bas à droite, etc... avec un délai entre chaque tir => ça dessine une hélice )... Elle est pas particulièrement utile : le drone tire lui aussi dans en gros toutes les direction, et retire dans chaque direction plus vite que l'hélice (qui doit faire une rotation compléte)... mais l'effet visuel de l'hélice est clairement plus joli !)

Je me répète un peu, mais je confirme: tu abuses d'effets graphiques!

>N'oublie pas que PreOs prend plus de 5 KO en archive et plus de 3 KO en RAM je considére que ça ne fait que très peu de "sacrifice" de mémoire à faire par rapport à tous les avantages apportés...

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

sauf pour les jeux demandant bcp de puissance...

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!

Qd tu cherche à optimiser tes algos pr gagner quelques millisecondes à donner à d'autres trucs que tu veux rajouter, c pas pr qu'une librairie d'affichage graphique te bouffe un temps fou !

Quand tu es à la milliseconde près dans un jeu 2D, c'est qu'il y a un problème quelque part (trop d'effets spéciaux par exemple, mais je me répète un peu ).

clair que qd tu passe à allegro et que tu réussi à l'utiser, c pas grace à l'exemple de extgraph

Ça montre qu'Allegro est compliqué, pas que genlib est simple.

>Oui mais preos contient HW2TSR et plein de chose supplémentaire qui font que 5ko s'est vraiment négligable. Pour s'en passer en nostub, il faudrait plein de TSR qui au final finiraient par consommer autant de place ... voire plus

Il faudra m'expliquer de quels TSRs vous parlez! Parce qu'un programme _nostub n'a normalement besoin d'aucun TSR pour tourner!

de toute façon, il n'y a que TRES PEU de gens parmis les utilisateurs des programmes qui sauront si la Dll contient des donnée ou du code (du moins, si tu ne le dis pas ouvertement )
dans KII, je n'utilise pas de Dll, mais je met des fonctions (donc, du code ) dans un de mes fichiers externe qui est conçu pr contenir des données...

Beurk! J'espère que tu as pensé à la protection des HW2!

cela dit, si je ne le dis pas, personne ne le sait... (d'autant plus que le tout est compressé )

>D'où mon conseil de laisser tomber genlib et d'utiliser une librairie graphique statique.
Désolé mais genlib me convient très bien.

>>Dans Preos c'est une très bonne idée car ca permet de l'utiliser une fois et un seule et on est tranquille
>Je ne vois pas pourquoi, selon toi, ça serait une bonne idée pour PreOs et pas pour mes TSRs à moi.
Vu que en général preos est installé dès le redémmarge le patch est appliqué et c'est réglé jusqu'au prochain reset. Mais bon je comprends que pour quelqu'un qui refuse le kernel c'est embetant.

>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.
Je comprends très bien, mais je ne vois pas vraiment pourquoi vouloir multiplier les lanceur alors que le kernel permet de regler ce problème(et bien plus) en une fois.
Certes je laisse pas le choix mais on a rien a y perdre vu que de toute façon, les programmes concerné sont au format kernel.

>... 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).
Tes calculs ne sont pas significatif : tout dépends de se qu'on a sur la calculatrice. Dans un cas général, je dirais que ca ne change pas grand chose que ce soit dans un sens ou dans l'autre.

>Je te signale que ttstart (et donc aussi les lanceurs personnalisés) n'a besoin d'aucun TSR pour fonctionner! 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.
C'est pire : c'est un fichier sur la calculatice qui en plus doit etre multiplié par le nombre de programes si on veut pouvoir les lancer du style "prog()"

>Mais ça prend encore plus de place! genlib en prend déjà trop toute seule!
Si tu prend genlib c'est que tu fait on jeu conséquent et que tu utilisera la pluspart des fonctions de genlib, donc sa taille est justifiée. Bien sur genlib n'est pas faite pour un backgammon. Si tu utilise un lib statique en plus, ca sera certainement pas pour plus d'une ou 2 fonctions d'ou peu de place perdue

>Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib. 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.
L'inverse est aussi vrai. Met toi bien dans le crane que Genlib n'est pas plus compliquée que Extragraph ou TIGCCLIB. TIGCCLIB en plus d'etre lente n'est pas pratique a mon gout. Ceci dit je n'ai jamais dit qu'elle marchait mal

>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.
Certes il y a eu des bogues mais rien ne te permet d'affirmer qu'il en reste. Ca m'étonnerai que ExtraGraph n'ai jamais eu de bogue

>Mais ça ne sert à rien.
Pour toi(j'en ai marre de me répeter)

>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.
Certes mais quoi qu'il en soit ca ne change pas grand chose

>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.
Non mais on peut essayer de trouver un bon compromis entre les 2

>Quel est le problème?
http://sources.redhat.com/bzip2/ - Il y a des binaires pour beaucoup de plateformes, et Windows en fait évidemment partie.
http://jrfonseca.dyndns.org/projects/gnu-win32/software/untbz2/index.html - un décompresseur de .tar.bz2 pour Windows en 23 KO seulement
C'est pas la pas la peine: ca fait un petit moment que je l'utilise mais ce n'est malheureusement pas le cas de la majorité des utilisateurs Windows.

Uther Lightbringer a écrit :
>>Mais franchement, fprintf(stdout ou fprintf(stderr (l'utilisation la plus courante de std*) n'apporte pas grand chose en fonctionnalité par rapport à un simple printf(
>je me trompe peut-être, mais il me semble qu'il est possible de rediriger stderr, stdout et stdin vers (ou depuis) des fichiers, alors qu'on ne peut pas avec printf ?
(pas sûr qu'on puisse pas avec printf, remarque...) les flux c'est très pratique sur PC

Ben, l'intérêt est assez limité quand-même. Un printf simple marche tout aussi bien. Et puis, l'affichage en stderr est lourd sous DOS/Windows, parce qu'il ne peut pas être facilement redirigé (DOS ne comprend que >, pas 2>), contrairement à l'affichage en stdout utilisé par les fonctions comme printf.

mais sur calculette je vois mal t'interet.

On est d'accord, pour une fois.

>oué, mais il me semble qu'on ne peut avoir d'une seule Dll par programme, non ? Bien sur Kevin le repete assez les DLL n'ont pas étés ajoutés pour une utilisation normale en lib dynamique mais pour contourner le problème de la limite a 64Ko.

Exact,

Si tu veux utiliser de vraies lib dynamiques, le mode kernel est vraiment prévu pour.

Je dirais plutôt: si tu veux faire des librairies pour réutiliser du code entre plusieurs projets, les librairies statiques sont vraiment prévues pour.

> Imagine un écran 128×128, et une matrice clavier qui n'a rien à voir avec celle de la TI-89 ni avec celle des TI-92+/V200 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é.

Et s'il y a un changement de resolution de l'écran ca m'étonnerais que ce soit pour une résolution inférieure.

160×100 -> 16000 pixels
128×128 -> 16384 pixels
Ce ne serait pas une résolution inférieure par rapport à la TI-89.

Par contre je ne vois vraiment pas comment le nostub pourait s'en sortir.

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.

> (en parlant du BitMapPut de pedrom) Ta routine n'est même pas clippée Le but est d'avoir un fonctionnement très proche de celui d'AMS ce n'est donc vraiment pas grave

La routine de AMS est clippée!

> Ce n'est pas parce que cette abbréviation est utilisée par Windows qu'on ne peut l'utiliser pour rien d'autre Certes mais DLL n'est utilisée que sous Windows alors quand on de ce nom a un système de lib dynamique il faut s'attendre a ce type de comparaison

Et c'est tout à fait normal qu'on compare, vu que c'est exactement le même concept.

>>Les autres auront beaucoup plus de chances de l'utiliser si tu la mets en statique. La plupart des programmeurs TI-89/92+/V200 encore actifs ne programment qu'en _nostub
>c'est d'ailleurs bien dommage... C'est bien vrai mais un jeu comme krypton gagnerai a etre en kernel tu ne le fais pas c'est dommage

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

squale92 a écrit :
> Bien sur Kevin le repete assez les DLL n'ont pas étés ajoutés pour une utilisation normale en lib dynamique mais pour contourner le problème de la limite a 64Ko. Si tu veux utiliser de vraies lib dynamiques, le mode kernel est vraiment prévu pour
pr ce qui est du kernel, je suis d'accord.
pr les dll... ma foi... c dommage

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.

>C'est bien vrai mais un jeu comme krypton gagnerai a etre en kernel tu ne le fais pas c'est dommage qu'est-ce que j'y gagnerai ?

Strictement rien.
Reste en _nostub, c'est mieux.

Hmmmmm Kevin, au niveau jeu puissant, tu n'es ni l'offre ni la demande, comment te permets-tu de juger? Que tu dises 'tu abuses des effets spéciaux' n'a aucun sens! Dis seulement que c'est ton opinion.

Space Invaders et R-Type n'ont quand même pas le même attrait... Il en va de même de ton Mario à 1 fps (que tu dis jouable, m'enfin s'il faut 10mn pour traverser l'écran, je doute) et SMA par exemple.

Laisse les programmeurs programmer comme ils l'entendent (et ça n'est pas valable que pour ces histoires d'effets graphiques), et les utilisateurs utiliser ce qu'ils veulent!