Kernel vs Nostub? - Page 10

PpHd a écrit :
>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.

Je répète ce que j'ai déjà répondu à Uther Lightbringer:
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.

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

-Os aussi, à mon avis.

Sauf pour certaines parties du code. Mais tout compiler en plus qu'en O2 me parait abuser.

Moi, je compile tout en -Os pour TIGCC et ça marche très bien.

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

Je ne vois vraiment pas pourquoi. Déjà, WinZIP (et WinRAR et WinACE) le décompressent sans problèmes. Et puis, untbz2 fait 23 KO. WinZIP fait nettement plus que ça.

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

On ne sait jamais. Le débâcle de EX_patch et de ttstart ne te dit-il rien? C'est une erreur (ça n'a d'ailleurs aucun rapport avec le fait que ttstart soit en _nostub, c'était tout simplement un bogue; le mode kernel n'y aurait changé strictement rien) qui a été mise en relief par une simple mise à jour de AMS.

>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 ont-ils besoin d'être mis à jour? La dizaine de programmes BASIC sur mon site n'a pas été mise à jour depuis longtemps (sauf pour CHEMISLV), mais c'est parce qu'ils n'ont pas eu besoin d'être mis à jour.

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

J'ai toujours l'impression que, soit toi, tu n'as pas compris ce que j'avais dit juste avant, soit moi, je n'ai pas compris ce que tu as voulu dire par "Mais alors pourquoi tu en tiens compte dans tes calculs ?"...

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

