Kernel vs Nostub? - Page 13

>Les accès aux attributs d'applications sont aussi très lent
Je sais. Mais ils sont bien plus rapides qu'une recherche sur une bonne partie de la Flash (et même si on ne recherche que sur le boot, les fonctions d'AMS appropriées sont bien plus rapides)...
> Marche pas sur AMS 1.0x
Bien sûr. Je ne l'ai pas mentionné, car trouver les adresses des fonts, c'est trivial sous AMS 1.xx. Surtout pour un programmeur comme toi, ça prend quelques minutes à faire, en désassemblant DrawStr. Si tu n'as pas le temps, regarde le source de TI-Chess 4.00, les routines sont dedans.

> J'ai propose de rajouter d'autres RAM_CALL.
Nous aussi.

> Ils manquent quand meme plein de trucs.
A TIGCC, ou à TIFS ('il manque', ou 'ils manquent') ?

Tigcc.

>Pourquoi le faire signer par TI ? Pas besoin [/cite]
Tu est sérieux? Si tu arrivais a faire ca ca serait vraiment énorme!

>>>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
>>Je vois pas en quoi ca peut etre plus propre et mieux definis.
>En tout cas, la spec du standard de commentaires _nostub est probablement plus claire et mieux définie que les super specs de certains trucs du kernel (au hasard, les RAM_CALLs de fonts)...
Je ne comprend pas un mot de vos arguments, les commentaires sont très bien définis et je ne vois vraiment pas au est le problème de RAM_CALLS de font

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

>Tu est sérieux? Si tu arrivais a faire ca ca serait vraiment énorme!
Faut pas rêver... Et puis de toute façon, ça sera dans PedROM...

> les commentaires sont très bien définis
Le format de commentaires kernel ? Je ne suis vraiment pas un expert de ce sujet, mais je ne pense pas qu'il soit aussi bien défini que le format de commentaires _nostub. D'autre part: ce format de commentaires kernel, résulte-t-il d'une consultation publique (comme cela a été fait pour le format de commentaires _nostub), ou est-ce un "standard" défini par quelques programmeurs et par l'usage ?

>je ne vois vraiment pas au est le problème de RAM_CALLS de font
Ils ne reflètent pas ce que peut faire l'utilisateur sur AMS 2.xx (redéfinir les fonts)... Pour faire un truc propre et rapide (nettement plus que la méthode actuelle),on fait une recherche dans la system frame (AMS 2.xx), on prend des offsets absolus dans DrawStr (AMS 1.xx).

> Tigcc.
Peut-être, mais TIGCCLIB est la plus complète existante pour TI-68k, et de llin. La lib de TIFS est faible/inexistante/fausse sur de nombreux points.
Et tu peux participer à la documentation des fonctions d'AMS (je sais que tu le fais, donc je ne te reproche pas de ne pas le faire).

mais optimiser en vitesse une routine de recherche de fonte c une pure perte de temps !
en taille je ne dis pas, mais en vitesse

c'est clair ...

Ouh, je vais pas me faire ch*** à réexpliquer encore une fois pour des personnes qui sont malcomprenantes, tiens.
C'est pas la vitesse, le plus gros problème !

/me repond au post 272

Kevin Kofler a écrit :
Tu utilises quoi alors? Notepad???
TIGCC IDE est très pratique, même si tu programmes en assembleur!

TIGCC IDE est le pire des IDE que la terre est pu porter !
Il extiste des 10zaine d'IDE bcp plus souple, leger, et utilisable ! (Un bon exemple, mais pas pour la "légéreté" : Jext)


Un truc a propos de ses stupide comparaison avec le DOS, si on veux vraiment comparer avec le DOS, le nostub = appli dos standard, un prog kernel = Appli DOS avec un DosExtender!


PS: g pris mon courage a deux mains pour lire les 13 pages ! sa finissait par etre un peu lourd...

Sinon mon chti point de vus, je croit que je vais adopter le kernel pour tt se qui est programe "normale" mais pour certain program spécifique demandant de toucher directemetn a la TI, le nostub prime.

TIGCC IDE est le pire des IDE que la terre est pu porter ! Il extiste des 10zaine d'IDE bcp plus souple, leger, et utilisable ! (Un bon exemple, mais pas pour la "légéreté" : Jext)

Je ne comprend pas vraiment pourquoi la TIGCC s'embète a faire une IDE(même sous Linux) alors qu'il existe plein d'éditeurs qui au déja fait leur preuves. Ceci dit tu y va un peu fort TIGCC IDE n'est pas mauvais, mais il y a mieux!

Un truc a propos de ses stupide comparaison avec le DOS, si on veux vraiment comparer avec le DOS, le nostub = appli dos standard, un prog kernel = Appli DOS avec un DosExtender!

Oui c'est très bien résumé.

PS: g pris mon courage a deux mains pour lire les 13 pages ! sa finissait par etre un peu lourd...

Je te félicite mais penses a PpHd et Kevin les pauvres qui en plus de lire ont tout écrit!

C'esdt clair, je me suis plus ou moins battut une fois avec macintock a coup de long posts comme sa, c assé epuisant !

Allé courage PpHd et KK, ya encore matiere a oeuvrer, rien que sur se que g dit ;D

bah, je pense que ce topic a encore de longues pages devant lui avant de mourrir

ConText + batch power ... pis au moins ca bug pas et c pas lourd

beuh, moi g context et pourtant j'utilise l'ide

bah tu gagnerais du tps avec ConText ...

XDanger a écrit :
Ouh, je vais pas me faire ch*** à réexpliquer encore une fois pour des personnes qui sont malcomprenantes, tiens. C'est pas la vitesse, le plus gros problème !

ben je sais pas moi, je ne passe pas mon temps à lire ce topic, je suis tombé sur ton post c tout

XDanger a écrit :
Pour faire un truc propre et rapide (nettement plus que la méthode actuelle)

y'av de quoi se tromper.
apres si c g pas compris dsl. mais c pas la peine de commencer à me traiter de personne malcomprenante..

XDanger
a écrit : Ouh, je vais pas me faire ch*** à réexpliquer encore une fois pour des personnes qui sont malcomprenantes, tiens.

Toi, tu n'as rien compris à l'essence même de ce topic.

ConText + batch power ... pis au moins ca bug pas et c pas lourd

Tu ments.
Non sérieusement context est bien sympa mais j'ai malheureusement constaté que les prog java que je lançais avec buggaient, alors qu'il étaient tout a fait normaux lancés a la ligne de commande!

Bon, je vais essayer de rattrapper mon retard...

squale92 a écrit :
oué.
Perso, j'ai stdlib entière sur ma calc, même si elle contient des libs que je n'utilise pas, et qu'aucun prog que j'ai n'utilise. Mais, ainsi, je sais que, quelque soit le prog que je met sur ma machine, il est quasi-certain qu'il fonctionne (et du moins, je ne risque pas de voir un msg du style "missing lib")

Il est vraiment dommage qu'on en soit arrivé là! Le problème "missing libs" est tellement grand qu'on en est arrivé avec PreOs à vouloir copier toutes les librairies dynamiques sur toutes les calculatrices. (Et encore, il existe au moins une douzaine de librairies dynamiques exotiques qui ne sont pas dans stdlib.) Il y a au moins une demi-douzaine des librairies de stdlib qui ont de bonnes chances d'être totalement inutilisées sur la plupart des calculatrices. Si ce n'est pas un gaspillage de place énorme, c'est quoi??? Et pourtant, la vraie solution au problème serait tellement simple: le linkage statique!

