300

Déja prends le fichier flash vs nostub vs Kernel dans la doc de preos qui explique simplement ce que l'on peut et que l'on ne peut pas faire avec chacun des types de programmation, si ce n'est les notes a la fin que l'on ne peut pas vraiment considérer comme représentatives a mon avis.
Pphd pourra t'expliquer tout ce que permet le kernel et de manière très complète vu que c'est lui qui développe le seul kernel encore mis a jour.
avatar

301

Son fichier texte est tout sauf objectif...
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

302

le commentaire a la fin avec les notes n'est pas objectif c'est vrai mais le tableau est juste
avatar

303

Mais les entrées du tableau sont choisies de manière à faire gagner le kernel.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

304

c'e'st bien pour ca que je dis que le notes ne valent pas grand chose mais que ce qu'il y a dans le tableau est correct
avatar

305

Kevin: ben fait ton propre tableau à toi ... et montre le nous roll

306

je crains qu'il soit encore moins objectif que celui de pphd
avatar

307

c'est pour cela que j'ai dit ca ...

308

Sacré Kevin gni
LES DEUX MODES ONT AUTANT D'AVANTAGES ! Voilà pourquoi ce débat est sans fin et qu'aucun des tableaux ne sera juste.
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

309

Arrête, tu casses toute la magie du débat !

310

smile
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

311

Non mais c'est vrai, un débat qui dure 11 pages avec des posts long comme des chewing-gum collés sous la semelle, ça serait trop bête ! C'est comme une chaîne de lettre.
D'ailleurs faudrait s'y remettre parce que ça faiblit là... Nos athlètes sont-ils à bout de souffle ?

312

Allez Kevin et PpHd !!! Balancez vos arguments contre-argumentables à l'infini grin
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

313

le nostub ca puesmile
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!

314

erf wink C'est une technique de type "énervation de Kevins" ça grin
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

315

TiMad a écrit :
le nostub ca puesmile

Il n'y a aucun argument, donc tu peux garder ton enfantillage pour toi.


Et j'ai des tas de choses à répondre à ce qui a été dit depuis samedi, mais il faudra attendre que j'aie le temps.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

316

KK: c'est pas parcequ'il n'y a pas d'argument, que pour dire le contraire, tu ne dois rien "démontrer" !

317

Il n'a pas le droit d'affirmer quelque chose sans la démontrer, un point c'est tout. En plus, je ne vois pas pourquoi je devrais perdre mon temps à argumenter avec quelqu'un qui parle sur ce ton-là ("ça pue", un message comme ça est un troll clair et net).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

318

C'est pas un troll : il poste en plein jour !

319

rotfl
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

320

Que veux-tu que je reponde ? J'attend le post de Kevin smile
Et si vous voyez d'autres idees de champs a rajouter dans FlashVSNostubVSkernel, dites-le moi. J'en vois pas. Et vous ?

321

Je vois plutôt des trucs à supprimer. smile Par exemple, tous les "* libraries". C'est une ruse de ta part pour avoir plein de "flash: no, nostub: no, kernel: yes" gratuits. Ça peut tout se résumer à une seule entrée.

De plus, des trucs comme "BSS Section: yes/no/yes" n'ont rien à faire là. Ce n'est pas une fonctionnalité, c'est un détail technique. Ce qu'il faudrait mettre à la place serait "Dynamic memory allocation: yes/yes/yes", mais c'est évident de toute façon.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

322

Et tu mets plein de "no" injustifiés au _nostub:
"System Overrides: No, Yes by using TSR" -> donc Yes!
"TI-Basic extensions: No, without a hack." -> C'est possible, donc c'est Yes!
"Auto-uncompress when executing: No (directly), Yes with ttstart or EXE-packed technology" -> donc Yes!
"Comment: No" -> plus pour longtemps. Il y a déjà la spécification préliminaire. Donc encore Yes!
"Protection from buggy programs: No" -> Si, il y a le choix entre crashlib (anti-crash en librairie statique), KerNO et PreOs.

Autre truc faux:
"Size : 65520 / 8K / 24K" -> 131036 avec une DLL _nostub. Et c'est 65518 la limite pour un fichier, pas 65520.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