Oui (je l'ai même fini), mais ce n'est pas un Mario classique. Déjà parce que c'est un Yoshi.

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

"Programmer en ASM" et "utiliser tigcc.a" ne sont pas incompatibles.

>>>Mais les fonctions offertes par genlib sont sur la calculatrice même si elles ne sont pas utilisées!
>>Et bien il n'y a qu'a les utiliser
>Et si on n'en a pas besoin? On rajoute un petit effet d'intro pas trop cher en memoire et joli.

Ce n'est pas une solution au problème. Avec une librairie statique, on pourrait économiser la mémoire utilisée par ces fonctions au lieu de les utiliser "juste parce qu'elles y sont".

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

En effet, pour la place, ça se discute. Les patches d'adresses prennent sans doûte pas mal de place. Et le risque d'erreurs est aussi beaucoup plus faible en utilisant un registre qu'en patchant des adresses de partout. Et puis, il est plus propre d'utiliser un registre pour ça.

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

Par paresse? Ça ne prend pas tellement d'octets/cycles si on le fait correctement.

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

Bon, je le ferai ce weekend si j'aurai le temps.

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

Suggère-lui ça alors.
Mais j'ai l'impression que tu fais exprès de ne pas donner de suggestions pour KerNO parce que c'est un "concurrent".

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

Ben, c'est ce que le premier à répondre fait en général. Moi, en général, je commence ma réponse par quelque chose comme ça: "Déjà, arrête d'utiliser DoorsOS, c'est totalement dépassé. Si vraiment tu as besoin d'un kernel (la plupart des programmes récents n'en ont plus besoin), télécharge PreOs sur http://www.timetoteam.fr.st."

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

Ce qui alourdit le tout. Tu aurais dû intégrer ttunpack_decompress à PreOs, comme ça pas besoin de librairie de décompression, et un taux de compression meilleur.

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.

Avec des erreurs. Cf. flag V200.

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

Pas tout à fait si les fichiers sont dans des répertoires différents. On peut quand-même les envoyer tous en même temps, mais il faut d'abord les aller chercher séparément pour les ajouter à la liste des fichiers à envoyer.

>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

Mais DOS est dépassé et difficile à utiliser.

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

Ils sont dans le même répertoire normalement, donc, pour les rajouter à la liste des fichiers à envoyer, c'est juste un double-clic en plus.

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

Non. Je répète qu'on s'attend à ce que le programme marche sans avoir lancé quoi que ce soit avant.

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

GCC est assez lourd en effet, mais y a-t'il des compilateurs légers avec des fonctionnalités comparables? Il ne me semble pas.

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

Évidemment, si on retire toutes les fonctionnalités intéressantes de AMS, on a la place.

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

De toute façon, très peu de gens utiliseront Pedrom, donc ça ne vaut pas le coup.

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

Il y a aussi des défauts objectifs indéniables. Cf. le premier paragraphe de réponse de ce message.

>>(Utiliser les ordinaux est bien mieux qu'utiliser les noms exportes par exemple).
>Ç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

Parce qu'un linker normal identifie une fonction par son nom. D'ailleurs, tu es obligé de passer par des #defines ou des equates pour associer les noms à des numéros. Pour un système de librairies qui identifie les fonctions par leur nom (le système de librairies statiques de TIGCC par exemple), on n'en a pas besoin.

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

Tu n'es pas souvent passé sur le forum de la TICT et sur celui de TI apparemment. Il y a pas mal de gens qui disent que les kernels sont complètement obsolètes là-bas.

Je pense que meme TN ou ZJ ne pensent pas qu'il est depasse (ca veut pas dire qu'ils l'aiment !)

Je pense que tu te trompes là.

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

Ben, les bogues qui empêchent aux jeux en question de s'appeler "version 1.00".

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

Tu n'as pas dû bien écouter quand le sujet revenait régulièrement. Et ce n'étaient pas seulement les utilisateurs finaux (end-users) à s'en plaindre, mais aussi certains programmeurs utilisant genlib. Dark Angel par exemple.

Des bugs occasionnels il est vrai.

Tout dépend de ta définition de "occasionnels".

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

Je m'en fiche de la spécification.
La spécification de AMS interdit les programmes en RAM >24 KO et les TSRs en RAM, et pourtant tout le monde s'en fout.
L'important est que ça marche.

>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'est parce qu'il fallait d'abord que je trouve les bons flags pour le faire. Et que le système de compilation de TIGCC est "hérité" du mainteneur précédent (Romain Liévin), et que je n'ai pas encore eu le temps de faire tous les nettoyages nécessaires (par exemple, virer autoconf et automake pour les programmes qui n'en ont pas besoin - ça accélèrerait pas mal la compilation).

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

Bon, voilà 2 exemples (je ne mets pas le code concret, parce que ça serait long et n'apporterait rien de plus que la description en mots):
- remplacer un buffer statique (pour une fonction de style sprintf) par un buffer alloué, plus grand, quand c'est nécessaire
- traverser une table dans un programme en modifiant l'adresse à lire à chaque fois
Évidemment, il y a aussi d'autres manières, plus propres, de coder ça, mais les exemples sont quand-même utiles et cohérents.

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

Tu importes le code pour EXECUTE_IN_GHOST_SPACE (un seul xdef), et tu fais:

 move.w %d0,-(%a7)
 move.l HeapDeref*4(%a5),%a0
 jsr (%a0)
 addq.l #2,%a7
 adda.l #0x40000,%a0
 jsr (%a0)
 nop;nop;nop |pour RETURN_VALUE

C'est tout bête.

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

Montre-moi des saletés dans les programmes TICT alors.

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

Mais ce sont quand-même des patches supplémentaires à maintenir. J'ai déjà passé assez de temps à porter le patch TIGCC vers GCC 3.3 comme ça.

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

Pourquoi? Le code de démarrage de TIGCC est prévu pour fonctionner indépendemment de ce que fait le programme principal.

Ce post illisible vous était offert par...

Le seul débat stérile auquel Kevin se jette éperdument...

PpHd a écrit :
>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.

C'est trop tard. Il y a déjà des programmes qui les utilisent (de la manière prévue). Duke68k et CalcRogue par exemple.

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

Bon, d'accord, l'API exportée n'est pas parfaite en effet. Mais l'important est que les fonctions soient dans la ROM.

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

Bon, on remplace "100%" par "99%". Mais il est très improbable que les versions futures de AMS exporteront moins de fonctions. Ce n'est pas du tout dans la logique de TI. Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas. Ils ont quand-même un minimum de souci de compatibilité, même si on les accuse souvent du contraire.

>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

Ah, je vois (c'est dans le ZIP de Pedrom que tu m'as envoyé pour le problème avec A68k ). Il y a pas mal de trucs qui pourraient nous intéresser (pour la documentation de TIGCC) dans ton Note.txt.
Mais il y a certainement un moyen de définir un menu CUSTOM en C.

>>Et on peut y acceder quand meme pas un NG_execute bien place.
>Oui, mais c'est plus compliqué et plus lent.
C'est plus simple

Plus simple? C'est plus simple de lancer un NG_execute avec des tags qu'un simple cmd_custmon???

Plus lent, cela reste a voir.

C'est certainement plus lent! NG_execute doit interpréter les tokens, puis exécuter le bon cmd_.... Il est certainement plus rapide d'appeler cmd_... directement.

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

Et alors?

>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

Certes. Mais je parlais de ce que ça apporterait comme fonctionnalité à un programme, pas ce que ça apporterait pour une librairie standard pour faciliter les portages.

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

TI-Connect n'est pas juste une surcouche du logiciel GraphLink. Par exemple, il supporte les câbles USB, ce qui n'est pas le cas du logiciel 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

Et c'est bien dommage.

>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

1. Je me demande bien comment tu veux faire cet "émulateur". Il faudra changer le code du programme de partout, et pour l'écran, les changements ne sont pas automatisables à mon avis.
2. Cet "émulateur" marcherait exactement de la même manière en _nostub.

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

Nos #defines de compat.h sont tout aussi faciles à changer. De même si le programme lui-même utilise la même technique (#define CONST1 (TI89?1:2)).

>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();

Bon, en fin de compte, tu as raison, ce n'est pas si dur que ça parce qu'on ne passe à l'exportation que quand l'importation est déjà finie, et que donc les symboles spéciaux ont déjà été traîtés.

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

Tu utilises quoi alors? Notepad???
TIGCC IDE est très pratique, même si tu programmes en assembleur!

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

Moi, j'aime bien, c'est la syntaxe GNU. Crois moi, on arrive très bien à s'y habituer.
Mais personne ne t'empêche de continuer à utiliser A68k ou d'utiliser le flag --register-prefix-optional de GNU as.

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

Mais BitmapPut de AMS l'est! Et c'était ça, le contexte. Je ne vois pas du tout ce que vient y faire ExtGraph (à part que tu as recopié le code de ExtGraph pour implémenter BitmapPut ).

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

Réponse floue. Qu'est-ce qui est impossible exactement? D'allouer un bloc de plus de 65520 octets?

2. On alloue deux handles et on les relie entre eux a l'iniailisation. La taille totale geree est donc 2*64Ko - qqs octets.

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

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

C'est justement ça ton erreur, à mon avis.

>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

Et ben, je ne suis pas d'accord.

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

Tu peux essayer de les envoyer à XDanger. Il peut aussi faire des mises à jour des logiciels TICT si c'est vraiment important.

>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

Je ne vois pas en quoi ma solution (rajouter un nouveau RAM_CALL pour font_medium, changer font_small et font_large, et garder _RAM_CALL_00E pour les fontes du boot) causerait des problèmes de compatibilité. Mais bon, tu fais ce que tu veux, de toute façon, je n'utilise aucun de ces RAM_CALLs. (Vive le _nostub! )

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

Certes, mais un appel de fonction est quand-même une ligne logique.

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

Ce que je dis est que le fait qu'il y a une mise à jour qui accélère les routines de prévue n'est pas une excuse valable pour ne pas créer une version statique. Si le programmeur a vraiment besoin de la vitesse supplémentaire apportée par la mise à jour, il recompilera/réassemblera/relinkera quand la librairie est mise à jour. Je n'ai pas du tout mis en question le fait que tu n'as pas le temps de sortir la mise à jour tout de suite.

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

Tu veux que je t'écrive la documentation pour toi? J'ai autre chose à faire.

Bon, commence par expliquer qu'une des 2 tables (je ne sais plus laquelle - ces abbréviations sont du chinois pour quelqu'un qui n'a jamais programmé sur une console) est une table de décalages de lignes par octets (donc par pas de 8 pixels), et que l'autre est une table de décalages horizontaux par pixel. C'est surtout ça qui manque effroyablement dans la documentation.

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

C'est peut-être du "fun", mais ça ne change rien au fait que c'est lent.

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

TI-89/92+/V200.
Les jeux avec FAT Engine ou d'autres techniques 3D tournent souvent autour des 10 FPS. Les jeux en 2D ont des framerates nettement plus élevés.

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

À peine, mais quand-même.

>>>Et hop, plus besoin de USE_KERNEL.
>>Mais non.
>Mais si. Mais non.

Je pense qu'on n'ira pas plus loin sans arguments et en ayant un peu perdu le contexte.

Le contexte, c'était des conseils à Uther Lightbringer pour comment il peut se passer des librairies qui nécessitent USE_KERNEL. J'ai donc dit qu'en appliquant ces conseils, USE_KERNEL n'est plus nécessaire. Toi, tu as prétendu le contraire. J'aimerais bien que tu m'expliques ton raisonnement...

>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

Il faudra m'expliquer pourquoi ça rame alors...

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

Pour les recopier pour le BitmapPut de Pedrom?

>Il est beaucoup plus simple de travailler avec le scrolling de ExtGraph [qu'avec des plans]. TOTALEMENT FAUX !

Ben, je te signale que pour le scrolling de ExtGraph, il est très facile de comprendre comment il marche. Le système de plans est plus compliqué.

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

Ben, alors, il suffit d'expliquer dans le lisezmoi comment on utilise ttstart.

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

Non, parce que leur affichage n'a pas besoin de 100 ms tout simplement. Et cela indépendemment de la librairie graphique utilisée.

>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

Quelle 3D? 3D isométrique? Dans ce cas, ce n'est pas vraiment de la 3D (ce sont juste des sprites avec un masque non-rectangulaire), et c'est normal que ça ne rame pas.

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

NON.

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

Parce que les fonctionnalités ne sont pas identiques. On peut lancer le programme de manière plus directe avec le lanceur personnalisé.
D'ailleurs, il y a aussi AutoStart comme troisième solution. Ça permet de combiner lanceur commun et lancement direct. Le désavantage est qu'il y a un TSR à installer.
C'est à l'utilisateur de choisir entre les 3 méthodes, pas au programmeur.

>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 il utilise ce qu'il connaît et il est content.
Et si tu veux qu'il connaisse les autres solutions, décris-les dans le fichier lisezmoi de ton programme.

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

En quoi est-ce un problème? Les fonctions de gray.h sont simples à utiliser et efficace, donc pourquoi dupliquer l'effort en en mettant d'autres dans ExtGraph? D'autant plus que c'est Thomas qui a écrit les routines de TIGCCLIB. Il ne va pas faire de la concurrence à ses propres routines!

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

Il manque quoi (à part les fonctions clippées, ça on le sait déjà)?

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

D'où l'intérêt de ne pas rajouter des fonctions compliquées et à intérêt doûteux (par exemple tes 2 fameuses "super tables") à sa librairie graphique.

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

Toutes sortes de jeux ou autres programmes.

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

C'est la même chose.

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

Seulement après avoir installé l'interpréteur du format (c'est-à-dire le kernel).

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

Il fonctionne très bien! À part pour un programme avec des milliers de relogements (*ahem* CC *ahem*), évidemment.

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

Elle ne convient pas très bien parce qu'elle n'existe qu'en dynamique.

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

Ben oui, je ne peux pas attendre de mes utilisateurs qu'ils aient un kernel d'installé, donc mes TSRs doivent eux-mêmes s'occuper de l'installation de h220xTSR.
Et de plus, même si on installe un kernel, rien ne dit que le kernel est installé avant mes TSRs et pas après.

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

Mais ttpack compresse mieux que les librairies utilisables pour les packs archive de PreOs.
Et puis:
>de toute façon, les programmes concerné sont au format kernel
Justement, le problème est là!

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

Sauf que mes calculs ont pris des cas moyens, voire des cas qu'on croierait extrêmement favorisants pour les librairies dynamiques, mais qui en fait, calculs faits, ne l'étaient pas du tout.

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.

Et ben, je dis que tu te trompes là. Vu la taille de genlib (autour de 16 KO) et vu la taille des routines utilisées d'habitude dans ExtGraph (autour de 2 KO: 1 KO pour les niveaux de gris de TIGCCLIB et 1 KO pour les fonctions de ExtGraph elle-même), il faut au moins 8 jeux avec genlib pour que le fait que genlib est une librairie dynamique soit rentable. Or, les jeux avec genlib ont généralement besoin de nettement plus de 655360/8=81920 octets d'archive en tout (cf. SMA, CF, ...), donc la solution de ExtGraph est meilleure. Et la compression n'y changera rien, vu qu'elle compresse genlib et ExtGraph de la même manière.

>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()"

Tu utilises AutoStart si tu veux absolument lancer le programme par son nom seul sans utiliser de lanceur personnalisé. Il prend moins de place que PreOs même en rajoutant la taille de ttstart!

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

N'empêche que pas mal de ses fonctions sont inutiles pour la plupart des programmes qui l'utilisent. Attention, je ne dis pas qu'elles ne sont pas utiles pour certains programmes, mais juste qu'elles traîneront inutilisées dans la plupart des cas parce que le principe des librairies dynamiques ne permet pas d'envoyer des fonctions au système de destination ("target", ici la calculatrice) de manière sélective.

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

Grâce au système de librairies statiques, pas grâce à genlib ni au système de librairies dynamiques!

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

Si, elle est plus compliquée!

TIGCCLIB en plus d'etre lente n'est pas pratique a mon gout. Ceci dit je n'ai jamais dit qu'elle marchait mal

Les fonctions GraySprite*_MASK de ExtGraph sont en effet un peu plus pratiques parce qu'un seul appel de fonctions suffit à la place de 4. Mais les fonctions de TIGCCLIB ont le grand avantage de prendre moins de place, parce que la même routine peut afficher en AND, OR et XOR,

>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

Il y en a eu nettement moins. Le mot "bug" apparaît 20 fois (dont 5 fois au pluriel) dans l'historique de genlib, et seulement 4 fois dans celle de ExtGraph.

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

Mais non. Si la différence de vitesse est négligeable, elle est négligeable!

>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

Si, c'est un abus du format.

>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

Ce ne sera qu'un compromis, et ce sera très loin d'une solution idéale. La solution idéale, c'est le linkage statique: la librairie peut offrir toutes les fonctions qu'elle veut, et le "programme client" choisit uniquement celles qui l'intéressent.

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

Je ne vois pas en quoi c'est plus dur pour eux d'aller télécharger un décompresseur de .tar.bz2 que d'aller décompresseur de ZIPs. D'autant plus que les décompresseurs ZIP les plus utilisés (WinZIP et compagnie) comprennent aussi les tar.bz2.

Ximoon
a écrit : 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.

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.

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.

Dans le Mario à 1 fps, on avance par pas de 5 ou 10 pixels quand on court.
Et évidemment qu'un Mario à 1 fps n'est pas comparable à un SMA. Mais un Mario à 10 fps l'est tout à fait!

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!

Le problème, c'est que souvent il y a un conflit entre "laisser les programmeurs programmer comme ils l'entendent" et "laisser les utilisateurs utiliser ce qu'ils veulent". Cf. mode kernel: si on laisse les programmeurs programmer en mode kernel, on empêche aux utilisateurs de ne pas utiliser de kernel.

[ftp83plus]
a écrit : Ce post illisible vous était offert par...

Ce n'est pas le post qui est illisible, c'est toi qui es trop paresseux de le lire. C'est dommage, il y a des choses intéressantes qui sont dites.

Le seul débat stérile auquel Kevin se jette éperdument...

Il n'est pas vraiment stérile.

Arf, là, ça fait à peu près 5 heures que je poste ici. Mais j'ai répondu à tout là.

Mais c'est quand même stérile, depuis combien de temps ce débat existe ...

Et bien tu aurais mieux fait de déposer les armes et d'aller dormir

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

ma foi, je trouve le switch pr le supprimer très utile
Dès que je dl une nouvelle version de preOS, je supprime le switch pr HW2tsr, le switch qui permet de supporter les HW2, le switch pr afficher les boites de dialogues à la fin de l'installation...
Et je recompile
Comme ça, preOS ne contient que ce dont j'ai besoin : il prend moins de place, et j'ai pas de crise de nerfs avec 36 boites de dialogue
(d'ailleurs, PpHd, merci pr ces swithc )

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)

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

oéu, mais c TI : ils font un peu comme ils vuelent

On peut avec printf sur PC.

arf, ok

Pas avec TIGCCLIB évidemment.

erf, clair
pourtant, ce serai pas mal d pouvoir rediriger la sortie standard de printf vers un fichier

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

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
(enfin, pr ça, fodrait que je code en kernel )

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"

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

oops
désolé. pas pris le temps de consulter la doc

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

j'en sais rien : je n'ai encore jamais utilisé genalib... même si le concept me tente bien

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

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

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

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 )

Tu mets un 0 de trop!

heu... oué, possible... encore que...
tout dépend du contecte, si on parle sur TI ou sur PC

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

je n'abuse pas des sprites pour "remplir l'écran entier", mais pour afficher tout ce que j'ai à afficher, voila tout !

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

mais ça permet pas d'avoir des objets se déplaçant dans tous les sens, à des vitesses différentes

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

c'est ce que je fais moi-même : je redessine tout à chaque cycle, après avoir tout effacé
(je n'utilise donc que les fonctions d'efacement d'écran et d'affichage de sprite)
comme ça, je sais ce que je fais, et je sais comment je le fais... avec mes propres algos
(qui sont peut-être pas toujours les meilleurs, comme en témoigne certaines idées d''optimisaiton que je n'ai pas encore mis en application)

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.

en appellant 3 fois la fonction pr scroller un plan... et deux fois pr l'autre... vive la rapidité
là, tu n'as fait que le fonc, en plus
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, ...

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

exelente question
mais il me semble qu'il y a des shells qui sont en gray

2. TIGCCLIB suffit pour les niveaux de gris

certes
mais juste au dessus, tu as dit que AMS suffisait pr un shell
(enfin, tu l'as dit dans la citation que tu as repris de ce que je te citais )

Ç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

j'aime jouer sur les mots et les imprecisions
surtout qu'il est rare que tu laisse de telles failles dans ce que tu dis

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

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

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

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

cf ce qu'on dit depuis 9 pages : le kernel n'est pas dépassé, puisqu'il évolue encore
alors que le nostub n'évolue pas... auquel cas on peut dire qu'il est dépassé

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

oué, ok
mais dans KII, par contre... les 10 fps sont pas toujours atteints

(je me cite moi-même )mais je dois reconnaitre que je n'ai que des algos merdiques

dans K...
dans KII, ils sont déjà un peu meilleurs... et encore optimisables
(et seront optimisés avant que KII sortent en bêta publique )

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

oué, moi non plus

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é

ils apportent un peu plus de fun
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 !

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

c'est vrai...
mais (je pars sur Solar Striker, dont je me sens plus proche) dans Solar Striker, on n'a pas non plus bcp de missiles... pas bcp de sortes d'armes différentes... et juste un povre canon avant, c lassant, au bout d'un moment

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

et bien, c plus joli, voila tout
entre une dinde bien grasse et une jolie fille, tu crois pas que la jouabilité est supérieure avec une jolie fille ?
(lol... enfin, ma foi, tant qu'il n'y a pas de filles qui passent dans cette partie du forum... )

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

tu devrai me le répéter encore une fois ou deux, au cas où j'ai mal saisi ton point de vue

Ç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
(entre autre)

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

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
Tu vieillis : tu commence à radoter

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

ah, tu commence à t'en rendre compte ?
un pb quelqure part... de ton point de vue
moi, je veux gagner le max de temps qd je peux, pr pouvoir rajouter des effets en plus, voila tout

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

Allegro est loin d'être compliquée
sinon, je l'aurai pas pris pour projet de fin d'IUT, avec 3 gars qui n'avaient jamais touché à une librairie graphique

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

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

heu... excellente question
j'ai mis le define EXECUTE_IN_GHOST_SPACE dans le fichier principal (ou quelque chose dans ce style)
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
c'est bon comme ça ? ou fo quelque chose de plus ?
(question non sarcastique, cette fois-ci : je voudrai pas que ça foire )

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 !

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

en parlant de ça, la 92 a exactement 92% de pixels de plus que la 89
(un peu hors sujet, mais bon )

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.

cf un peu plus haut, d'une...
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 !

Strictement rien.

il me semblait aussi

Reste en _nostub, c'est mieux

si je reste en mode nostub, ce n'est pas parce que TU me dit (sans argumenter ) que c mieux, mais parce que j'en ai envie.

/me cite Ximoon

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.

merci de me soutenir

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

/me a lu jusqu'au post 269... (donc, la seule chose qu'il ait raté est la page 10)
/me répondra à la page 10 plus tard

Je crois que ce topic détient un record : vu la taille des posts, c'est le topic le plus petit de yAronet occupant le plus de place dans la BDD

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

Et hop ! topics/2-19542-sources-side-et-as#28 Voilà un avantage du mode kernel
La version kernel de CC prend 8,7 ko de moins que la version nostub !!!

Haaa le kernel c'est vraiment bien comme format

/me cite la page 10

/me cite Kevin, post 270

-Os aussi, à mon avis

sauf que Os n'est pas vraiment des plus rapides, en général

Mais j'ai l'impression que tu fais exprès de ne pas donner de suggestions pour KerNO parce que c'est un "concurrent".

sur l'anticrash peut-être...
mais il reste ce que le "NO" met en évidence

Tu aurais dû intégrer ttunpack_decompress à PreOs, comme ça pas besoin de librairie de décompression, et un taux de compression meilleur

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

[cite]Mais DOS est dépassé et difficile à utiliser(/cite]
mais qd tu sais l'utiliser, tu passe pr un Dieu
(ou pour un fou )

/me cite Kevin, 272

C'est trop tard. Il y a déjà des programmes qui les utilisent (de la manière prévue). Duke68k et CalcRogue par exemple.

et mixer les deux ne seait pas une bonne idée ?
/me cite Kevin, 273

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
et pkoi il est nécessaire d'utiliser ce qu'on a de plus rapide, dans tous les dommaines

Quelle 3D? 3D isométrique? Dans ce cas, ce n'est pas vraiment de la 3D (ce sont juste des sprites avec un masque non-rectangulaire), et c'est normal que ça ne rame pas

la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs

D'autant plus que c'est Thomas qui a écrit les routines de TIGCCLIB

ça me rappelle une bonne série d'engueulades voila quelques temps...

Il manque quoi (à part les fonctions clippées, ça on le sait déjà)?

fonctions de sprites par transparence ?

/me cite Kevin, 274

Il prend moins de place que PreOs même en rajoutant la taille de ttstart!

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

Mais les fonctions de TIGCCLIB ont le grand avantage de prendre moins de place, parce que la même routine peut afficher en AND, OR et XOR

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é

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 !

Et évidemment qu'un Mario à 1 fps n'est pas comparable à un SMA. Mais un Mario à 10 fps l'est tout à fait

ben alors, il a interet à être bien réussi, ton mario



/me a lu jusqu'au post 277

[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.. et en plus c'est lent... et en plus c'est incomplmet comme code.

XLib peut meme gerer un scroll diff à 5 niveaux avec annimation alors bon...

Il y aura un exemple dans la derniere version de XLib..

>Mais c'est le format natif standard qu'il faudrait respecter...
Je le respecte, sinon ca ne pourrait jamais se lancer.

>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...
C'est vrai ca.

>D'où mon conseil de laisser tomber genlib et d'utiliser une librairie graphique statique.
Plutot fait la fonctionner en mode kernel.

>Je ne vois pas pourquoi, selon toi, ça serait une bonne idée pour PreOs et pas pour mes TSRs à moi.
Du point de vue utilisateur M'enfin ca peut se discuter sans probleme. Et je n'ai pas envie d'en disserter.

>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.
Arg mais avant de le laisser faire ce qu'il veut, il faudrait lui expliquer les choix qui s'offrent a lui.

>... 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).
Sauf que c'est souvent faux. Cf cc qui est de 64K en _nostub et moins de 56K en kernel...

>Je te signale que ttstart (et donc aussi les lanceurs personnalisés) n'a besoin d'aucun TSR pour fonctionner!
Il parlait des equivalents !

>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.
Et s'il connait les trucs et astuces a utiliser...

>Mais ça prend encore plus de place! genlib en prend déjà trop toute seule!
Compressee, elle ne prend pas tant de place.

>Ben si, on peut aussi faire un jeu qui utilise ExtGraph sans savoir comment fonctionne genlib.
Tu veux montrer quoi en affirmant cela ?

>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.
Oui. BitmapPut aussi.

>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.
On ne peut raisonnablement pas comparer les degres de complexite des deux librairies.
Et les bugs sont souvent mineurs.

>Mais ça ne sert à rien.
Pour toi oui. Pour certains non.

>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.
Et 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.
Si c'est possible
Une Pack-Archive contenant une centaine de sous-DLL

<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.
Cf au dessus.

>- 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)
Bof. On aurait pu faire de meme avec plusieurs.

>- 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!)
Un hack est facile.

>Il y a certainement un moyen de le faire. Si c'est possible en BASIC, c'est aussi possible en C.
Mais pas en utilisant ces fonctions.

>Quels "hacks proposés par PpHd"?
Les trucs utilises lors de l'install de PreOs surement.

>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.
Oué, mais justement, c'est parce que le fichier 'printf.c' n'a JAMAIS ete recompile. S'il le recompilait (rien que par le fait qu'ils vont changer leurs flags de compilation), la methode actuelle serait invalide.

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


>BitmapPut de AMS est clippé! À ton avis, il sert à quoi, le paramètre SCR_RECT *clip
A clipper. Pas eu le temps de mettre le clipping. Si quelqu'un est interresse

>genalib gère-t'elle ça de manière transparente?
Oui. Y'a genalib::add_block pour cela.

>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 les DLL windows ne sont pas prevus pour etre partages aussi
Vous auriez mieux fait de mettre 'EASM' comme extension Extended Assembly file.


>PpHd a mis bien plus de 2 mois pour corriger le problème, et puis c'était une seule instruction d'assembleur à rajouter.
Au moins 1 an
Je n'ai aucune excuse.

>Mais un appel de fonction est quand-même une ligne logique.
C'est un concept certifie ?

>Ben, évidemment, si tu abuses des sprites pour remplir l'écran entier, il est normal que ce soit lent.
Tu dois pas beaucoup aimer les shoots toi

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

>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.
Certes, mais les routines de genlib sont optimises pour.

>Si tu fais la même chose, le scrolling différentiel devient trivial.
moins que dans genlib.

>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):
Ton code est nul

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

>Et de toute façon, ces effets graphiques ne changent rien à la jouabilité.
Joue a Quake3 en mode flat alors

>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.
Phoenix affiche beaucoup de vaisseaux et de missiles a la fois

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

>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!
il en est hors de questions !

>>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é.
File moi un exemple precis et je chercherais un moyen.

>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.
Faux le kernel mettrait en place une surcouche emulation de l'ancien hardware.
Le seul truc c'est de faire une traduction temps reel de la matrice clavier (Ca roulerait bien).
Pour l'ecran, une int qui s'occupe de la traduction fera l'affaire.
Encore mieux : si le programme fonctionne avec genlib, une adaptation complete de genlib permettrait de s'en sortir facilement (sans a avoir a recompiler tous les autres programmes). Vive genlib

>La routine de AMS est clippée!
Elle le sera.

>Et c'est tout à fait normal qu'on compare, vu que c'est exactement le même concept.
Non. Toi c'est une Extended Assembly File.

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

>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.
Et lorsqu'on a plusieurs libs statiques de versions differentes entre elles incompatibles entre elles et que chaque programme necessite une version differente ?

>Strictement rien.
>Reste en _nostub, c'est mieux.
Taille, mon respect. Ca tournerait sur ma calc

>Je ne vois vraiment pas pourquoi. Déjà, WinZIP (et WinRAR et WinACE) le décompressent sans problèmes. Et puis, untbz2 fait 23 KO. WinZIP fait nettement plus que ça.
Certes dont moi, ont des vieilles versions de WinZip et ont pas envie de mettre a jour.
Moi je m'en moque, j'ai bzip2.exe

>On ne sait jamais. Le débâcle de EX_patch et de ttstart ne te dit-il rien? C'est une erreur (ça n'a d'ailleurs aucun rapport avec le fait que ttstart soit en _nostub, c'était tout simplement un bogue; le mode kernel n'y aurait changé strictement rien) qui a été mise en relief par une simple mise à jour de AMS.
Mes macros ne fonctionnent qu'en mode algortihmique pur. Aucun appel de fonction AMS, ni de references materielles.

>Mais ont-ils besoin d'être mis à jour?
Je sais pas. Ca fait longtemps que je n'y ai plus joue

>La dizaine de programmes BASIC sur mon site n'a pas été mise à jour depuis longtemps (sauf pour CHEMISLV), mais c'est parce qu'ils n'ont pas eu besoin d'être mis à jour.
Tant mieux pour tes progs.

>J'ai toujours l'impression que, soit toi, tu n'as pas compris ce que j'avais dit juste avant, soit moi, je n'ai pas compris ce que tu as voulu dire par "Mais alors pourquoi tu en tiens compte dans tes calculs ?"...
On arrete ce dialogue de sourd et muet ?

>Oui (je l'ai même fini), mais ce n'est pas un Mario classique. Déjà parce que c'est un Yoshi.
LOL

>"Programmer en ASM" et "utiliser tigcc.a" ne sont pas incompatibles
Mais programmer en ASM peut faire utiliser les romcalls directement

>Ce n'est pas une solution au problème.
Si, c'est une solution.

>Avec une librairie statique, on pourrait économiser la mémoire utilisée par ces fonctions au lieu de les utiliser "juste parce qu'elles y sont".
Mais elles y sont ! Donc autant les utiliser.

>En effet, pour la place, ça se discute. Les patches d'adresses prennent sans doûte pas mal de place.
Sauf que parfois on a aussi besoin de plus de 16 registres en meme temps.
Le SMC permet de resoudre cela.

>Et le risque d'erreurs est aussi beaucoup plus faible en utilisant un registre qu'en patchant des adresses de partout. Et puis, il est plus propre d'utiliser un registre pour ça.
Pas tant que ca. Les erreurs surviennent en general tres vite. Si ca passe une fois, ca passera les autres.

>Par paresse? Ça ne prend pas tellement d'octets/cycles si on le fait correctement.
Non. Mais j'aime garder un max de registres pour mes routines.

>Bon, je le ferai ce weekend si j'aurai le temps.
Rappel de francais (Juste histoire que tu te plantes pas dans un exam) :
"je le ferai ce weekend si j'<AI> le temps. "
Futur + SI + present. Desole

>Mais j'ai l'impression que tu fais exprès de ne pas donner de suggestions pour KerNO parce que c'est un "concurrent".
C'est plutot que j'ai pas le temps
Et puis il a du y penser de lui meme non ? C'est trivial a penser.
Il a du choisir DlgMsg pour certaines raisons.

>Ben, c'est ce que le premier à répondre fait en général. Moi, en général, je commence ma réponse par quelque chose comme ça: "Déjà, arrête d'utiliser DoorsOS, c'est totalement dépassé. Si vraiment tu as besoin d'un kernel (la plupart des programmes récents n'en ont plus besoin), télécharge PreOs sur http://www.timetoteam.fr.st."


>Ce qui alourdit le tout. Tu aurais dû intégrer ttunpack_decompress à PreOs, comme ça pas besoin de librairie de décompression, et un taux de compression meilleur.
Ca n'alourdit pas vraiment. Le code utilise reellement le potentiel du kernel.
Et tu peux parfaitement utiliser ttunpack

>Avec des erreurs. Cf. flag V200.
Je ne suis pas infaillible.

>Mais DOS est dépassé et difficile à utiliser.
Difficile
Et il manque un autoexec.bat a ASM plutot

>Non. Je répète qu'on s'attend à ce que le programme marche sans avoir lancé quoi que ce soit avant.
Pas moi.

>GCC est assez lourd en effet, mais y a-t'il des compilateurs légers avec des fonctionnalités comparables? Il ne me semble pas.
GTC est largement suffisant a mon avis.
Surtout si on veut faire du code portable d'un compilo a un autre.

>Évidemment, si on retire toutes les fonctionnalités intéressantes de AMS, on a la place.
C'est surtout qu'AMS n'est pas optimise en taille. En moins de 64K, 350 fonctions d'AMS. Tu trouves ca normal ?

>De toute façon, très peu de gens utiliseront Pedrom, donc ça ne vaut pas le coup.
moi de toute facon.

>Il y a aussi des défauts objectifs indéniables. Cf. le premier paragraphe de réponse de ce message.
C'est corrigeable.

>Parce qu'un linker normal identifie une fonction par son nom. D'ailleurs, tu es obligé de passer par des #defines ou des equates pour associer les noms à des numéros.
Tout OS identifie ces fonctions internes par des numeros, pas par des noms.
Tu peux utiliser directement sous la forme malib__0000();
C'est lisible.

>Pour un système de librairies qui identifie les fonctions par leur nom (le système de librairies statiques de TIGCC par exemple), on n'en a pas besoin.
C'est une tres mauvaise idee a mon avis.

>Tu n'es pas souvent passé sur le forum de la TICT
Si. Mais je ne vois pas beaucoup de debat en parlant.

>et sur celui de TI apparemment.
Jamais.

>Il y a pas mal de gens qui disent que les kernels sont complètement obsolètes là-bas.
Ils disent des conneries c'est tout.

>Je pense que tu te trompes là.
C'est mon droit.

>Ben, les bogues qui empêchent aux jeux en question de s'appeler "version 1.00".
Ben ces jeux sont concus pour etre beaus, riches et complexes. Donc ca prend du temps, surtout si on fait autre chose par ailleurs.

>Tu n'as pas dû bien écouter quand le sujet revenait régulièrement.
Si mais j'ai corrige.

>Et ce n'étaient pas seulement les utilisateurs finaux (end-users) à s'en plaindre,
Qui ?

>mais aussi certains programmeurs utilisant genlib. Dark Angel par exemple.
La c'etait le probleme de la detection de Vti. Un faux probleme.

>Je m'en fiche de la spécification.

>La spécification de AMS interdit les programmes en RAM >24 KO et les TSRs en RAM, et
>pourtant tout le monde s'en fout. L'important est que ça marche.
Si tu me trouves un patche viable.

>Bon, voilà 2 exemples (je ne mets pas le code concret, parce que ça serait long et n'apporterait rien de plus que la description en mots):
- remplacer un buffer statique (pour une fonction de style sprintf) par un buffer alloué, plus grand, quand c'est nécessaire
- traverser une table dans un programme en modifiant l'adresse à lire à chaque fois
Évidemment, il y a aussi d'autres manières, plus propres, de coder ça, mais les exemples sont quand-même utiles et cohérents.

Tes deux exemples fonctionnent aussi en kernel. Suffit de faire l'init soit meme, ce qui est quand meme bien plus propre.

>Tu importes le code pour EXECUTE_IN_GHOST_SPACE (un seul xdef), et tu fais:
> move.w %d0,-(%a7)
> move.l HeapDeref*4(%a5),%a0
> jsr (%a0)
> addq.l #2,%a7
> adda.l #0x40000,%a0
> jsr (%a0)
> nop;nop;nop |pour RETURN_VALUE
> C'est tout bête.
Et tu obtiendras une belle barre noire en haut
Sur HW1 et sur HW2

>Montre-moi des saletés dans les programmes TICT alors.
Le patch pour faire communiquer tictex / tictexpl

>Pourquoi? Le code de démarrage de TIGCC est prévu pour fonctionner indépendemment de ce que fait le programme principal.
Mais un patch peut devoir faire autre chose.

>C'est trop tard. Il y a déjà des programmes qui les utilisent (de la manière prévue). Duke68k et CalcRogue par exemple.
On se demande comment ils font. Moi meme en y mettant du mien, j'ai du mal a remplir 64K de code pur.

>Bon, on remplace "100%" par "99%".
Ok.

>Mais il est très improbable que les versions futures de AMS exporteront moins de fonctions.
>Ce n'est pas du tout dans la logique de TI.
>Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en retirent pas.
Hum. Tu te contredis. "Ils en ont retires".

>Ils ont quand-même un minimum de souci de compatibilité, même si on les accuse souvent du
>contraire.
Ah. Ou ca ? Certains ingenieur peut etre.

>Ah, je vois (c'est dans le ZIP de Pedrom que tu m'as envoyé pour le problème avec A68k ). Il y a pas mal de trucs qui pourraient nous intéresser (pour la documentation de TIGCC) dans ton Note.txt.
C'est fait pour

>Mais il y a certainement un moyen de définir un menu CUSTOM en C.
push_parse_text("custom:text ....");
HS_popESTACK / NG_execute
me semble le meilleur moyen.

>Plus simple? C'est plus simple de lancer un NG_execute avec des tags qu'un simple cmd_custmon???
Tu connais le format ?

>C'est certainement plus lent! NG_execute doit interpréter les tokens, puis exécuter le bon cmd_.... Il est certainement plus rapide d'appeler cmd_... directement.
A condition de connaitre le format !

>Et alors?
prions pour qu'ils ne recompilent pas printf.c

>Certes. Mais je parlais de ce que ça apporterait comme fonctionnalité à un programme, pas ce que ça apporterait pour une librairie standard pour faciliter les portages.
Tu l'as dit toi meme: faciliter les portages.

>TI-Connect n'est pas juste une surcouche du logiciel GraphLink. Par exemple, il supporte les câbles USB, ce qui n'est pas le cas du logiciel GraphLink.
J'ai essaye. Je n'ai vu qu'une surcouche de graphlink.
Faudrait essayer ces chaines la.

>1. Je me demande bien comment tu veux faire cet "émulateur". Il faudra changer le code du programme de partout, et pour l'écran, les changements ne sont pas automatisables à mon avis.
Cf au dessus.

>Nos #defines de compat.h sont tout aussi faciles à changer. De même si le programme lui-même utilise la même technique (#define CONST1 (TI89?1:2)).
Plus lourd. Plus lent.

>2. Cet "émulateur" marcherait exactement de la même manière en _nostub.
Pas de maniere automatique ni transparente

>Tu utilises quoi alors? Notepad???
>TIGCC IDE est très pratique, même si tu programmes en assembleur!
Ultra Edit pour tout et n'importe quoi (C, HTML, JAVA, ASM, C++, ..) avec pleins de compilos differents.

>Moi, j'aime bien, c'est la syntaxe GNU. Crois moi, on arrive très bien à s'y habituer.
C'est plus lourd. Ca obblige a taper un caractere sup par registre.
Bref on voit bien qu'ils programment pas en asm.

>Mais personne ne t'empêche de continuer à utiliser A68k ou d'utiliser le flag --register-prefix-optional de GNU as.
Je ne me gene pas.

>Mais BitmapPut de AMS l'est! Et c'était ça, le contexte. Je ne vois pas du tout ce que vient y faire ExtGraph (à part que tu as recopié le code de ExtGraph pour implémenter BitmapPut ).
Parce que justement je l'ai prise de la

>Réponse floue. Qu'est-ce qui est impossible exactement? D'allouer un bloc de plus de 65520 octets?
Oui. A la fois dans genalib (65520-8 si mes souvenirs sont bons) et avec malloc.

>genalib gère-t'elle ça de manière transparente?
Oui y'a genaAddBlock(void *start, void *end);

>C'est justement ça ton erreur, à mon avis.
Tu veux donc un exemple ou c'est impossible de faire autrement ?

>Tu peux essayer de les envoyer à XDanger. Il peut aussi faire des mises à jour des logiciels TICT si c'est vraiment important.
Ce n'etait pas important. Quelques details. Et puis ca l'obblige a refaire appel aux traducteurs

>Je ne vois pas en quoi ma solution (rajouter un nouveau RAM_CALL pour font_medium,
>changer font_small et font_large, et garder _RAM_CALL_00E pour les fontes du boot)
>causerait des problèmes de compatibilité. Mais bon, tu fais ce que tu veux, de toute façon,
> je n'utilise aucun de ces RAM_CALLs. (Vive le _nostub! )
Parce que certains programmes les utilisent deja

>Ce que je dis est que le fait qu'il y a une mise à jour qui accélère les routines de prévue n'est pas une excuse valable pour ne pas créer une version statique.
Ce n'est en rien une excuse. C'est une fonctionnalite supplementaire.

>Si le programmeur a vraiment besoin de la vitesse supplémentaire apportée par la mise à jour, il recompilera/réassemblera/relinkera quand la librairie est mise à jour. Je n'ai pas du tout mis en question le fait que tu n'as pas le temps de sortir la mise à jour tout de suite.
Pourquoi n'en aurait-il pas besoin puisque dans le contexe ou elle doit etre utiliser y'a la notion de vitesse.

>Tu veux que je t'écrive la documentation pour toi? J'ai autre chose à faire.

>Bon, commence par expliquer qu'une des 2 tables (je ne sais plus laquelle - ces abbréviations sont du chinois pour quelqu'un qui n'a jamais programmé sur une console) est une table de décalages de lignes par octets (donc par pas de 8 pixels), et que l'autre est une table de décalages horizontaux par pixel. C'est surtout ça qui manque effroyablement dans la documentation.
Par "word."
Ok, je rajoute cela.

>TI-89/92+/V200.
>Les jeux avec FAT Engine ou d'autres techniques 3D tournent souvent autour des 10 FPS. Les jeux en 2D ont des framerates nettement plus élevés.
Ils sont plus interressants aussi.

>À peine, mais quand-même.
Restons raissonnable. On est pas a 3% pres.

>Le contexte, c'était des conseils à Uther Lightbringer pour comment il peut se passer des librairies qui nécessitent USE_KERNEL. J'ai donc dit qu'en appliquant ces conseils, USE_KERNEL n'est plus nécessaire. Toi, tu as prétendu le contraire. J'aimerais bien que tu m'expliques ton raisonnement...
De toute facon, avec toi, USE_KERNEL n'est jamais necessaire alors

>Il faudra m'expliquer pourquoi ça rame alors...
Ils sont doues les gars de chez Origin. Mais doue
Ils affichent come un bouef tous les sprites de la map, quelque soit ta position. Je ne vois que ca comme explication.

>Pour les recopier pour le BitmapPut de Pedrom?
Oué !

>Ben, je te signale que pour le scrolling de ExtGraph, il est très facile de comprendre comment il marche. Le système de plans est plus compliqué.
Oui. Mais tellement plus simple une fois assimile. Et plus rapide.

>Ben, alors, il suffit d'expliquer dans le lisezmoi comment on utilise ttstart.
Ou mettre un message d'explication dans le programme _nostub juste avant l'extraction du PPG.

>Non, parce que leur affichage n'a pas besoin de 100 ms tout simplement. Et cela indépendemment de la librairie graphique utilisée.
mais si ! Essaye de faire tourner Cf/SMA sous Extgraph alors !

>Quelle 3D? 3D isométrique? Dans ce cas, ce n'est pas vraiment de la 3D (ce sont juste des sprites avec un masque non-rectangulaire), et c'est normal que ça ne rame pas.
3D face pleine
En surcouche des maps (2 planes), et des sprites (30 spr 32x32 a l'ecran), plus les fenetres.

>Parce que les fonctionnalités ne sont pas identiques. On peut lancer le programme de manière plus directe avec le lanceur personnalisé.
Mais le format des Pack Archive permet de le lancer directement justement !

>D'ailleurs, il y a aussi AutoStart comme troisième solution. Ça permet de combiner lanceur commun et lancement direct. Le désavantage est qu'il y a un TSR à installer.
C'est à l'utilisateur de choisir entre les 3 méthodes, pas au programmeur.
Mais si !

>En quoi est-ce un problème? Les fonctions de gray.h sont simples à utiliser et efficace, donc pourquoi dupliquer l'effort en en mettant d'autres dans ExtGraph? D'autant plus que c'est Thomas qui a écrit les routines de TIGCCLIB. Il ne va pas faire de la concurrence à ses propres routines!
Ce n'est pas un probleme pour Extgraph, mais tu dois en tenir compte lorsque tu compares avec d'autres libs.

>Il manque quoi (à part les fonctions clippées, ça on le sait déjà)?
1. Les fonctions clippees
2. La generation du halo.
3. L'affichage de plane.
4. Les routines de link.
5. Gestion joypad.
6. Effets de lumiere.

>D'où l'intérêt de ne pas rajouter des fonctions compliquées et à intérêt doûteux (par exemple tes 2 fameuses "super tables") à sa librairie graphique.
C'est tres utile. Cf SMA Aquatic Ruins. C'est splendide comme effet !

>Toutes sortes de jeux ou autres programmes.
Mais pas des jeux d'actions.

>C'est la même chose.
Non.

>Seulement après avoir installé l'interpréteur du format (c'est-à-dire le kernel).
Parce qu'il y a pas d'autostart !
Faudrait que je fasse Preos en apps.

>Il fonctionne très bien! À part pour un programme avec des milliers de relogements (*ahem* CC *ahem*), évidemment.
Mais il est sous-optimal ! Toi qui deteste la place perdu, tu devrais t'en rendre compte !

>Elle ne convient pas très bien parce qu'elle n'existe qu'en dynamique.
Arg !

>Sauf que mes calculs ont pris des cas moyens, voire des cas qu'on croierait extrêmement favorisants pour les librairies dynamiques, mais qui en fait, calculs faits, ne l'étaient pas du tout.
Hein ? Ou ca ?

>Et ben, je dis que tu te trompes là. Vu la taille de genlib (autour de 16 KO) et vu la taille des routines utilisées d'habitude dans ExtGraph (autour de 2 KO: 1 KO pour les niveaux de gris de TIGCCLIB et 1 KO pour les fonctions de ExtGraph elle-même), il faut au moins 8 jeux avec genlib pour que le fait que genlib est une librairie dynamique soit rentable.
Tu oublies toutes les fonctions que l'on doit reecrire par soi meme car ca n'y est pas dans genlib. tu oublies la vitesse d'execution.

>Or, les jeux avec genlib ont généralement besoin de nettement plus de 655360/8=81920 octets d'archive en tout (cf. SMA, CF, ...), donc la solution de ExtGraph est meilleure. Et la compression n'y changera rien, vu qu'elle compresse genlib et ExtGraph de la même manière.
mais ca permet de mettre a jour genlib pour d'autres machines

>Tu utilises AutoStart si tu veux absolument lancer le programme par son nom seul sans utiliser de lanceur personnalisé. Il prend moins de place que PreOs même en rajoutant la taille de ttstart!
Et en ajoutant la taille de Kerno ?

>N'empêche que pas mal de ses fonctions sont inutiles pour la plupart des programmes qui l'utilisent. Attention, je ne dis pas qu'elles ne sont pas utiles pour certains programmes, mais juste qu'elles traîneront inutilisées dans la plupart des cas parce que le principe des librairies dynamiques ne permet pas d'envoyer des fonctions au système de destination ("target", ici la calculatrice) de manière sélective.
Lesquelles sont inutilisees ?

>Si, elle est plus compliquée!
Montre le :
genaux_init(GENAUX_DBUFFER|GENAUX_SPR16_TABLE, spr16);
gen_put_sprite_16(16, 16, 0);
gen_wait_key();
genaux_quit();

>Il y en a eu nettement moins. Le mot "bug" apparaît 20 fois (dont 5 fois au pluriel) dans l'historique de genlib, et seulement 4 fois dans celle de ExtGraph.
Ce n'est absolument pas le meme degre de complexite.

>Mais non. Si la différence de vitesse est négligeable, elle est négligeable!
Elle n'est pas negligeable !

>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.
Mais ca fonctionne !

>Dans le Mario à 1 fps, on avance par pas de 5 ou 10 pixels quand on court.
... meme fer3 v3.20 va plus vite que 1 fps.

>Et évidemment qu'un Mario à 1 fps n'est pas comparable à un SMA. Mais un Mario à 10 fps l'est tout à fait!
Mario et Sonic sont INCOMPARABLES !

>si on laisse les programmeurs programmer en mode kernel, on empêche aux utilisateurs de ne pas utiliser de kernel.
Si on laisse les programmeurs programmer seulement pour AMS, on empêche les utilisateurs de ne pas utiliser AMS.

>ma foi, je trouve le switch pr le supprimer très utile
>Dès que je dl une nouvelle version de preOS, je supprime le switch pr HW2tsr, le switch qui permet de supporter les HW2, le switch pr afficher les boites de dialogues à la fin de l'installation... Et je recompile.
>Comme ça, preOS ne contient que ce dont j'ai besoin : il prend moins de place, et j'ai pas de crise de nerfs avec 36 boites de dialogue
(d'ailleurs, PpHd, merci pr ces swithc )
C'est fait pour.
Mais tu auras bientot de nouveaux switchs a ta disposition.
Entre autre, ERASE_UNCERTIFIED_LIB.

>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.
CODE EN MODE KERNEL ALORS !

>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 compiles en Pack Archive, tu crees une lib "ttpack", et c'est bon.
Sinon tu as autostart.

>la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs
C'est pas qu'un polygone. Y'en a 16 je crois.

>ça me rappelle une bonne série d'engueulades voila quelques temps...
Qui a dessassembler le code de JM pour obtenir ces routines ?

Je n'ai pas le temps de répondre à tout là, mais:

PpHd a écrit :
>Tu importes le code pour EXECUTE_IN_GHOST_SPACE (un seul xdef), et tu fais:
> move.w %d0,-(%a7)
> move.l HeapDeref*4(%a5),%a0
> jsr (%a0)
> addq.l #2,%a7
> adda.l #0x40000,%a0
> jsr (%a0)
> nop;nop;nop |pour RETURN_VALUE
> C'est tout bête.
Et tu obtiendras une belle barre noire en haut
Sur HW1 et sur HW2

Arf, m*rde, il manque l'appel à EM_twinSymFromExtMem. Je ne connais pas suffisamment kernel::exec pour savoir ce qu'il fait et ce qu'il ne fait pas, donc je ne savais pas (ou alors j'ai tout simplement oublié) qu'on pouvait lui passer directement le fichier archivé.

/me cite PpHd, 283

>Mais ça prend encore plus de place! genlib en prend déjà trop toute seule! Compressee, elle ne prend pas tant de place

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

>Mais un appel de fonction est quand-même une ligne logique. C'est un concept certifie ?

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 plus rapide que de tout réafficher à chaque fois. Faux

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é

>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. Certes, mais les routines de genlib sont optimises pour

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 )

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

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)

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

PreOS a une autre fonctionnalité par rapport à kerNO

>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! il en est hors de questions !

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é !

(en parlant de ce que K gagnerai à être en kernel et non pas nostub)
Taille, mon respect. Ca tournerait sur ma calc

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)

/me cite PpHd, 284

C'est surtout qu'AMS n'est pas optimise en taille. En moins de 64K, 350 fonctions d'AMS. Tu trouves ca normal ?

Je trouve que c qd même mieux que AMS
cela dit, pour ces mêmes 350 fonctions, combien de place prend AMS ?
Tu aurai pas envie d'essayer de proposer tes versions à TI ?
Je pense pas qu'il les intégreraient à la prochaine ROM... mais ils verraient peut-être que la commauté est pas movaise à

côté d'eux

>Il y a pas mal de gens qui disent que les kernels sont complètement obsolètes là-bas. Ils disent des conneries c'est tout

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

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

>Ils ont retiré quelques fonctions isolées (une douzaine), mais en général, ils rajoutent des fonctions, ils n'en

retirent pas. Hum. Tu te contredis. "Ils en ont retires".

/me cite PpHd, 285

>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. Mais ca fonctionne !

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)