et pr des appels de fonctions imbriqués, tu fait comment ?
une ligne dans une autre ? par exemple : f1(f2(a), f3(5+6)*f4(d));

C'est une ligne ça.

Voila, j'ai d'un côté Kevin qui me dit qu'il ne faut pas tout réafficher à chaque cycle... de l'autre côté, PpHd qui me dit le contraire
Si je n'avais pas envie de me fatiguer à tester, devinez, en fonction des programmes que chacun a sorti, lequel j'aurai tendance à croire...
Et vu que je ne suis pas paresseux à ce point, j'ai testé la technique de PpHd (à l'origine, je redessinnai pas tout à chaque cycle... ct encore plus barbarre, je pense), ... et c'est celle que j'ai adopté ne serait-ce que question de rapidité... et de simplicité

Mais, moi, j'ai des arguments. Avec la méthode de PpHd, tu affiches tout l'écran à chaque frame. Avec la mienne, tu scrolles (ce qui va plus vite que de tout réafficher, il y a beaucoup moins de calculs à faire) et tu affiches une seule rangée de sprites.

arf, oué, possible
cela dit, vu que je n'ai jamais utilisé genlib
tout ce que je connais de genlib, c la doc (que j'ai lu plusieurs fois, il y a de ça déjà quelques temps), et ce que je lis sur le forum (et ce que tu as dis aux open )

Moi non plus, je n'ai jamais utilisé genlib. Surtout parce qu'elle est en mode kernel.

c vrai qu'en voyant CF ou SMA, on se dit qu'il faut absolument réserver la TI aux jeux sans graphisme, avec 3 lettres qui bougent à l'écran, parce que la machine est pas asez puissante pour faire tourner quelque chose de plus évolué à une vitesse jouable (lol)

LOL, je ne te conseille pas de faire tes jeux en ASCII art! Ce que je te conseille, c'est juste de ne pas abuser de graphismes. C'est très différent.
Et donne-moi un exemple de jeu rapide qui ne plante pas et qui ne remplit pas la mémoire archive entière, pas CF ou SMA.

PreOS a une autre fonctionnalité par rapport à kerNO

Fonctionnalité qui serait inutile si vous arrêtiez enfin de programmer en le format dépassé (kernel). Donc économie de place (comme déjà dit, KerNO est nettement plus petit, et de plus le _nostub marche aussi très bien sans KerNO).

c tellement moche, sinon... et puis, c plus marrant de chercher à gagner quelques millissecondes partout où on peut pour les ré-attribuer à la gestion des graphismes que de faire quelque chose de moche, mais sur lequel on n'a pas cherché !

Un usage raisonnable des graphismes ne veut pas nécessairement dire que c'est moche. Il est beaucoup plus intéressant de chercher à faire quelque chose de beau avec peu d'effets spéciaux.

Ah, ben, pour gagner un utilisateur, peut-être que je ferai une version kernel (cf la liste des versions possibles, un peu plus bas dans ce post)

Ne perds pas ton temps à contenter les extrémistes. La version _nostub marche très bien sur les calculatrices avec kernel (alors que l'inverse n'est pas vrai!), donc je ne vois aucun intérêt de faire une version kernel. Si PpHd veut boycotter le _nostub, c'est son problème. Peut-être même que ton jeu le fera changer d'avis.

ma fois, s'il 'en sont encore à DoorsOS, c normal

Et puis, vu que ticalc a jamais fait de pub à preOS... alors qu'il en fait à doorsos (cf non de la partie kernel pr les progs !)...

Bon sang, encore un qui n'a pas compris que le nom de la partie correspond au kernel qui a inventé le format, pas au kernel qui est actuellement le moins pire. Et pourtant, je l'ai déjà expliqué plein de fois sur ce forum.

Remarque, je n'ai pas le souvenir que ticalc ait fait de la pub à Pphd (du moins, pas pour CF, déjà)

Il y a plusieurs raisons de ne pas faire de news sur CF:
* CF n'est qu'une bêta.
* C'est une bêta instable et bourrée de bogues.
* Elle est en mode kernel.
* Elle remplit la mémoire archive entière.

certes
Et puis, on a qd même une machine bien puissante le tout est d'utiliser cette puissance de façon optimale (en continuant d'optimiser mes algos, par exemple)

Ça reste quand-même un 68k à 10 ou 12 MHz, pas un Athlon à 2 GHz. Il faut s'adapter à cette situation.