323

Un truc qui serait justifié, c'est:
"Uses dirty AND unsafe hacks, some of those are incompatible with AMS 2.xx" : No/No/Yes (le AND est important).
Là, je parle d'horreurs comme les RAM_CALLs de fonts. La recherche des adresses est incroyablement mal faite, lente. C'est, je le pense, surtout dû au fait que la spec est complètement stupide...

> "Size : 65520 / 8K / 24K" -> 131036 avec une DLL _nostub. Et c'est 65518 la limite pour un fichier, pas 65520.
De plus, pourquoi les programmes _nostub sont limités à 8 KO, alors que les programmes kernel seraient limités à 24 KO ? A ma connaissance, ils souffrent de la même stupide limitation software sur AMS 2.xx (et cette limitation est triviale à contourner...)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

324

Ben non justement puisque le kernel détourne cette protection roll
avatar
;)

325

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

>Ah, ben, pour gagner un utilisateur, peut-être que je ferai une version kernel
Oui smile

>cela dit, pour ces mêmes 350 fonctions, combien de place prend AMS ?
Je sais pas exactement.

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

>ma foi, s'il 'en sont encore à DoorsOS, c normal smile
grin

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

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

>En fait, je me demande si je devrai pas sortir mes progs en 4, voire 5 versions smile :
>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 smile)
>Le tout dans un même Zip...
Je te deconseille d'utiliser "kernel, compresse avec PPG".
Enfin, histoire d'alleger le zip smile

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

>Tout comme XLib
>d'ailleur meme sans fonction specialisée de plan X> gen SAUF pour le 8² ou la gen> X.
Oué. Meme dans l'affichage de ligne, de triangle, d'effets de lumiere, dans la generation de l'halo, du flipping, ...
D'ailleurs, Genlib fait du scrolling differentiel deux niveaux a 25 fps sur 92+ HW2. (Niveaux de gris, plein ecran, deux couches completes). Et XLib ?

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

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

>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. 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.
Tout le monde n'utilise pas XP smile

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

>Cool des débats imbriqués dans un même topic
>Espérons que Pphd va marcher...
Je ne pouvais pas ne pas repondre ! Et puis sans ca, je m'emmerde sur ce forum ZZzzz

326

Kevin Kofler a écrit :
Et tu mets plein de "no" injustifiés au _nostub:
"System Overrides: No, Yes by using TSR" -> donc Yes!
"TI-Basic extensions: No, without a hack." -> C'est possible, donc c'est Yes!
"Auto-uncompress when executing: No (directly), Yes with ttstart or EXE-packed technology" -> donc Yes!

Mais je les ai compte, ces yes la.

"Comment: No" -> plus pour longtemps. Il y a déjà la spécification préliminaire. Donc encore Yes!

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

"Protection from buggy programs: No" -> Si, il y a le choix entre crashlib (anti-crash en librairie statique), KerNO et PreOs.

Kerno est un kernel batard.
crashlib ne marche pas si le programme n'est pas concu pour.

Autre truc faux:
"Size : 65520 / 8K / 24K" -> 131036 avec une DLL _nostub. Et c'est 65518 la limite pour un fichier, pas 65520.

La DLL est un truc batard.

"Uses dirty AND unsafe hacks, some of those are incompatible with AMS 2.xx" : No/No/Yes (le AND est important).

Vrais exemples.

Là, je parle d'horreurs comme les RAM_CALLs de fonts. La recherche des adresses est incroyablement mal faite, lente. C'est, je le pense, surtout dû au fait que la spec est complètement stupide...

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

De plus, pourquoi les programmes _nostub sont limités à 8 KO, alors que les programmes kernel seraient limités à 24 KO ? A ma connaissance, ils souffrent de la même stupide limitation software sur AMS 2.xx (et cette limitation est triviale à contourner...)

Va lire le fichier.

327