(en parlant des switch de Preos )C'est fait pour.

c'est pour ça que je les utilises
Je sais pas si bcp de monde passe du temps à lire le début de la source pour savoir quoi mettre ou quoi ne pas mettre, de

même que je ne sais pas si bcp de gens sont prêt à recompiler le kernel plutôt que d'utiliser la version fournie en

standard... Mais, en tout cas, je trouve ces switch bien utiles

Mais tu auras bientot de nouveaux switchs a ta disposition. Entre autre, ERASE_UNCERTIFIED_LIB

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 )

>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. CODE EN MODE KERNEL ALORS !

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

>la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs C'est pas qu'un polygone. Y'en a 16 je crois

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

>ça me rappelle une bonne série d'engueulades voila quelques temps... Qui a dessassembler le code de JM pour obtenir ces routines ?

je vois que nous pensons à la même chose

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.

Je parlait bien évidement de Unix, Linux... sous windows il y a presque autant d'interet que sur TI mais sous Linux, j'aurais du mal a m'en passer

On est d'accord, pour une fois.

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

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

La routine de AMS est clippée!

autant pour moi, dans ce cas la en effet ca peut-être génant.

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

certes mais il y gagnerai tous le avantage du kernel, et s'il avait été réalisé avec genlib il y aurait gagné en taille

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.

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 et qui sont apparues alors qu'il existe un concept de lib dynamique reconnu et qui a fait ces preuves sur TI.