heu... ça effacera les librairies qui ne sont pas "certifiées" ?
Qu'est-ce que tu entend par là ?
(que ça efface des libs dont des versions plus récentes sont dans stdlib, ok... mais que tu effaces des libs utiles à d'autres programmes (telles tbolib pour TBO de FlashZ, ou autres), c pas glop )

C'est exactement la même attitude que celle de TI. Et pourtant les pro-kernel gueulent toujours sur TI à cause de ça...

En fait, je me demande si je devrai pas sortir mes progs en 4, voire 5 versions :
nostub, non compressé
nostub, compressé avec ppg
kernel, non compressé
kernel, compressé avec ppg
kernel, compressé en pack archive
(actuellement, pour K, j'ai les deux premiers )

Les 2 premiers, ça suffit. Ceux qui ont un kernel peuvent très bien utiliser des programmes _nostub (tout comme ceux qui n'en ont pas), donc je ne vois aucune raison valable de faire une version kernel. Et personnellement, je trouve que le deuxième seul suffit. Quel intérêt de faire une version non compressée?
Et puis, même si tu fais une version kernel, pourquoi pas laisser tomber le pack archive? Le PPG prend moins de place.

Le tout dans un même Zip...

Et bravo pour avoir multiplié la taille du téléchargement par 5.
C'est un gaspillage de place et de temps de téléchargement. La version _nostub PPG marche très bien sur toutes les calculatrices, donc les autres sont inutiles.

Comme ça, chaque utilisateur prend ce qu'il prèfère... et avec un peu de chance, il restera une version, entre nostub et kernel, qui fonctionnera sur les prochaines ROM

Si c'est ça qui te fait peur, envoie tes sources à quelqu'un qui reste dans la communauté avant de "disparaître".
Ou alors, encore mieux: ne disparais pas entièrement. Tu peux arrêter d'écrire de nouveaux programmes, mais continuer quand-même la maintenance de ceux que tu as déjà sortis... C'est juste une question de recompilation normalement.

oué, enfin, c pareil pr moi : c une forme qui vole en 3D

Kevin Kofler a écrit :



Mais, moi, j'ai des arguments. Avec la méthode de PpHd, tu affiches tout l'écran à chaque frame. Avec la mienne, tu scrolles (ce qui va plus vite que de tout réafficher, il y a beaucoup moins de calculs à faire) et tu affiches une seule rangée de sprites.

franchement je ne pense pas qu'en pratique ce soit réellement plus rapide

Moi non plus, je n'ai jamais utilisé genlib. Surtout parce qu'elle est en mode kernel.

pourtant tu devrais, juste pour voir

LOL, je ne te conseille pas de faire tes jeux en ASCII art! Ce que je te conseille, c'est juste de ne pas abuser de graphismes. C'est très différent.
Et donne-moi un exemple de jeu rapide qui ne plante pas et qui ne remplit pas la mémoire archive entière, pas CF ou SMA.

Fernando

Bon sang, encore un qui n'a pas compris que le nom de la partie correspond au kernel qui a inventé le format, pas au kernel qui est actuellement le moins pire. Et pourtant, je l'ai déjà expliqué plein de fois sur ce forum.

Et on t'a déjà dit pourquoi on trouvait ça stupide. et 'moins pire', c'est pas top

Il y a plusieurs raisons de ne pas faire de news sur CF:
* CF n'est qu'une bêta.
* C'est une bêta instable et bourrée de bogues.
* Elle est en mode kernel.
* Elle remplit la mémoire archive entière.

N'empêche que c'est certainement le plus gros projet jamais releasé sur TI68k, et que quand on voit certaines news qu'ils ont déjà posté, on est en droit d'attendre que CF ait au moins le droit à être vaguement nommé

Et bravo pour avoir multiplié la taille du téléchargement par 5.
C'est un gaspillage de place et de temps de téléchargement. La version _nostub PPG marche très bien sur toutes les calculatrices, donc les autres sont inutiles.

Dans un programme nostub, les fonctions sont inclues non? dis-toi que c'est un zip nostub avec 5 fois les mêmes fonctions, ça passera mieux

Uther Lightbringer
a écrit : Je parlait bien évidement de Unix, Linux...

Ah, OK.

sous windows il y a presque autant d'interet que sur TI mais sous Linux, j'aurais du mal a m'en passer

Bof, on peut quand-même travailler avec printf seul.

Mon but n'est pas d'être systématiquement en désacord avec toi

>>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. c'est terible cette manie de ne pas répondre au question

Ça répond à la question. Ce que squale92 veut faire, c'est de partager du code entre plusieurs projets, donc je lui dis qu'il ne doit pas utiliser une "DLL _nostub" pour ça, mais une librairie statique.

>J'en doûte, si la matrice clavier et la résolution de l'écran ont complètement changé. dans tous les cas, on ne peut pas avoir plus de problèmes qu'en nostub

Mais pas moins de problèmes non plus. On a exactement les mêmes problèmes, et exactement la même solution (recompiler le programme - ça prend 5 minutes maximum), donc utiliser le format kernel à cause de ça ne sert à rien.
Et puis on peut avoir un problème supplémentaire avec le mode kernel: vous faites quoi si h220xTSR et HW2Patch ne fonctionnent plus à cause d'une mise à jour matérielle? Si enter_ghost_space ne marche pas, h220xTSR ne marchera pas non plus, mais l'inverse est loin d'être vrai. Donc le _nostub (qui dépend juste de enter_ghost_space) est plus portable.

certes mais il y gagnerai tous le avantage du kernel,

1. Quels avantages?
2. Il n'utilise aucune fonctionnalité du kernel, donc il n'y gagnera strictement rien.

et s'il avait été réalisé avec genlib il y aurait gagné en taille

1. Il n'a pas été réalisé avec genlib.
2. "Il y aurait gagné en taille" peut-être si tu ne comptes pas la taille du kernel ni celle de genlib, mais certainement pas si tu les comptes! J'ai vraiment marre de cette manière truquée de compter la taille. Ce n'est pas parce que vous (PpHd, toi, ...) cachez des octets dans des fichiers externes qu'il ne faut pas les compter!

Les DLL nostub sont un concept defectueux a plus forte raison: ce sont des libs dynamiques dont il ne faut pas ce servir comme des libs dynamique

Ce n'est pas un concept défectueux, c'est le seul moyen de faire un programme _nostub de plus de 64 KO, et c'est exactement pour ce but-là qu'il est prévu.

et qui sont apparues alors qu'il existe un concept de lib dynamique reconnu et qui a fait ces preuves sur TI.

Mais qui nécessite un kernel.

heureux de le savoir je vais recompiler ca en -O3 parceque même si la diférence est pas flagrante, sur mon ordi qui rame, c'est déja ca de gagné.

Bonne chance. Sur mon PIII 733 MHz, j'ai besoin d'une heure environ pour compiler GCC et Binutils. (C'est plus rapide sous Linux que sous Windows d'ailleurs.)

en asm la grog kernel est bien plus facile est tout aussi efficace

Elle n'est pas du tout "bien plus facile". Tu n'as pas l'air d'avoir lu ça.

N'empeche que la doc de PreOS est très bien réalisée.

Compare avec les documentations que j'ai écrites, moi. Celle-là par exemple: http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=161.topic. Dans la documentation de PreOs, il y a plein d'abbréviations, de phrases nominales etc. Dans les miennes, il y a des phrases complètes qui expliquent tout en détail.

pas pour le moment mais ca ne devrait plus trop tarder

Tu veux dire GTC, n'est-ce pas? Comme j'ai déjà dit, ses fonctionnalités ne sont pas tout à fait comparables.

disons que tout le monde n'a pas la même vision des fonctionnalités intérééssantes.

Pour moi, ce qui est le plus intéressant dans AMS, ce sont ces capabilités mathématiques.

c'est normal c'est l'antre du nostub

Non. Ici, c'est l'antre du kernel! Le reste du monde considère les kernels comme dépassés presque unanimément.

rien ne te prouve que ce soit du a genlib! c'est vraiment facile comme argument

Je constate juste la corrélation.
Et ce n'est pas du tout "facile comme argument". Ce qui est facile, c'est de traîter les arguments des autres de "faciles" sans aucune justification. En quoi est-ce un argument facile???

n'empeche que kernel::Exec est bien plus pratique

Pas du tout. Je compte exactement 9 instructions (dont seulement 6 différentes) dans mon code. Pour n'importe quel programmeur ayant le minimum d'expérience en assembleur, ça prend au maximum 1 minute d'écrire ça.

Ca serait déja ca, quoi qu'il arrive stderret stdout seraient affichée a l'écran sans posibilité de rediriger quoi que ce soit, certes ca ne sert a rien mais ca permet de faciliter le portage

Je compte regarder si je peux faire quelque chose pour le support des streams quand j'aurai fini de travailler sur les fonctions d'entrée sur console (*scanf, gets avec support du backspace, ...). Mais pas avant. Et je ne promets rien. Le problème est surtout que si on les implémente de la manière "évidente", on se retrouve avec par exemple fprintf qui rajoute en même temps printf, fgets qui rajoute en même temps gets, ... C'est lourd! Surtout: ça double la taille des programmes qui utilisent ces fonctions.

TIGCC IDE n'aporte rien que n'apporte une autre ide a part le lien automatique(dont on peut facilement ce passer) et de la génération automatique des entête que de toute facon, il faut souvent modifier .

Ça apporte aussi:
* la coloration syntaxique pour exactement les langages dont tu as besoin (C, A68k, GNU as 68k).
* la coloration des parenthèses: j'aime beaucoup la manière de laquelle TIGCC IDE colore les parenthèses. Les autres éditeurs que j'ai vus ne font pas ça aussi bien.
* la possibilité de tester ton fichier sur VTI ou sur une vraie calculatrice avec un seul clic.
* une interface simple à utiliser, pas alourdie par des fonctions qui ne servent que si on programme sur PC.
...

Il n'y a pas que notepad dans la vie, il existe une tonne d'étideurs de textes. Emacs est génial mais pour toi qui ne le suporte pas il y a aussi Context, UtraEdit...

Déjà ce sont des sharewares. TIGCC IDE est gratuit et sous GPL.
Et surtout TIGCC IDE est l'IDE qui est fait pour l'utilisation avec TIGCC. Utiliser un autre éditeur avec TIGCC est du bidouillage. Les fonctionnalités des autres éditeurs ne sont pas adaptées aussi bien à TIGCC.

Si ce n'est que lors d'un super tir qui peut arriver très rarement, ce n'est pas vraiment grave, ce n'est pas toi qui parlait d'un mario a 1Fps jouable?

Le problème, c'est que lui, il veut en même temps des super-tirs très lourds en graphismes et une vitesse de 100 fps (oui, il en veut 100, pas 10 ou 20, cf. messages précédents). Ne penses-tu pas qu'il y a une contradiction quelque part?

Le contexte c'est que j'utilise des RAM_CALL,

Tu utilises les RAM_CALLs directement?! Tu devrais utiliser les macros de compat.h! En mode kernel, elles sont automatiquement transformées en RAM_CALLs quand il y a un RAM_CALL correspondant. En _nostub, elles sont implémentées différemment.

des libs dynamique dont je n'ai pas l'intertion de me passer(a part filelib)

Pour genlib, tu as toujours le pseudo-_nostub (ce n'est pas du vrai _nostub, mais au moins tu n'as pas besoin de USE_KERNEL). Tu utilises quoi d'autre comme librairies dynamiques?

et que je veux que s'il y a une mise a jour, je ne soit pas forcement obligé de recompiler,

Tu n'es pas forcément obligé de recompiler! Juste s'il y a vraiment un problème. Pas mal de programmes _nostub n'ont jamais eu besoin d'être recompilés pour une mise à jour.
Et c'est quoi cette paresse? Ça ne prend même pas 5 minutes de recompiler ton programme!

et je veux utiliser kpack que je trouve plus pratique que ttpack.

Il est plus pratique comment???
Pour utiliser ExePack, il suffit de:
* cocher une case dans TIGCC IDE OU
* passer un paramètre à tigcc(.exe): -pack nomduppg OU
* utiliser ttppggen(.exe) qui fonctionne exactement comme kpack.exe.

Uther Lightbringer a écrit :
J'ai mis genlib me convient très bien et non te convient très bien

la différence est vraiment minime et en plus c'est décompressé plus vite donc ca ne change rien

La différence de taille n'est pas si minime que ça, et la différence de temps de décompression est minime. Donc ttpack est bien meilleur.

[contexte: comparaison de la taille utilisée par une librairie statique et celle utilisée par une librairie dynamique] il n'y a pas que genlib: il y a aussi graphlib, ziplib,...

* Quel intérêt d'utiliser graphlib? Pratiquement toutes ses fonctions sont déjà dans la ROM!
* Pour ziplib, elle compresse tellement mal que si on l'utilise, on gaspille automatiquement pas mal de place.

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

* Aucun de ces programmes n'est nécessaire pour faire fonctionner le _nostub! Si tu veux les fonctionnalités qu'ils apportent, mets-les, si tu préfères économiser la place, ne les mets pas. Tu n'as toujours pas l'air d'avoir compris, et je te demande donc: il y a quoi que tu n'as pas compris dans cette explication (que je répète déjà au moins pour la 3^ème fois)?
* Je ne vois pas ce que vient y faire XtraKeys. Ça n'a aucun rapport avec les fonctionnalités de PreOs.

Si tu programme un bon jeu, tu auras sans doute besoin d'une grande partie des fonctions.

Pas du tout. Un jeu peut très bien être un bon jeu sans utiliser la centaine d'effets graphiques qu'il y a dans genlib! Juste un exemple: TI-Chess.

T'as au maois lu la doc avec autant d'attention que celle d'extragraph avant de balancer cette affirmation gratuite?

Pour ExtGraph, on n'a même pas besoin de lire la documentation pour savoir comment elle marche. Et puis, si la documentation de genlib était écrite en angais compréhensible ou en français compréhensible, je l'aurais peut-être comprise plus facilement. Mais là, c'est du jargon illisible... La documentation est probablement le plus grand problème de genlib (mis à part le fait que c'est une librairie dynamique ).

le linkage statique pose d'autres inconvéniants!

Inconvénients absolument minimes. Surtout par rapport au grand nombre d'inconvénients des librairies dynamiques.

Uther Lightbringer
a écrit : Je connais pas mal de monde que un fichier tar.bz2 n'était pas une erreur mais un format de compression diférant de zip.

C'est pour ça que je l'explique toujours quand je mets des tar.bz2 en téléchargement.

Et cela fait très peu de temps que ce format est reconnu d'office par WinZip, beaucoup de gens ont encore des logiciel qui ne le gerent pas et ce n'est pas pret de s'arranger avec WindowsXP qui gère le zip en natif et donc risque de disuader de prendre un autre format.

Je ne vois pas le problème qu'il y a à télécharger un décompresseur de 23 KO. Ça prend moins de place que beaucoup de programmes pour calculatrice!

Un mario en Basic c'est un beau défi a réaliser, mais merci la jouabilité

erreur PreOS a plein
d'autres fonctionctionalités par rapport a _KerNO

Comment ça "plein d'autres fonctionnalités"? Il y a juste le support du format kernel (et c'est ça que le "NO" veut dire). Pas plus.
Renseigne-toi sur ce qu'est et fait KerNO avant d'en discuter s'il te plaît. Même chose pour les autres TSRs dont tu parles (XtraKeys par exemple, qui n'a rien à voir avec les fonctionnalités de PreOs).

oula! ce nom me fait peur, tu pourais expliquer davantage?

Tu as raison à en avoir peur.

vince a écrit :
Pourriez vous me définir le distingo NOSTUB // MiSTUB // KERNEL précisément et simplement.

D'avance merci
(Kernel et nostub, je sais faire la différence, c'est le terme "mi-stub" que je me figure mal)

Bon:
* Kernel et _nostub, c'est ce dont on parle depuis le début du topic.
* Ce terme de "mistub", c'est à mon avis n'importe quoi:
- PpHd l'utilise pour dire des programmes "hybrides" avec un stub kernel et avec 2 points d'entrée: un pour quand il n'y a pas de kernel et un pour quand il y en a un. Ça n'a aucun intérêt en pratique. (Le _nostub pur apporte exactement les mêmes fonctionnalités sans ce bidouillage bizarre.)
- Certains l'utilisent pour parler du pseudo-_nostub de genlib: une librairie d'importation statique qui reloge la librairie dynamique au format kernel. Ce n'est pas du _nostub (parce qu'il y a un stub dans genlib), mais le terme "mistub" ne convient pas non plus.

Je ne dirais qu'une chose

Ce topic ne sert que deux objectifs :
- Indiquer à ceux qui ne savaient pas exactement (comme moi) ce qu'est le mode kernel et ce qu'est le mode _nostub (au fait, pourquoi conserver le "_" devant lorsqu'on en parle de façon normale ? Je trouve que ça fait "bourge de la prog").
- Peut-être arriver à ce que TIGCC supporte mieux (sic) les programmes kernel.
En tous cas, c'est assez instrucitf (surtout qu'il y a deux opinions différentes, donc on peut choisir), sauf les posts de Ti-Mad... Je me demade s'il ne va pas passer en mode X (Ignorer) .

PpHd a écrit :
>Voila, j'ai d'un côté Kevin qui me dit qu'il ne faut pas tout réafficher à chaque cycle... de l'autre côté, PpHd qui me dit le contraire
Bon soyons honnete. Ca depend de ce que tu vas faire apres. Si le nombre de choses a l'ecran qui bougent est trop grand, oui, car le surcout du traitement va etre plus grand que la force brute pour tout reafficher.

Mais même si tu as peu à afficher, il y a quand-même moins de calculs (décalages de bits etc.) à faire qu'en réaffichant tout à chaque fois.

>Tu aurai pas envie d'essayer de proposer tes versions à TI ? Non.

Pas très coopératif. Mais je te comprends, je ne serais pas très content non plus de voir mes routines utilisées dans un concurrent commercial à mon propre projet.

>Et puis, vu que ticalc a jamais fait de pub à preOS... alors qu'il en fait à doorsos (cf non de la partie kernel pr les progs !)...
>Remarque, je n'ai pas le souvenir que ticalc ait fait de la pub à Pphd (du moins, pas pour CF, déjà)
Ben a part SMA, dont ils ont parle une fois, rien de rien. Pourtant j'en ai envoye des mails. Faut croire qu'ils me boycottent.

Ou tout simplement qu'ils ne retiennent pas tes programmes dignes de news. Ce qu'on trouve intéressant ou non est fortement subjectif. Et il y a des raisons de ne pas faire de news sur CF, du moins en l'état en lequel il est actuellement.

>heu... ça effacera les librairies qui ne sont pas "certifiées" ?
>Qu'est-ce que tu entend par là ?
>(que ça efface des libs dont des versions plus récentes sont dans stdlib, ok...
>mais que tu effaces des libs utiles à
>d'autres programmes (telles tbolib pour TBO de FlashZ, ou autres), c pas glop ) Ca sera. Mais y'aura un message d'avertissement.

Au moins...
Mais c'est quand-même assez autoritaire comme idée.

>En fait, je me demande si je devrai pas sortir mes progs en 4, voire 5 versions :
>nostub, non compressé
>nostub, compressé avec ppg
>kernel, non compressé
>kernel, compressé avec ppg
>kernel, compressé en pack archive
>(actuellement, pour K, j'ai les deux premiers )
>Le tout dans un même Zip...
Je te deconseille d'utiliser "kernel, compresse avec PPG".
Enfin, histoire d'alleger le zip

Pourquoi? La version actuelle de ExePack marche très bien avec des programmes en mode kernel. Et ttpack compresse mieux. C'est plutôt la version pack archive qu'il devrait laisser tomber.

>moi non plus! mais ce qui serait pratique un truc genre fichier de commande qui permette de compiler une version perso même pour quelqu'un qui ne comprend rien a l'assembleur Oué. Mais c'est pas si facile. Des idees ?

Ce n'est pas si dur que ça si tu présupposes une installation fonctionnelle de TIGCC.

>ttpack compresse mieux que les librairies utilisables pour les packs archive de PreOs. C'est surtout plus pratique.

Lequel est plus pratique? Le pack archive??? Pourquoi? ExePack est très pratique! (Cf. aussi la réponse à Uther Lightbringer, qui a fait la même remarque, un peu plus haut.)

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

Ce que disais était justement que ce support prend trop de place.

>oula! ce nom me fait peur, tu pourais expliquer davantage? Tout lib incertifiee (Version =0) se verra proposer d'etre effacee a l'installation.

Et tu as pensé au nombre de vieilles librairies qu'il y a avec une version 0? smqlib par exemple? Oui, c'est un abus des librairies dynamiques, mais elles y sont quand-même!

PpHd
a écrit : Mais je les ai compte, ces yes la.

Ah bon? Mais ça fausse quand-même le tableau de mettre tous ces "no".

C'est du vaporware, mon cher, cette techno la.

C'est du vaporware comment? La spécification est déjà publique depuis des semaines. Et elle sera officialisée demain.

Kerno est un kernel batard.

C'est un kernel pour les programmes _nostub. Il apporte les fonctionnalités des kernels sauf le format kernel. C'est peut-être "bâtard", mais quand-même utile pour certains.

crashlib ne marche pas si le programme n'est pas concu pour.

Tu fais un tableau des possibilités qu'un format offre aux programmeurs. crashlib est une possibilité proposée aux programmeurs _nostub, donc elle a bien sa place dans ton tableau.

La DLL est un truc batard.

Tu as l'air de bien aimer ce mot "bâtard".
Les DLLs _nostub ne sont pas du tout un truc bâtard. Ce sont des fichiers externes qui contiennent du code. Il n'y a rien de bâtard là-dedans. Un exemple de format vraiment bâtard est ton idée de "mistub".

Je comprends pas pkoi tu [XDanger] en fais une telle fixation sur ces ram_calls la.

Parce que c'est un hack qui ne tient pas en compte la redéfinition des fontes qui est possible sous AMS 2.

Bof, on peut quand-même travailler avec printf seul.

Certes mais quand j'ai des fonctionalité pratiques, j'aime bien m'en servir

>dans tous les cas, on ne peut pas avoir plus de problèmes qu'en nostub
Mais pas moins de problèmes non plus. On a exactement les mêmes problèmes, et exactement la même solution (recompiler le programme - ça prend 5 minutes maximum), donc utiliser le format kernel à cause de ça ne sert à rien. Et puis on peut avoir un problème supplémentaire avec le mode kernel: vous faites quoi si h220xTSR et HW2Patch ne fonctionnent plus à cause d'une mise à jour matérielle? Si enter_ghost_space ne marche pas, h220xTSR ne marchera pas non plus, mais l'inverse est loin d'être vrai. Donc le _nostub (qui dépend juste de enter_ghost_space) est plus portable.

Le kernel peut emuler des fonctions d'une calc a l'autre sous certaines conditions donc il y aura probablement moins de problème en Kernel(meme pour les progs Nostub) et puis s'il y a des problème de lib, il suffira de mettre a jour la lib en question(uniquement pour les progs kernels dans ce cas). Tous cela c'est des avantages par rapport au nostub. Bien sur dans les cas que tu as signalé, il est possible que ca ne marche pas, mais dans le pire des cas, le kernel sera aussi bien placé que le Nostub. Enfin cela m'étonnerait que TI face encore des changements matériels a ces calculatrices.
[/cite]1. Quels avantages?
2. Il n'utilise aucune fonctionnalité du kernel, donc il n'y gagnera strictement rien.
...
2. "Il y aurait gagné en taille" peut-être si tu ne comptes pas la taille du kernel ni celle de genlib, mais certainement pas si tu les comptes! J'ai vraiment marre de cette manière truquée de compter la taille. Ce n'est pas parce que vous (PpHd, toi, ...) cachez des octets dans des fichiers externes qu'il ne faut pas les compter!
[/cite]
Je voulais parler bien sur dans le cas ou il utiliserai le fonctionalité du kernel
Avec Genlib compté il aurait perdu un tout petit peu de place, mais si l'on ajoute ne serai ce qu'un autre jeu qui utilise genlib, on en gagne déjà.

> Les DLL nostub sont un concept defectueux a plus forte raison: ce sont des libs dynamiques dont il ne faut pas ce servir comme des libs dynamique Ce n'est pas un concept défectueux, c'est le seul moyen de faire un programme _nostub de plus de 64 KO, et c'est exactement pour ce but-là qu'il est prévu.

Mais cela n'empeche pas le concept d'etre mauvais.
Tu declares les kernel dépassé pour beaucoup moins que ca.

Bonne chance. Sur mon PIII 733 MHz, j'ai besoin d'une heure environ pour compiler GCC et Binutils. (C'est plus rapide sous Linux que sous Windows d'ailleurs.)

j'ai vu: j'ai laissé tomber

>en asm la prog kernel est bien plus facile est tout aussi efficace Elle n'est pas du tout "bien plus facile". Tu n'as pas l'air d'avoir lu ça.

Si si je le connais

>N'empeche que la doc de PreOS est très bien réalisée.
Compare avec les documentations que j'ai écrites, moi. Celle-là par exemple: http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=161.topic. Dans la documentation de PreOs, il y a plein d'abbréviations, de phrases nominales etc. Dans les miennes, il y a des phrases complètes qui expliquent tout en détail.

Je n'ai jamais dis que tu documentais mois bien que PpHd j'ai juste dis que ca doc était complète et compréhensible

>pas pour le moment mais ca ne devrait plus trop tarder Tu veux dire GTC, n'est-ce pas? Comme j'ai déjà dit, ses fonctionnalités ne sont pas tout à fait comparables.

Bien sur que non! si c'était encore plus comparable ca s'appellerai pas "GTC" mais "TIGCC clone" GTC devrait etre(s'il tient ces promesses) un compilateur au niveau

>disons que tout le monde n'a pas la même vision des fonctionnalités intérééssantes. Pour moi, ce qui est le plus intéressant dans AMS, ce sont ces capabilités mathématiques.

Bien sur et si tu aime te servir de la calculatrice pour les Math rien ne t'oblige d'utiliser Pedrom. Mais que si tu n'a plus aucune utilité de faire des mathématiques avancées, on peut etre intéréssé

Je constate juste la corrélation. Et ce n'est pas du tout "facile comme argument". Ce qui est facile, c'est de traîter les arguments des autres de "faciles" sans aucune justification. En quoi est-ce un argument facile???

Dire qu'une lib est responsable quand un programme bugge sans pouvoir le justifier c'est facile. De plus, les programmes qui utilisent genlib sont souvent bien plus complexes que la majorité des programmes qui utilisent extragraph il sont donc plus difficiles a débogger.

Pas du tout. Je compte exactement 9 instructions (dont seulement 6 différentes) dans mon code. Pour n'importe quel programmeur ayant le minimum d'expérience en assembleur, ça prend au maximum 1 minute d'écrire ça.

Oui mais quand on ne connais pas tout a l'assembleur notament les problèmes de protections, c'est infiniment plus facile un kernel::exec[/cite]

Ça apporte aussi:
* la coloration syntaxique pour exactement les langages dont tu as besoin (C, A68k, GNU as 68k).
* la coloration des parenthèses: j'aime beaucoup la manière de laquelle TIGCC IDE colore les parenthèses. Les autres éditeurs que j'ai vus ne font pas ça aussi bien.
* la possibilité de tester ton fichier sur VTI ou sur une vraie calculatrice avec un seul clic. * une interface simple à utiliser, pas alourdie par des fonctions qui ne servent que si on programme sur PC.

la coloration y est aussi sur tout bon éditeur et on peut en plus la personaliser sur certains(Context permet pas exemple de redéfinir le mots clés...).
La coloration des parenthèses se fait, dans la pluspart des autres éditeurs, quand le curseur est dessus ce qui rend le tout moins chargé(mais la c'est vrai que c'est une question de gout).
L'interface a beau etre alégée est est plus lente et moins complète que la pluspart des autres IDE.
La possiblité de tester en un clic reste c'est vrai un avantage mais dont on apprend très vite a ce passer
de plus, je passe sur le nombre de fonctions(plus ou moins utiles) dont disposent les editeur de texte comme Emacs ou UltraEdit

> Il n'y a pas que notepad dans la vie, il existe une tonne d'étideurs de textes. Emacs est génial mais pour toi qui ne le suporte pas il y a aussi Context, UtraEdit...
Déjà ce sont des sharewares. TIGCC IDE est gratuit et sous GPL. Et surtout TIGCC IDE est l'IDE qui est fait pour l'utilisation avec TIGCC. Utiliser un autre éditeur avec TIGCC est du bidouillage. Les fonctionnalités des autres éditeurs ne sont pas adaptées aussi bien à TIGCC.

Emacs un shareware . Context est freeware et il en existe plein d'autres en freeware. Seul UltraEdit est shareware.
Pour ce qui est de l'IDE, GCC n'a pas été concu pour une IDE spécifique et tant mieux alors il n'y a pas de raison qu'une IDE soit imposée avec TIGCC.

Le problème, c'est que lui, il veut en même temps des super-tirs très lourds en graphismes et une vitesse de 100 fps (oui, il en veut 100, pas 10 ou 20, cf. messages précédents). Ne penses-tu pas qu'il y a une contradiction quelque part?

Il a le droit de réver non? Il essaye de faire du mieux qu'il peut pour s'en approcher, c'est tout a fait normal.

Tu utilises les RAM_CALLs directement?! Tu devrais utiliser les macros de compat.h! En mode kernel, elles sont automatiquement transformées en RAM_CALLs quand il y a un RAM_CALL correspondant. En _nostub, elles sont implémentées différemment.

Le fichier kernel.h s'occupe de tout ca . Ceci dit je préfère un RAM_CALL que des pseudos-constantes .

>et je veux utiliser kpack que je trouve plus pratique que ttpack.
Il est plus pratique comment???
Pour utiliser ExePack, il suffit de:
* cocher une case dans TIGCC IDE OU
* passer un paramètre à tigcc(.exe): -pack nomduppg OU * utiliser ttppggen(.exe) qui fonctionne exactement comme kpack.exe.

Je le trouve plus pratique a l'utilisation et non a la création. Je sais tu vas me dire c'est pas pratique parce qu'il faut un kernel mais pour moi c'est secondaire.

* Quel intérêt d'utiliser graphlib? Pratiquement toutes ses fonctions sont déjà dans la ROM! * Pour ziplib, elle compresse tellement mal que si on l'utilise, on gaspille automatiquement pas mal de place.

*graphlib est bien plus rapide que les ROMCALLs et permet les 8 niveaux de gris
*ziplib, meme si elle n'est pas aussi efficace que les compresseur PC, peut tout de meme faire gagner de la place sur de long fichiers texte par exemple. Donc pourquoi s'en priver.

>Si tu programme un bon jeu, tu auras sans doute besoin d'une grande partie des fonctions. Pas du tout. Un jeu peut très bien être un bon jeu sans utiliser la centaine d'effets graphiques qu'il y a dans genlib! Juste un exemple: TI-Chess.

Je crois te l'avoir déja expliqué 70 fois genlib n'est pas pour TI-Chess, je ne sais pas si c'est le cas mais les BitmapPut suffisent amplement pour ce genre de jeu Le seul truc complexe(mais c'est vrai très complexe) dans TI-Chess, c'est l'IA mais la aucune lib statique ou dynamique ne pourra t'aider.

Je ne vois pas le problème qu'il y a à télécharger un décompresseur de 23 KO. Ça prend moins de place que beaucoup de programmes pour calculatrice!

Et après tu dis que ca pose problème d'installer un kernel sur ca calculatrice

* Aucun de ces programmes n'est nécessaire pour faire fonctionner le _nostub! Si tu veux les fonctionnalités qu'ils apportent, mets-les, si tu préfères économiser la place, ne les mets pas. Tu n'as toujours pas l'air d'avoir compris, et je te demande donc: il y a quoi que tu n'as pas compris dans cette explication (que je répète déjà au moins pour la 3ème fois)? * Je ne vois pas ce que vient y faire XtraKeys. Ça n'a aucun rapport avec les fonctionnalités de PreOs.

Disons que ExtraKey permet de remplacer de Shift+ON Mais c'est vrai que ce n'est pas son usage principal. et moi qui aime bien avoir un anti-crash, pouvoir installer des TSR, pouvoir passer sans me poser de question les 8/24Ko de limite et lancer des fichier sans lancher, j'ai tout ca dans PreOS alors qu'il me faut 3 prog équivalents en Nostub sans compter l'avantage de pouvoir utiliser des prog au format kernel.

T'as au maois lu la doc avec autant d'attention que celle d'extragraph avant de balancer cette affirmation gratuite? Pour ExtGraph, on n'a même pas besoin de lire la documentation pour savoir comment elle marche. Et puis, si la documentation de genlib était écrite en angais compréhensible ou en français compréhensible, je l'aurais peut-être comprise plus facilement. Mais là, c'est du jargon illisible... La documentation est probablement le plus grand problème de genlib (mis à part le fait que c'est une librairie dynamique ).

Si tu connais pas le nom de tes fonction je vois mal comment tu peux les utiliser(a la limite en utilisant le .h) Et puis quand j'utilise une lib lire la doc me parait un minimum.

>>Et puis, vu que ticalc a jamais fait de pub à preOS... alors qu'il en fait à doorsos (cf non de la partie kernel pr les progs !)...
>>Remarque, je n'ai pas le souvenir que ticalc ait fait de la pub à Pphd (du moins, pas pour CF, déjà)
>Ben a part SMA, dont ils ont parle une fois, rien de rien.
Pourtant j'en ai envoye des mails. Faut croire qu'ils me boycottent.
Ou tout simplement qu'ils ne retiennent pas tes programmes dignes de news. Ce qu'on trouve intéressant ou non est fortement subjectif. Et il y a des raisons de ne pas faire de news sur CF, du moins en l'état en lequel il est actuellement.

Par rapport a la moyenne de progs qui ont eu droit a des news CF et tous les projets de PpHd étaient largement au dessus

>>moi non plus! mais ce qui serait pratique un truc genre fichier de commande qui permette de compiler une version perso même pour quelqu'un qui ne comprend rien a l'assembleur
>Oué. Mais c'est pas si facile. Des idees ? Ce n'est pas si dur que ça si tu présupposes une installation fonctionnelle de TIGCC.

oui le seul véritable problème est qu'il faut tigcc installé

Je ne vais pas répondre à tout là (il y a encore plein de messages précédents auxquels je compte répondre), mais arrête de te f**tre de ma gueule! Je sais bien que Emacs est libre (GPL) et gratuit. Mais tu as dit:

Emacs est génial mais pour toi qui ne le suporte pas il y a aussi Context, UtraEdit...

Ma réponse se rapportait à ConTEXT et UltraEdit, pas à Emacs!!!

Context n'est pas un shareware et il existe bien d'autres éditeur freeware ou Libres

Kevin Kofler a écrit :
Il est vraiment dommage qu'on en soit arrivé là! Le problème "missing libs" est tellement grand qu'on en est arrivé avec PreOs à vouloir copier toutes les librairies dynamiques sur toutes les calculatrices. (Et encore, il existe au moins une douzaine de librairies dynamiques exotiques qui ne sont pas dans stdlib.) Il y a au moins une demi-douzaine des librairies de stdlib qui ont de bonnes chances d'être totalement inutilisées sur la plupart des calculatrices. Si ce n'est pas un gaspillage de place énorme, c'est quoi??? Et pourtant, la vraie solution au problème serait tellement simple: le linkage statique!

Mais je n'empeche personne de se faire des collections de libs persos.
Perso je ne mets pas tout sur ma calc.

Mais, moi, j'ai des arguments. Avec la méthode de PpHd, tu affiches tout l'écran à chaque frame. Avec la mienne, tu scrolles (ce qui va plus vite que de tout réafficher, il y a beaucoup moins de calculs à faire) et tu affiches une seule rangée de sprites.

Faux. Cf plus loin.

Moi non plus, je n'ai jamais utilisé genlib. Surtout parce qu'elle est en mode kernel.

Mais tu aurais pu faire un effort.

LOL, je ne te conseille pas de faire tes jeux en ASCII art! Ce que je te conseille, c'est juste de ne pas abuser de graphismes. C'est très différent.
Et donne-moi un exemple de jeu rapide qui ne plante pas et qui ne remplit pas la mémoire archive entière, pas CF ou SMA.

Fer3c

Fonctionnalité qui serait inutile si vous arrêtiez enfin de programmer en le format dépassé (kernel). Donc économie de place (comme déjà dit, KerNO est nettement plus petit, et de plus le _nostub marche aussi très bien sans KerNO).

Sauf que la place est rattrapee rien que pour cc.

Un usage raisonnable des graphismes ne veut pas nécessairement dire que c'est moche. Il est beaucoup plus intéressant de chercher à faire quelque chose de beau avec peu d'effets spéciaux.

Oui. Mais utiliser beaucoup d'effets est aussi interressant.

Ne perds pas ton temps à contenter les extrémistes. La version _nostub marche très bien sur les calculatrices avec kernel (alors que l'inverse n'est pas vrai!), donc je ne vois aucun intérêt de faire une version kernel. Si PpHd veut boycotter le _nostub, c'est son problème. Peut-être même que ton jeu le fera changer d'avis.

Non, pas sur la mienne.

Bon sang, encore un qui n'a pas compris que le nom de la partie correspond au kernel qui a inventé le format, pas au kernel qui est actuellement le moins pire. Et pourtant, je l'ai déjà expliqué plein de fois sur ce forum.

C'est une concertation entre PlusShell et DoorsOs, donc les 2 devraient figurer.

Il y a plusieurs raisons de ne pas faire de news sur CF:
* CF n'est qu'une bêta.
* C'est une bêta instable et bourrée de bogues.
* Elle est en mode kernel.
* Elle remplit la mémoire archive entière.

1. Ticalc a deja fait des news sur beaucoup de beta.
2. instable: Faux. C'est stable. Ya des bogues, mais c'est stable.
3. Peut etre...
4. Et ?

Ça reste quand-même un 68k à 10 ou 12 MHz, pas un Athlon à 2 GHz. Il faut s'adapter à cette situation.

Oui. Mais 96 missiles ne necessitent pas un Athlon a 2 Ghz.

C'est exactement la même attitude que celle de TI. Et pourtant les pro-kernel gueulent toujours sur TI à cause de ça...

Ben je voudrais qu'ils mettent a jour leur lib. Faut que je les pousse.

Les 2 premiers, ça suffit. Ceux qui ont un kernel peuvent très bien utiliser des programmes _nostub (tout comme ceux qui n'en ont pas), donc je ne vois aucune raison valable de faire une version kernel. Et personnellement, je trouve que le deuxième seul suffit. Quel intérêt de faire une version non compressée?
Et puis, même si tu fais une version kernel, pourquoi pas laisser tomber le pack archive? Le PPG prend moins de place.

Mais le PPG n'est pas concu pour fonctionner en kernel. Le Pack Archive, oui.

Et bravo pour avoir multiplié la taille du téléchargement par 5.
C'est un gaspillage de place et de temps de téléchargement. La version _nostub PPG marche très bien sur toutes les calculatrices, donc les autres sont inutiles.

Pas forcement. Avec un bon utilitaire de compression, cela ne multiplira que par 2.

Si c'est ça qui te fait peur, envoie tes sources à quelqu'un qui reste dans la communauté avant de "disparaître".
Ou alors, encore mieux: ne disparais pas entièrement. Tu peux arrêter d'écrire de nouveaux programmes, mais continuer quand-même la maintenance de ceux que tu as déjà sortis... C'est juste une question de recompilation normalement.

Normalement.
[/cite]

Kevin Kofler a écrit :
Ça répond à la question. Ce que squale92 veut faire, c'est de partager du code entre plusieurs projets, donc je lui dis qu'il ne doit pas utiliser une "DLL _nostub" pour ça, mais une librairie statique.

Une lib dynamique kernel est aussi parfaitement adaptee.

Mais pas moins de problèmes non plus. On a exactement les mêmes problèmes, et exactement la même solution (recompiler le programme - ça prend 5 minutes maximum), donc utiliser le format kernel à cause de ça ne sert à rien.
Et puis on peut avoir un problème supplémentaire avec le mode kernel: vous faites quoi si h220xTSR et HW2Patch ne fonctionnent plus à cause d'une mise à jour matérielle? Si enter_ghost_space ne marche pas, h220xTSR ne marchera pas non plus, mais l'inverse est loin d'être vrai. Donc le _nostub (qui dépend juste de enter_ghost_space) est plus portable.

Faux. On pourra toujours faire un lanceur kernel.

1. Quels avantages?
2. Il n'utilise aucune fonctionnalité du kernel, donc il n'y gagnera strictement rien.

De la place dans son executable.

1. Il n'a pas été réalisé avec genlib.
2. "Il y aurait gagné en taille" peut-être si tu ne comptes pas la taille du kernel ni celle de genlib, mais certainement pas si tu les comptes! J'ai vraiment marre de cette manière truquée de compter la taille. Ce n'est pas parce que vous (PpHd, toi, ...) cachez des octets dans des fichiers externes qu'il ne faut pas les compter!

Mais on ne les compte qu'une fois parmi tous nos projets.

Ce n'est pas un concept défectueux, c'est le seul moyen de faire un programme _nostub de plus de 64 KO, et c'est exactement pour ce but-là qu'il est prévu.

Et c'est pkoi le terme DLL est inapte !

Mais qui nécessite un kernel.

Et alors ? Ca marche bien mieux !

Elle n'est pas du tout "bien plus facile". Tu n'as pas l'air d'avoir lu ça.

je l'ai lu, et c'est bien plus simple en kernel.

Compare avec les documentations que j'ai écrites, moi. Celle-là par exemple: http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=161.topic. Dans la documentation de PreOs, il y a plein d'abbréviations, de phrases nominales etc. Dans les miennes, il y a des phrases complètes qui expliquent tout en détail.

Ok, tu critiques mon niveau d'anglais Desole

Tu veux dire GTC, n'est-ce pas? Comme j'ai déjà dit, ses fonctionnalités ne sont pas tout à fait comparables.

Oui. Mais taille GTC << taille GCC

Pour moi, ce qui est le plus intéressant dans AMS, ce sont ces capabilités mathématiques.

Ton point de vue est interressant.

Non. Ici, c'est l'antre du kernel! Le reste du monde considère les kernels comme dépassés presque unanimément.

t'exageres. Il y a toi par exemple.

Je constate juste la corrélation.
Et ce n'est pas du tout "facile comme argument". Ce qui est facile, c'est de traîter les arguments des autres de "faciles" sans aucune justification. En quoi est-ce un argument facile???

Il ne coute pas chez a dire.

Pas du tout. Je compte exactement 9 instructions (dont seulement 6 différentes) dans mon code. Pour n'importe quel programmeur ayant le minimum d'expérience en assembleur, ça prend au maximum 1 minute d'écrire ça.

Il supporte aussi les Pack Archives en une passe au lieu de 2.

Je compte regarder si je peux faire quelque chose pour le support des streams quand j'aurai fini de travailler sur les fonctions d'entrée sur console (*scanf, gets avec support du backspace, ...). Mais pas avant. Et je ne promets rien. Le problème est surtout que si on les implémente de la manière "évidente", on se retrouve avec par exemple fprintf qui rajoute en même temps printf, fgets qui rajoute en même temps gets, ... C'est lourd! Surtout: ça double la taille des programmes qui utilisent ces fonctions.

On veut surtout de la portabilite, pas de la taille lorsqu'on utilise ces fonctions la.

Ça apporte aussi:
* la coloration syntaxique pour exactement les langages dont tu as besoin (C, A68k, GNU as 68k).
* la coloration des parenthèses: j'aime beaucoup la manière de laquelle TIGCC IDE colore les parenthèses. Les autres éditeurs que j'ai vus ne font pas ça aussi bien.
* la possibilité de tester ton fichier sur VTI ou sur une vraie calculatrice avec un seul clic.
* une interface simple à utiliser, pas alourdie par des fonctions qui ne servent que si on programme sur PC.
...

1. Tous les autres le font.
2. Les autres ont des reconnaisances automatiques de paires.
3. Ca sert a rien et ca marche pas sur PedroM
4. C'est lourd.

Déjà ce sont des sharewares. TIGCC IDE est gratuit et sous GPL.
Et surtout TIGCC IDE est l'IDE qui est fait pour l'utilisation avec TIGCC. Utiliser un autre éditeur avec TIGCC est du bidouillage. Les fonctionnalités des autres éditeurs ne sont pas adaptées aussi bien à TIGCC.

Ben je trouve UEdit bien plus simple d'emploi que Tigcc IDE.
Et c'est pas de la bidouille.

Le problème, c'est que lui, il veut en même temps des super-tirs très lourds en graphismes et une vitesse de 100 fps (oui, il en veut 100, pas 10 ou 20, cf. messages précédents). Ne penses-tu pas qu'il y a une contradiction quelque part?

Si.

Tu utilises les RAM_CALLs directement?! Tu devrais utiliser les macros de compat.h! En mode kernel, elles sont automatiquement transformées en RAM_CALLs quand il y a un RAM_CALL correspondant. En _nostub, elles sont implémentées différemment.

Et en ASM ? Et les ram_calls non supportees en _nostub ?

Il est plus pratique comment???
Pour utiliser ExePack, il suffit de:
* cocher une case dans TIGCC IDE OU
* passer un paramètre à tigcc(.exe): -pack nomduppg OU
* utiliser ttppggen(.exe) qui fonctionne exactement comme kpack.exe.

Oncalc. Et plus flexible.

Kevin Kofler a écrit :
La différence de taille n'est pas si minime que ça, et la différence de temps de décompression est minime. Donc ttpack est bien meilleur.

Ben alors je vais creer une lib dynamique ttpacklib

* Quel intérêt d'utiliser graphlib? Pratiquement toutes ses fonctions sont déjà dans la ROM!

Plus rapide.

* Pour ziplib, elle compresse tellement mal que si on l'utilise, on gaspille automatiquement pas mal de place.

t'exageres.

* Aucun de ces programmes n'est nécessaire pour faire fonctionner le _nostub! Si tu veux les fonctionnalités qu'ils apportent, mets-les, si tu préfères économiser la place, ne les mets pas. Tu n'as toujours pas l'air d'avoir compris, et je te demande donc: il y a quoi que tu n'as pas compris dans cette explication (que je répète déjà au moins pour la 3^ème fois)?

Et si on veut les utiliser, pourquoi ne pas offrir des programmes optimises pour ?

* Je ne vois pas ce que vient y faire XtraKeys. Ça n'a aucun rapport avec les fonctionnalités de PreOs.

SHIFT+ON je pense.

Pas du tout. Un jeu peut très bien être un bon jeu sans utiliser la centaine d'effets graphiques qu'il y a dans genlib! Juste un exemple: TI-Chess.

C'est un jeu d'echec !

Pour ExtGraph, on n'a même pas besoin de lire la documentation pour savoir comment elle marche. Et puis, si la documentation de genlib était écrite en angais compréhensible ou en français compréhensible, je l'aurais peut-être comprise plus facilement. Mais là, c'est du jargon illisible... La documentation est probablement le plus grand problème de genlib (mis à part le fait que c'est une librairie dynamique ).

Desole. Encore une nouvelle critique de mon anglais. Sniff.

Inconvénients absolument minimes. Surtout par rapport au grand nombre d'inconvénients des librairies dynamiques.

Qui sont ?
Probleme de mise a jour : aucun probleme.
Gaspillage de place pour les fonctions supposees inutilisees : faux.