squale92 a écrit :
> Il y a certainement un moyen de le faire. Si c'est possible en BASIC, c'est aussi possible en C
moué.. mais alors, ça fait partie des choises qu'il vaut mieuxf aire en basic que C, non ? un peu comme les progs pr faire des maths : c'est aussi rapide en basic qu'uen C, ou presque... et le basic ratrappe déjà plein de trucs (tandis que le C, par exemple, olante sur les divide by 0)

Il est non seulement tout à fait possible de coder des programmes mathématiques en C sous AMS, ça permet aussi de faire plein de choses qu'on ne peut pas faire en BASIC. Par exemple, rechercher des sous-expressions d'un certain type dans une expression et faire des manipulations sur les sous-expressions trouvées.
oéu, mais c TI : ils font un peu comme ils vuelent grin

Mais il n'y a quand-même pas de fortes chances que sprintf change de manière imprévue.
pourtant, ce serai pas mal d pouvoir rediriger la sortie standard de printf vers un fichier [sous TIGCCLIB] smile

Mais bonjour la taille des routines qui permettent cela...
ma foi... chacun sa définition de compatibilité, je suppose...
Qd j'aurai quitté la communauté, j'aimerai bien qu'un kernel se charge de rendre mes progs compatbiles avec ce qui va arriver dans le futur smile
(enfin, pr ça, fodrait que je code en kernel smile)

De toute façon, la compatibilité binaire parfaite est illusoire. Par exemple, les kernels ont été incapables de garantir la compatibilité binaire entre AMS 1 et 2, il y a eu besoin de changements dans les kernels et de recompilations, de réassemblages, voire de portages assez complexes pour les programmes. Alors que les premiers programmes _nostub (on les comptait sur les doigts d'une main à l'époque) n'avaient pas besoin de portage du tout d'ailleurs (sauf pour basiclib qui utilisait des adresses absolues toutes les 3 lignes roll).
>Il y a de bonnes chances que je serai toujours membre de l'équipe de TIGCC.
qui sait ce que l'avenir nous réservera...
il suffit de bien peu pr changer l'avenir... Car "toujours en mouvement est le futur" grin

J'ai dit "il y a de bonnes chances". Mais je suis très déterminé à rester.
je croyais que ct toi qui avait avancdé la durée de 2 mois pr PpHd.
si je me trompte, dsl... c un peu long à tout relire pr trouver le post grin

J'ai dit "des mois". Je n'ai pas précisé le nombre parce que je ne me rappelle plus exactement, mais ce qui est sûr, c'est que c'étaient plus de 2 mois.
dans mes programmes, il y a de nombreux appels de fonctions qui tiennent sur plus d'une ligne, pr des raisons évidentes de clarté !
(je sortirai pas d'exemple ici... mais dans mon projet de fin d'IUT, il doit y en avoir qui sont pas mal grin)

Je fais ça aussi en général. Mais doit-on compter ça comme plusieurs lignes?
je n'abuse pas des sprites pour "remplir l'écran entier", mais pour afficher tout ce que j'ai à afficher, voila tout !

Tu as trop à afficher. grin
en appellant 3 fois la fonction pr scroller un plan... et deux fois pr l'autre... vive la rapidité smile

C'est la meilleure manière de défiler de plusieurs pixels à la fois en horizontale. Le flag X utilisé par roxl/roxr ne peut contenir qu'un bit à la fois.
là, tu n'as fait que le fonc, en plus grin par dessus, il faut mettre les murs, les ennemis, les missiles (du joueur et des ennemis, et des murs ennemis), les power-up, les explosions, le joueur et les morceaux anexes à son vaisseau, ...

Évidemment. Mais le scrolling différentiel est un effet qui s'applique au fond, donc j'ai fait la partie relevante.
exelente question smile
mais il me semble qu'il y a des shells qui sont en gray smile

Il y a toujours des gens qui aiment les choses inutiles. grin
j'aime jouer sur les mots et les imprecisions smile
surtout qu'il est rare que tu laisse de telles failles dans ce que tu dis grin

grin
je suis à 100% d'accord... voila pkoi j'utilise ttpack pour KII smile
cela dit, ziplib a un avantage par rapport à ttpack : ziplib fonctionne on-calc smile et pr un shell, il est bon de pouvoir décompresser, certes, mais il peut aussi être utile de compresser, tu crois pas ?