Moi, je compile tout en -Os pour TIGCC et ça marche très bien.

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

"Programmer en ASM" et "utiliser tigcc.a" ne sont pas incompatibles.

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

Avec des erreurs. Cf. flag V200.

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

GCC est assez lourd en effet, mais y a-t'il des compilateurs légers avec des fonctionnalités comparables? Il ne me semble pas.

pas pour le moment mais ca ne devrait plus trop tarder

Évidemment, si on retire toutes les fonctionnalités intéressantes de AMS, on a la place.

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

Tu n'es pas souvent passé sur le forum de la TICT et sur celui de TI apparemment. Il y a pas mal de gens qui disent que les kernels sont complètement obsolètes là-bas.

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

Ben, les bogues qui empêchent aux jeux en question de s'appeler "version 1.00".

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

Tu importes le code pour EXECUTE_IN_GHOST_SPACE (un seul xdef), et tu fais:
move.w %d0,-(%a7)
move.l HeapDeref*4(%a5),%a0
jsr (%a0)
addq.l #2,%a7
adda.l #0x40000,%a0
jsr (%a0)
nop;nop;nop |pour RETURN_VALUE
C'est tout bête.

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

Certes. Mais je parlais de ce que ça apporterait comme fonctionnalité à un programme, pas ce que ça apporterait pour une librairie standard pour faciliter les portages.

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

Tu utilises quoi alors? Notepad??? TIGCC IDE est très pratique, même si tu programmes en assembleur!

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

>J'aime pas ces %
Moi, j'aime bien, c'est la syntaxe GNU. Crois moi, on arrive très bien à s'y habituer.
Mais personne ne t'empêche de continuer à utiliser A68k ou d'utiliser le flag --register-prefix-optional de GNU as.

J'aurais préféré que le % soit devant le nom des variables, mais bon il faut reconnaitre que c'est pas la mort.

C'est peut-être du "fun", mais ça ne change rien au fait que c'est lent.

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?

Je pense qu'on n'ira pas plus loin sans arguments et en ayant un peu perdu le contexte. Le contexte, c'était des conseils à Uther Lightbringer pour comment il peut se passer des librairies qui nécessitent USE_KERNEL. J'ai donc dit qu'en appliquant ces conseils, USE_KERNEL n'est plus nécessaire. Toi, tu as prétendu le contraire. J'aimerais bien que tu m'expliques ton raisonnement...

Le contexte c'est que j'utilise des RAM_CALL, des libs dynamique dont je n'ai pas l'intertion de me passer(a part filelib) et que je veux que s'il y a une mise a jour, je ne soit pas forcement obligé de recompiler, et je veux utiliser kpack que je trouve plus pratique que ttpack.
[cite]Ben, je te signale que pour le scrolling de ExtGraph, il est très facile de comprendre comment il marche. Le système de plans est plus compliqué.[cite]
Franchement je ne touve rien de compliqué dans le système des plan! Je le trouve au contraire très facile et pratique.

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

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