Le plus important, c'est la décompression sur demande des exécutables, comme le fait TICTEX. Le reste est beaucoup moins important. On n'a pas vraiment besoin de compresser des fichiers on-calc. Si les fichiers sur lesquels on travaille sont suffisamment gros pour mériter une compression, il vaut mieux les éditer sur PC, ce qui permet aussi de les compresser correctement.
> 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
ce sont les petits rien qui font les gd tous smile

Pas du tout. J'ai déjà fait la somme de toutes les copies pour avoir les 2%, donc il n'y a plus rien à rajouter pour en faire un "grand tout". Donc ça reste un "petit rien". Et comme j'ai déjà dit, ce qui remplit vraiment ma mémoire archive, ce sont des fichiers de grande taille.
cf ce qu'on dit depuis 9 pages : le kernel n'est pas dépassé, puisqu'il évolue encore smile

Ça ne veut pas dire qu'il n'est pas dépassé! Comme j'ai déjà dit: il y a toujours des nostalgiques pour faire évoluer les systèmes totalement dépassés!
alors que le nostub n'évolue pas... auquel cas on peut dire qu'il est dépassé smile

Le format de base ne change pas parce qu'il n'a pas besoin de changer. Il est très bien comme il est. Et il y a des évolutions à l'intérieur de ce format de base. Par exemple le format de commentaires et autres données qui est en développement.
oué, ok smile
mais dans KII, par contre... les 10 fps sont pas toujours atteints sad

Trop de sprites, trop d'animations => framerate insuffisant. C'est une implication logique.
ils apportent un peu plus de fun smile
je peux faire KII en noir et blanc, en affichant des lettres au lieu de sprites, et sur l'écran prmIO, sur tu veux... comme ça, puisqu'il n'y aura que peu d'effets graphiques, ça ramera peut-être pas trop... et la jouabilité sera aussi bonne ? fo pas abuser qd même !

En effet, il ne faut pas abuser. grin Mais pas dans l'autre sens non plus! Il s'agit de trouver le juste milieu, et tu en es très loin à mon avis.
et bien, c plus joli, voila tout smile entre une dinde bien grasse et une jolie fille, tu crois pas que la jouabilité est supérieure avec une jolie fille ?

rotfl
(lol... enfin, ma foi, tant qu'il n'y a pas de filles qui passent dans cette partie du forum... grin)

Et même si elles passent, je doûte qu'elles liront ce débat sans fin. grin
tu devrai me le répéter encore une fois ou deux, au cas où j'ai mal saisi ton point de vue grin
ah, cette fois, tu ne le dit pas clairement, mais avec un sous-entendu... je compta ça pour 1/2 fois que je le répéte grin
Tu vieillis : tu commence à radoter grin
ah, tu commence à t'en rendre compte ?

Désolé, la même réponse convenait à tellement de paragraphes que je ne voyais pas trop comment éviter de me répéter. Cette fois-ci, j'ai tout simplement déplacé les citations pour répondre à toutes en même temps. smile
>Ça n'apporte pas grand chose en fonctionnalités par rapport à KerNO qui fait la moitié de la taille
tout ce que le "NO" de kerno signifie smile (entre autre)

Ce que le "NO" signifie, c'est qu'il n'y a pas de support pour le format "kernel" (DoorsOS). À part le support pour ce mode dépassé, il ne lui manque pas grand chose.
un pb quelqure part... de ton point de vue smile
moi, je veux gagner le max de temps qd je peux, pr pouvoir rajouter des effets en plus, voila tout smile

Tu devrais commencer par "gagner le max de temps" en virant tous les effets qui n'apportent rien à la jouabilité.
Allegro est loin d'être compliquée smile
sinon, je l'aurai pas pris pour projet de fin d'IUT, avec 3 gars qui n'avaient jamais touché à une librairie graphique smile