/me a pas le temps de répondre au reste(peut être plus tard)

/me cite pphd:
[edit]>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.
Certes, mais les routines de genlib sont optimises pour[/edit]

Tout comme XLib
d'ailleur meme sans fonction specialisée de plan X> gen SAUF pour le 8² ou la gen> X.

>Désolé mais genlib me convient très bien. Elle ne convient pas très bien parce qu'elle n'existe qu'en dynamique.

J'ai mis genlib me convient très bien et non te convient très bien

Mais ttpack compresse mieux que les librairies utilisables pour les packs archive de PreOs.

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

Et ben, je dis que tu te trompes là. Vu la taille de genlib (autour de 16 KO) et vu la taille des routines utilisées d'habitude dans ExtGraph (autour de 2 KO: 1 KO pour les niveaux de gris de TIGCCLIB et 1 KO pour les fonctions de ExtGraph elle-même), il faut au moins 8 jeux avec genlib pour que le fait que genlib est une librairie dynamique soit rentable. Or, les jeux avec genlib ont généralement besoin de nettement plus de 655360/8=81920 octets d'archive en tout (cf. SMA, CF, ...), donc la solution de ExtGraph est meilleure. Et la compression n'y changera rien, vu qu'elle compresse genlib et ExtGraph de la même manière.

il n'y a pas que genlib: il y a aussi graphlib, ziplib,...

Tu utilises AutoStart si tu veux absolument lancer le programme par son nom seul sans utiliser de lanceur personnalisé. Il prend moins de place que PreOs même en rajoutant la taille de ttstart!

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

N'empêche que pas mal de ses fonctions sont inutiles pour la plupart des programmes qui l'utilisent. Attention, je ne dis pas qu'elles ne sont pas utiles pour certains programmes, mais juste qu'elles traîneront inutilisées dans la plupart des cas parce que le principe des librairies dynamiques ne permet pas d'envoyer des fonctions au système de destination ("target", ici la calculatrice) de manière sélective.

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

Si, elle est plus compliquée!

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

Ce ne sera qu'un compromis, et ce sera très loin d'une solution idéale. La solution idéale, c'est le linkage statique: la librairie peut offrir toutes les fonctions qu'elle veut, et le "programme client" choisit uniquement celles qui l'intéressent.

le linkage statique pose d'autres inconvéniants!

Je ne vois pas en quoi c'est plus dur pour eux d'aller télécharger un décompresseur de .tar.bz2 que d'aller décompresseur de ZIPs. D'autant plus que les décompresseurs ZIP les plus utilisés (WinZIP et compagnie) comprennent aussi les tar.bz2.

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.