Bon, de 2 choses l'une:
- soit elle ressemble à genlib.
- soit elle est simple d'utilisation.
Je ne connais pas suffisamment Allegro pour dire laquelle des 2 solutions est la bonne, mais je connais suffisamment genlib pour pouvoir dire que si elle ressemble à genlib, elle n'est pas simple d'utilisation et vice-versa.
> l faudra m'expliquer de quels TSRs vous parlez! Parce qu'un programme _nostub n'a normalement besoin d'aucun TSR pour tourner!
ça tombe bien, puisque preOS permet aussi de faire tourner des progs non-nostub smile

Le rapport avec ce que j'ai dit, il est où??? confus
heu... excellente question smile j'ai mis le define EXECUTE_IN_GHOST_SPACE dans le fichier principal (ou quelque chose dans ce style)

Ça, c'est bon, ce #define est là pour ça.
puis, ensutie, je décompresse de l'archive vers la RAM le code que je veux exécuter
puis je fais un EX_patch dessus (sur ce qui est décompressé en RAM) puis je branche dessus

J'espère que tu as ajouté 0x40000 à l'adresse avant de faire EX_patch et de brancher.
c'est bon comme ça ? ou fo quelque chose de plus ?
(question non sarcastique, cette fois-ci : je voudrai pas que ça foire smile)

Ça devrait être bon, sauf si tu as oublié d'ajouter 0x40000 à l'adresse.
>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
ah non, justement ! c'est dans CE cas précis que tu as 36 fois le même code sur ta machine !

- "36 fois" est largement exagéré.
- Qui dit que les programmes se trouveront forcément en même temps sur la même machine?
- Même si c'est le cas, ce n'est pas une raison à elle toute seule de ne pas utiliser les librairies statiques. Déjà, les librairies statiques ont aussi leur manière d'économiser de la taille (ne pas linker les fonctions inutilisées). Et ensuite, même dans le cas très improbable où la librairie statique prendrait plus de place, les avantages des librairies statiques justifient nettement le sacrifice minimal en taille.
cf un peu plus haut, d'une...

Encore une fois: je ne vois pas pourquoi il serait si horrible que ça d'avoir plusieurs fois le même code sur une même machine, si toutes les copies sont utilisées. Je trouve bien pire de voir de la mémoire gaspillée pour du code qui traîne complètement inutilisé!
et de deux, c'est, une fois en core, TON point de vue.
perso, je préfère avoir une seule ois le code sur ma TI que 10 fois ! si les routines de grays étaient dans un lib dynamique, je te raconte pas la place qu'on gagnerai sur nons machines en mémoire !

10 fois 1 KO (taille des routines des niveaux de gris) = 10 KO. Ce n'est pas grand chose du tout.
si je reste en mode nostub, ce n'est pas parce que TU me dit (sans argumenter grin)

Les pages entières que j'ai remplies ne te suffisent pas en tant qu'argument? grin
que c mieux, mais parce que j'en ai envie.

Je suis content que tu en aies envie alors. smile
Thibaut a écrit :
Tout ça pour un débat qui n'aboutira jamais, puisque le kernel a autant de défauts que le nostub, et le nostub autant d'avantages que le kernel. Mais il y a ici deux personnes qui ne le savent pas wink

Ben non, le kernel a plus de défauts:
- impossible de lancer un programme sans installation préalable d'un programme tiers.
- gaspillage de place en utilisant une surcouche d'émulation par dessus AMS (pour une estimation de la place gaspillée, comparez la taille de PreOs avec celle de KerNO).
- complique la vie aux développeurs d'outils de développement à cause de son format difficile à gérer pour le linker.
- gaspillage de place pour les routines inutilisées des librairies dynamiques.
etc...
squale92 a écrit :
sauf que Os n'est pas vraiment des plus rapides, en général smile

Ça ne change pas grand chose à la vitesse en général.
sur l'anticrash peut-être...
mais il reste ce que le "NO" met en évidence smile

Mais c'est quand-même un concurrent pour PreOs. smile
ma foi, je suis assez d'accord... ça serait bien pratique que ce soit intégré au kernel...
comme ça, on tape directement le nom du ppg dans la ligne d'entrée, pas besoin d'appeller ttstart... (en supposant que ce soit possible, ce serait bien pratique !)