Dans le Mario à 1 fps, on avance par pas de 5 ou 10 pixels quand on court. Et évidemment qu'un Mario à 1 fps n'est pas comparable à un SMA. Mais un Mario à 10 fps l'est tout à fait!

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

PreOS a une autre fonctionnalité par rapport à kerNO

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

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)

Tu en gagnera au moins 2
Non je prendrai Krypton même s'il ne sort qu'en nostub(même si je préfèrerai en kernel).

Mais tu auras bientot de nouveaux switchs a ta disposition. Entre autre, ERASE_UNCERTIFIED_LIB

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

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

Bonne idée!

TiMad
a écrit : d'ailleur meme sans fonction specialisée de plan X> gen SAUF pour le 8² ou la gen> X.

Cool des débats imbriqués dans un même topic
Espérons que Pphd va marcher...

attaquer sur 2 front à la fois, ça va être dur

attend moi je fait un bench quand tu veux

Hé Kevin, ne fait pas semblant de ne pas avoir vu ça

Je n'ai pas encore répondu au dernier paquet de posts tout simplement, faute de temps.

Mais bon, on va répondre tout de suite à ton petit message pour que tu arrêtes de te plaindre:

Thibaut a écrit :
Et hop ! topics/2-19542-sources-side-et-as#28 Voilà un avantage du mode kernel
La version kernel de CC prend 8,7 ko de moins que la version nostub !!!

CC est un cas bien particulier. Il utilise des milliers de relogements! C'est vraiment très loin du cas moyen.
Et puis, il y aura peut-être des relogements compacts à la mlink dans TIGCC 0.95 ou 0.96 pour les cas exceptionnels comme celui-là. Le code de relogement de mlink prend moins de place que le header et le stub du format kernel.

Haaa le kernel c'est vraiment bien comme format

Non, c'est un format inutilement compliqué.

Quand-est-ce que tu reconnaîtras qu'il a aussi des avantages ?

Question à ceux qui nous font des posts à rallonge. (c'est pour les archives TI-FR)


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)

vince> Kevin et PpHd te répondron... mais aucun de leurs posts ne sera objectif

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.