Tu peux utiliser AutoStart si tu veux. http://calc.gregd.org.
et mixer les deux [support DLL, découpage automatique] ne seait pas une bonne idée ?

Peut-être. Reste à savoir si on peut implémenter le découpage automatique dans le linker de manière acceptable. Ce ne sera presque certainement pas dans la 0.95 beta 1. Par la suite, peut-être.
>C'est peut-être du "fun", mais ça ne change rien au fait que c'est lent
voila justement pkoi l'optimisation est nécessaire smile
et pkoi il est nécessaire d'utiliser ce qu'on a de plus rapide, dans tous les dommaines smile

Ben non, voilà justement pourquoi il est nécessaire de laisser tomber ce qui est lent de par sa nature!
la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs smile

Ah bon... Je n'ai jamais essayé CF, il nécessite beaucoup trop de mémoire (à la fois archive et RAM). Pour moi, la limite de l'acceptable en comsommation de mémoire est TI-Chess. Tout ce qui consomme plus consomme trop.
fonctions de sprites par transparence ?

C'est à ça que servent les masques. Ils sont aussi plus flexibles.
encore une fois (ùmême si, cette fois, on ne parle pas de kerno), il prend moins de place... mais a moins de fonctionanlités smile

Certes, mais il propose exactement les fonctionnalités que Uther demandait...
et, en plus de cet avantage, elle ont l'avantage d'être bien lente...
cela est quelque chose de formidable ; en effet, si on n'utilise pas d'effets graphiques dans un jeu, il risque de tourner trop vite... il faut donc trouver un moyen de le ralentir !
Et bien, ce moyen est trouvé grin

rotfl
Si tu trouves nos routines de sprites lentes, tu dois n'avoir jamais essayé BitmapPut. grin
>Je dis qu'il abuse parce qu'il n'adapte pas du tout son usage d'effets spéciaux à la plateforme sur laquelle il programme n'exagérons tout de m^me pas !

Je n'exagère pas. Une arme de jeu qui tire 96 missiles à la fois n'est pas du tout adaptée à un processeur à 10 ou 12 MHz.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

328

TiMad a écrit :
[edit]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);[/edit]

MDR... Deja ya pas d'annim en background..

Si tu veux une animation, je peux te rajouter des écrans virtuels de fond.
et en plus c'est lent...

Lent comment? Je ne pense pas que ce soit trop lent pour être utilisable.
et en plus c'est incomplmet comme code.

Pas vraiment. Il manque juste le remplissage de la dernière colonne de pixels après scrolling.
XLib peut meme gerer un scroll diff à 5 niveaux avec annimation alors bon...
Il y aura un exemple dans la derniere version de XLib..

</pub> grin


Argh, il reste pas mal de gros posts auxquels je n'ai pas encore répondu. sad Je n'en suis qu'au 282 là.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

329

/me cite pphd:
>d'ailleur meme sans fonction specialisée de plan X> gen SAUF pour le 8² ou la gen> X. 
Oué. Meme dans l'affichage de ligne, de triangle, d'effets de lumiere, dans la generation de l'halo, du flipping, ... 
D'ailleurs, Genlib fait du scrolling differentiel deux niveaux a 25 fps sur 92+ HW2. (Niveaux de gris, plein ecran, deux couches completes). Et XLib ?


Arf X n'as pas de routine preformante pour les effets de lumieres et de hallo et de flipping pkoi?
pour le flipping et le hallo, il vaux mieux le faire en precalculé.. d'ailleur ya assez de ram pour ca sauf pour cf smile
Les effets de lumiere, j'ai pas encore vu de truc tres impressionnant fait avec alors bon....
pour le scroll diff, je crois que je suis bien au dessussmile mais ca reste a confirmer: )))


/me parle a kk:
Tant que tu ne me demontre pas le contraire mon affirmation est justesmile or comme tes arguments ne tiennent pas la route (contradiction etc...) bein je considere que c'est justesmile
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!

330

1. Ton affirmation n'est pas juste tant que tu ne la démontres pas.
2. J'ai déjà démontré le contraire depuis le début du topic, et il n'y a pas de contradiction dans mes arguments.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité