180

Ce n'est pas à partir de 10 fps qu'on ne distingue plus la différence de fluifité, mais plutôt 24.

181

Même si ce sont 24 (ce que je ne pense pas: Thomas Nussbaumer dit que ce sont 10, et il sait de quoi il parle vu qu'il est l'auteur de FAT Engine, PpHd dit que ce sont 12,5), ça ne change rien à l'idée (qu'on s'en fiche du nombre de FPS au-delà d'un certain nombre que pratiquement tous les jeux atteignent sans problèmes), et ça n'explique pas ce qu'a dit MacIntoc non plus.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

182

nan, ça dépend du support. Sur TV, c 24, au ciné c 25, sur PC, faut arriver à 40-50... ça dépend essentiellement de la netteter de l'image. Plus elle est nette, plus faut qu'il y est d'image par seconde. Et sur TI, c'est pas net du tous, donc y a pas tellement besoin d'avoir enormément d'ips, mais c toujours plus agréable d'avoir 80 ips que 10wink
avatar
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.

183

en tous cas, on peu pas eternellment sauter d'images, y a un moment ou ça passe plus.
avatar
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.

184

Mais ce "moment", ce sont les 10 FPS dont on parle.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

185

On reprend parce ca devient vraiment n'importe quoi.. on veux afficher 2 sprites maskés avec un VS:

XLib:
XOn() 
a=XNewGPlan(); 
XGPlanc(a); 
XGMSprite(1,1,blabla); 
XCpyGPlanToLCD();
XWait(Enter); 
XOff();


Extgraphlib:
if (!GrayOn()) 
 { 
   print(erreur ram less...);
   ngetchx();
   exit(0); 
 }

if(a=malloc(LCD_SIZE*2)
{
ClearGrayScreen();
GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
                  a,a+LCD_SIZE);
GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
                  a,a+LCD_SIZE);
memset(...);  // ouai ya ptetre un equivalent Extgraphlibn la n'est pas le prob
memset(...);
free(a);
ngetchx();
}
else
 printf(erreur ram less ...);

ngetchx();
GrayOff();


tout depend si on prog comme un porc ou pas.. mais normalement vu que Extgraphlib n'as pas de gestion de ram .. bein ca devient beaucoup plus complex....
De plus rien que la syntax de la foncton maské me fait peur tellement elle est lourde!!!
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!

186

As-tu une bonne raison d'utiliser USE_KERNEL? Parce qu'en principe, tout ce qui est possible avec TIGCCLIB en mode kernel est aussi possible en mode _nostub?

Qu'est ce qui te fais croire que je n'utilise que TIGCCLIB
Tu risques de perdre ton pari. Les bogues corrigés sont beaucoup plus nombreux que ceux qu'il nous arrive de rajouter en rajoutant des nouvelles fonctionnalités. Beaucoup de bogues reportés récemment sont en fait de vieux bogues qui sont juste passés inobservés. Et puis, les bogues nouveaux ne concernent pratiquement toujours que des fonctionnalités nouvelles.

On vera bien mais vu que les dernière versions de TIGCC étaient relatiment peu boggées et que apparament vous avez changé pas mal de truc, ca me semble probable que le nombre de bug augmentent
Ben, il suffirait d'envoyer des cease-and-desist menaçant une action légale, parce que ça serait illégal.

Si tu veut t'embeter avec ca bon courage.
Et puis je vois pas pourquoi il faudrait contraindre le programmeur
Pourrais-tu expliciter ton cas? Ça apporterait bien plus au débat si c'était explicité d'une manière qui nous permet de comprendre pourquoi c'est le cas.

Je vais pas détailler comment j'ai fait mon programme c'est hors sujet mais dans mon cas l'écran vitruel plus grand que l'écran de la TI est très pratique.
Ben, tant mieux pour eux s'ils peuvent lancer le programme sans se casser la tête! Ce que tu présentes comme un inconvénient est en fait un avantage! Trouves-tu vraiment qu'il faut forcer les utilisateurs à économiser de la place sur leur calculatrice??? Moi, je ne trouve pas ça du tout!
Ben, tant mieux pour eux s'ils peuvent lancer le programme sans se casser la tête! Ce que tu présentes comme un inconvénient est en fait un avantage! Trouves-tu vraiment qu'il faut forcer les utilisateurs à économiser de la place sur leur calculatrice??? Moi, je ne trouve pas ça du tout!

Il ne savent pas qu'il perdent de la place c'est tout. C'est ce qui arrive a force d'assister les utilisateurs.
Mais quand on est dans l'ordre de grandeur des millisecondes (et plus des microsecondes), on a déjà fait la somme!

Tout dépends de la complexité de ton jeu
Si, genlib et ExtGraph+gray.h sont utilisées dans exactement les mêmes conditions: quand on a besoin d'une librairie pour l'affichage graphique.

Bien! Pourquoi pas conseiller genlib pour réaliser un shell aussi! Genlib est fait pour les jeux demandant de la puissance(d'ailleurs il gère bien plus de choses que les graphismes) alors qu'extragraph+gray.h s'utilisent de facon plus généraliste et uniquement pour les graphismes.
avatar

187

Kevin Kofler a écrit :
Même si ce sont 24 (ce que je ne pense pas: Thomas Nussbaumer dit que ce sont 10, et il sait de quoi il parle vu qu'il est l'auteur de FAT Engine, PpHd dit que ce sont 12,5), ça ne change rien à l'idée (qu'on s'en fiche du nombre de FPS au-delà d'un certain nombre que pratiquement tous les jeux atteignent sans problèmes), et ça n'explique pas ce qu'a dit MacIntoc non plus.


Ben moi, j'avais fait un test sur real TI et on remaquait quand même une différence de fluidité entre 10 et 20 fps au-delà de 20, ça devenait plus difficile.
Mais le fait d'accélérer les fonctions ne permet pas forcément que d'augmenter le fps, il peut servir à laisser plus de temps au CPU pour calculer des trucs (genre dans un moteur 3D, il n'y a pas énormément de trucs à afficher (s'il n'est pas texturé), mais c'est quand même nettement mieux d'accélérer au maximum l'affichage pour compenser le temps que mettent les calculs.

188

Kevin> tu devrais essayer de faire toi-même un jeu en temps réel demandant une grande puissance d'affichage pour te rendre compte que tout n'est pas aussi simple que tu sembles le croire. Après tu comprendra peut-être ce que 4 cycles processeurs peuvent chnager dans une routine de sprites, ou pourquoi utiliser des écrans virtuels plus grands que l'écran.
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

189

Kevin > Les TI-89/92+/V200 ne sont pas une bonne plateforme "host" (par opposition à "target") pour le développement en C.
N'oublie pas qu'il y a une version sur PC de GTC.
La version on-calc est théoriquement là pour servir à continuer son programme aux moments on n'a pas accès à son PC.

> Non. Il y aura bientôt un compilateur sérieux. TIGCC est un compilo TRES sérieux
>> rotfl
Pourquoi rire ? Qu'est-ce qui est faux ?
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

190

au fait XLib etait deja juste en 3DIso.. alors extgraphlib c'est pas la peine d'y penser...
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!

191

Kevin Kofler
a écrit : Mais ce "moment", ce sont les 10 FPS dont on parle.

Nan, pasque sur GBS, les éléments ne vont pas à la même vitesse (les balles, par exemple). S'il commence à virer des frames, les balles, on les verras plus partir.
avatar
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.

192

>De toute façon, il restera au moins pour la version 0.95, et probablement encore beaucoup plus longtemps. (Maintenant qu'il est supporté par le nouveau linker, on n'a plus vraiment de raison de le supprimer.)
Je te fais confiance pour trouver des raisons de le supprimer. Je ne m'inquietes pas a ce sujet.

>Si tu veux garder tous les bogues, tant pis pour toi.
Dans le pire des cas, on change de compilateur.
Ou on modifie tigcclib pour que ca marche (vive la licence GPL !)

>Je me demande si on ne devrait pas mettre TIGCCLIB sous LGPL. Ça obligerait les programmeurs de faire en sorte qu'on puisse recompiler/relinker le programme pour mettre à jour TIGCCLIB, c'est-à-dire de distribuer soit les sources, soit les fichiers objet (*.o). Comme ça, le problème de la disparition des programmeurs serait règlé.
Encore une raison pour garder les anciennes versions !

>Le problème est que pour que la mise à jour avec les fichiers .o seuls soit vraiment effective, il faudrait remplacer nos macros par des fonctions, et ça pessimiserait pas mal le code. Ce problème concerne d'ailleurs aussi les librairies dynamiques. Il n'y a pas mal de macros dans les headers de genlib (même dans le header assembleur).
Ils n'ont qu'a distribuer les sources, voyons, c'est si simple !

>Et c'est la faute des programmeurs s'ils ne distribuent ni leurs sources ni leurs fichiers objet. Ce n'est pas la faute du système des librairies statiques, mais du fait que les programmeurs ne s'y adaptent pas.
Lol. Moi je vous conseilles de programmer avec des libs dynamiques kernels. Au moins y'a pas ce probleme.

>C'est le plus souvent le cas pour ceux qui trouvent ça plus pratique et qui s'en fichent de la consommation d'archive. Mais dans ce cas, c'est leur problème, et il ne faut pas compter ça dans le décompte de la taille (vu que ce n'est pas nécessaire pour utiliser le programme).
Mais alors pourquoi tu en tiens compte dans tes calculs ?

>Même dans un jeu de plateau, on n'est pas à 1 ms près. Si ton Mario ou Sonic met 1 ms de plus pour un saut, personne ne le remarquera.
S'il y a 20 ennemies a l'ecran et que les 20 sautent, ca fait 20ms, et ca, ca se remarque (a 20 fps, ca fait 400ms par seconde).

>Et d'ailleurs même un jeu de plateforme très lent, par exemple un Mario en BASIC, peut être jouable. (J'ai essayé personnellement.)
Certes. Mais ?

>- est due à la suppression de OSVRegisterTimer et OSVFreeTimer par AMS
Y'a en d'autres qui ont disparus !!

>- concerne aussi le mode kernel. Les kernels n'ont rien fait pour résoudre ce problème. Cette histoire de "il suffit de mettre à jour le kernel" est un mensonge courant, mais quand-même un mensonge. C'est très loin de la réalité.
Si tu veux je peux le resoudre, mais c'est inutile car je n'ai pas eu le temps de le faire.
Alors que faire ? Laisse comme c'est oué.
Mais le kernel aurait pu faire cela sans probleme !

>- peut être résolue par une simple recompilation sans aucun changement des sources
Y'a le mot recompilation qui me gene.

>Parce que tu penses qu'en optimisant en taille, on pert une milliseconde entière par frame? On est plutôt dans l'ordre de grandeur de quelques microsecondes par frame.
Oué on peut arriver en optimisant vraiment en taille a ca !

>CounterStrike n'est pas un jeu de plateau. C'est un jeu multijoueur où le temps de réaction compte beaucoup. C'est totalement différent.
Un mario/sonic est beaucoup plus qu'un simple jeu de plateaux.

>Et puis, pour n'importe quel jeu, au-delà d'une dizaine ou au maximum une vingtaine de FPS (au-delà de 10 FPS selon Thomas Nussbaumer), plus personne ne remarque la différence.
Ca depend si le jeu a ete concu pour fonctionner a ce frame rate. Aucun jeu d'action a l'heure actuelle n'est prevu pour (il ne faut pas fournir des images statiques, mais des images dynamiques en pretraitant l'integration des photons par l'oeil).

>On ne dirait pas en te lisant.
Tu veux que je sortes le programme interdisant l'emploi des nostub ?

>Peut-être, mais genlib prend plus de 2 fois plus de place que les fonctions de TIGCCLIB (gray.h) et ExtGraph utilisées habituellement.
Peut-être, mais genlib offre largement plus de 2 fois le nombre de fonctions offertes par gray.h et extgraph.

>Au lieu de mettre un pointeur en auto-modifiant, tu le prélèves dans un paramètre comme le fait ExtGraph. Ce n'est pratiquement pas plus lent. Et ça donne du code plus petit dans ta librairie
Pushe ce parametre, le lire, est lent. Beaucoup trop lent pour moi, desole.

>Mais une simple optimisation de taille ne fera certainement pas perdre 1 ms par unité graphique.
Si !
Compare donc Les routines de sprites de tigcclib a celles d'extgraph !

>Tu fais trop de calculs de vitesse dans un ordre de grandeur qui est de toute façon négligeable. Déjà, tes 5% sont très probablement une surestimation, et puis on n'est pas à 5% près.
5% est la marge a partir de laquelle le gain est plus que le bienvenu.
En dessous, ca peut se discuter.

>Moi oui, mais pas tout le monde qui utilise un anti-crash.
Mais ca n'empeche pas que ca solution d'afficher un message n'est pas terrible !
En plus, ca ne marche que sur AMS 2.0x

>Je suis sûr que Greg Dietsche accepte les conseils d'amélioration. Maile-lui.
Je n'en ai aucun pour le moment.

>Non. Ce que tu toi, tu appelles "flexible" est tout simplement lourd. J'ai déjà dit dans ce topic pourquoi le format kernel est en fait moins flexible que le format _nostub.
Moins flexible ? Pourquoi faut-il patcher les executables pour qu'il marche sur V200 alors ? Tu appelles ca de la flexbilite ?

>On peut aussi intercepter les appels à un programme _nostub. Il suffit de modifier un peu le hook du trap #11 de h220xTSR. Tu peux même rajouter un "trampoline" en changeant quelques adresses, ce qui te permet de détecter aussi quand le programme a fini l'exécution.
Ca ne marche pas sur AMS 1.0x !

>Mais c'est un hack. Si un programme non-TSR installe un TSR, c'est un hack. C'est même un leak de mémoire.
Mais c'est AUTONOME ! Gagne !

>Je répète: Si tu n'aimes pas, personne ne t'empêche de n'utiliser que ttstart ou TICTEX. Si d'autres utilisateurs préfèrent l'autre solution, c'est leur problème, et tu n'as pas à t'en mêler. Les programmes compressés avec ExePack permettent à l'utilisateur de choisir la solution qu'il préfère.
Et avec les pack archive, au moins il n'y a pas ce probleme. C'est bien de centraliser les problemes.

>Désolé, je n'ai pas compris ta question là.
Normal, elle etait incomprehensible.
Certains utilisateurs demandent de l'aide avant meme d'essayer le programme. C'etait le point ou je voulais te faire venir.

>Le mien est qu'il est tout simplement impossible d'"éduquer" les utilisateurs, et qu'un programme doit prévoir toutes les c*nneries qu'un utilisateur pourrait faire.
C'est strictement impossible ! Un utilisateur pourra toujours faire des conneries !
'J'ai fait delvar tictex. Tictex marche plus, c'est normal monsieur ?'

>Un programme bien utilisable est un programme qui peut être utilisé même par le pire des idiots.
Et bien bon courage. Le pire des idiots ne saura meme pas allumer la machine.
D'ailleurs il n'aura aucun interet dans le programme.

>Ils n'ont pas leur archive pleine à 95% ou plus normalement.
J'ai des doutes... Sondage ?

>Les TI-89/92+/V200 ne sont pas une bonne plateforme "host" (par opposition à "target") pour le développement en C.
Il ne tient qu'a nous d'en faire une bonne plate forme !

>Mais c'est tout dans l'autre sens que dans celui duquel je parle.
Et y'a aussi kernel::exec qui est incompatible. Ou la facon d'acceder aux repertoire home/main.

>Ce n'est pas une émulation, mais de la compatibilité antérieure, parce que c'est le même format.
Je m'embrouille. Tu parles de compatibilite anterieure avec les precentes versions d'AMS. Mais c'est faux. Exemple : mon programme d'install de cf peut planter sur les nouvelles versions d'ams.

>Windows 3.1 est un OS complet implémenté par dessus un autre OS. La différence entre Windows 3.1 et le format kernel est qu'un programme Windows 3.1 n'appelle (normalement) pas les appels DOS alors qu'un programme kernel TI-89/92+/V200 appelle les ROM_CALLs de AMS.
Hein ? C'est totalement faux. Ne serait-ce que pour le systeme de fichiers.

>Ben, PlusShell et les premières bêtas de DoorsOS sont quand-même les premiers kernels, et donc la motivation derrière ces 2 kernels est la motivation derrière le système de kernels en général.
Et les Pack Archive ? C'est compatibilite fargo encore ?

>Ce sont des ajouts d'ordre mineur. Ça ne change rien à l'idée de base derrière le format.
Ce format est tres different de celui de fargo (rom_calls, ram_calls <rappel fargo n'a ni romcall, ni ramcall mais deux libraries 'tios' et 'kernel', exit, exportation des fonctions de programmes, multi-linkages de libs, etc).

>Solution: corriger les bogues. Les versions 1.00 des logiciels de la TICT ne sont pas ultra-bogués. Je ne dis pas qu'il n'y a pas de bogues (un logiciel sans bogues est quelque chose de pas très réalisable en pratique), mais entre "aucun bogue" et "ultra-bogué", il y a une marge
Ca prend du temps de corriger les bogues et d'ajouter des features. Il faut laisser le temps a l'utilisateur de tester.

>Si seulement tout le monde faisait ça... Avec le nombre de flames en public qu'on a eu au sujet de bogues dans TIGCC 0.9x, on est très loin de ça.
Je vous ai deja enfonce pour un bogue ?

>En théorie oui, mais bonjour la taille de ton programme.
Pas forcement. Moins d'un mega je pense.

>Alors qu'un programme _nostub peut remplir toutes les fonctionnalités d'un programme kernel avec au maximum 5 KO de plus (parce que le kernel est un programme _nostub de 5 KO). Et ce qui rend le tout intéressant, c'est que normalement, un programme _nostub a besoin de nettement moins de 5 KO pour remplir lui-même les fonctionnalités offertes par le kernel.
Sauf tout ce qui touche a la partie TSR.

193

>Le mode _nostub n'est pas "imparfait" (certes, rien n'est vraiment parfait, mais le mode _nostub est très bien fait). Et pourrais-tu détailler "redondant"? Parce que je ne vois pas la redondance dans le format (sauf si tu parles de ce qui permet d'éviter le dérelogement - si c'est ça, il y a une raison, donc ce n'est pas une redondance).
Ca peut etre eviter en faisant comme ne kernel et en rajoutant juste une long contenant la valeur de la precedente relocation. Pour rereallouer un programme, il suffirait de faire une relocation de (nouvelle_valeur-ancienne_valeur) pour que ca marche smile

>1. TIGCC a toujours été codé en pensant au confort du programmeur qui l'utilisera.
Pour le programmeur nostub.

>2. Je ne vois pas le rapport entre "support du mode kernel" et "confort du programmeur".
C'est plus simple en kernel : moins de lignes de code, plus d'aisances.

>3. Ce n'est pas moi qu'il faut remercier pour le maintien du support pour le format kernel, mais Sebastian
Je le remercirai.

>Ben, si on oublie de déreloger.
Qui reloge ? Qui dereloge ? Le kernel ! Et preos a un systeme qui permet de passer outre les problemes d'oublis de derelogement.

>Pour les #defines mal tapés, je ne vois pas comment on devrait résoudre ce problème-là. Utiliser un #include n'est pas une bonne idée. Ça ralentit et alourdit la compilation et ça oblige à rajouter des headers supplémentaires, tout ça pour très peu de gains. Et puis, les headers de TIGCC suivent les conventions 8.3, donc execute_in_ghost_space.h est trop long.
Des pragmas ?

>Ce n'est pas possible pour la compatibilité avec les très vieux programmes, qui ne mettent aucun #define, mais des short _ti89; pour sélectionner les modèles.
Changer le nom de l'include principal alors ! Et garder tigcclib pour la compatibilite anterieure.

>Project / Build.
La belle affaire !

>Je ne trouve pas. Le problème n'existerait pas si Doors Explorer était codé correctement.
Tu connais un programme code correctement ?

>addstupc toto.89z inuse.bin. C'est très simple.
En theorie.

>Mais tu as quand-même "copié" SET_FILE_IN_USE_BIT.
C'est un BUG d'AMS ! Il fallait que je le corrige !

>Parce que ça le force à changer de kernel, ce qui est un travail supplémentaire qu'il n'est pas forcément capable de fournir.
grin LOL
J'imagine l'utilisateur terriblement epuise. Arg, je dois changer de kernel pour pouvoir jouer a ce programme. Arg, j'en suis fatigue a l'avance.
Faut pas deconner non plus wink

>Aucune des nouvelles fonctionnalités est suffisamment importante pour justifier l'effort de maintenance supplémentaire. Et puis, USE_KERNEL n'est supporté que pour permettre de compiler les vieux programmes qui l'utilisent. On ne compte pas y rajouter quoi que ce soit.
C'est bien pour ca que j'ai sorti un VRAI include pour faire du bon mode kernel.

>Tu es vraiment un égoïste. Je ne pensais pas que tu étais égoïste à ce point-là.
Et toi tu ne l'es pas ? Qui ne l'est pas ? Je plains celui qui n'est pas egoiste ! Il n'est pas fait pour vivre dans ce monde. Paix a son ame.

>Tu n'as pas compris ce que j'ai voulu dire. Le problème est le découpage automatique en morceaux de 64 KO. C'est ça la partie dure.
Pas tant que ca. Un simple algo (pas forcement optimum) pourra faire l'affaire. Apres tout tant pis si c'est en 3 ou 2 fichiers.

>Le problème est où?
Le manque de coherence dans le nom des romcalls d'un module a l'autre.
D'un surabondance de fonctions inutiles, et d'un manque de fonctions utiles.
push_internal_simplify par exemple.

>Les fonctions les plus importantes d'un runtime C sont toutes dans la ROM: malloc, free, sprintf, ...
fopen, printf, etc aussi, n'est ce pas ?
stdin, stdout, stderr, aussi n'est-il pas ?

>Les fonctions graphiques essentielles comme l'effaçage d'écran et le tracé de texte, de lignes et d'autres objets géométriques y sont aussi.
Ainsi que DrawTexturedPolygon n'est il pas ?

>Il y a très peu de fonctions qui manquent dans la ROM. À part les niveaux de gris, ce sont tous des trucs implémentables assez facilement en termes de ROM_CALLs, comme c'est fait dans tigcc.a. Et les niveaux de gris sont implémentés en un seul KO dans tigcc.a.
Question de points de vue.

>Il faut quand-même une infrastructure pour le linking sous demande (c'est-à-dire pour ne linker que les fichiers objets réellement utilisés).
Bof. Pas si dur. Il faut quand meme pas exagerer la difficulte.

>C'est un abus du format!!! Pourquoi utiliser des PRGM pour des programmes en assembleur???
Parce que les programmes PRGM peuvent faire plus de 24K et etre executes sans probleme.
PS: C'est vrai.

>Et TI-Connect ne transfèrera très probablement pas tes fichiers
On verra bien. Je pense que si.

>Nous aussi.
A recompiler tous les fichiers et programmes ?

>Ben, si tu es trop paresseux pour taper 4 lignes (ou une douzaine en ASM), on se demande pourquoi tu programmes.
En tout cas pas pour taper des lignes sans interet, auxquelles je peux me passer.

>Ça arrive si souvent qu'on arrête d'utiliser un fichier de données où on l'utilisait à un moment? Dans les rares cas où ça arrive, est-il vraiment si dur de retirer 4 lignes ou de les mettre sous #if 0 (ou ifne 0)???
Ca arrive. Et dans ce cas, il faut rechercher l'importation du fichier de donnees dans le code source.

>Tu appelles tes variables malib@1234, toi? Si c'est le cas, alors 5678(a3) est tout aussi clair.
Sauf que malib@1234 peut changer sans arret d'offset, mais pas 5678(a3).

>Les 12 registres sont là pour être utilisés.
Autant les utiliser pour autre chose. 12 registres c'est peu.

>Si on a implémenté une fonctionnalité et qu'on se rend compte que ce n'est pas une bonne idée, mais qu'on n'ose pas la supprimer pour des raisons de compatibilité, le minimum à faire est de déconseiller son utilisation, pas de la conseiller
Sauf que moi je conseille de les utiliser !

>On peut toujours exprimer ça en termes d'écrans de taille normale et de routines clippées.
Comment remplir un BackBuffer de taille 400x300 par exemple ?

>Mes solutions marchent toutes.
NON ! C'est loin d'etre aussi simple ! Reflechis-y bien !

>C'est un hack qui tourne autour du problème au lieu de le résoudre à sa base.
Un hack ? Ou ca ? eek
C'est tres propre et ca offre des fonctionnalites manquantes (Je dis bien que malloc n'est pas concu pour le meme usage que genalib__alloc).

>Ben, dans ce cas, c'est que les documentations sont insuffisantes. En d'autres mots, envoie ce que tu as trouvé à Doc@tigcc.ticalc.org (c'est Sebastian qui lit cette adresse) s'il te plaît.
Ce que j'ai trouve ? C'est en testant jusqu'a que ca marche !

>Ça nous fait encore plus de travail, pour quelque chose qui n'apporte aucune fonctionnalité nouvelle (compat.h de TIGCCLIB marche très bien comme c'est).
Qui ameliore une fonctionnalite passee. Ou est le probleme ? Pourquoi pire ?

>Ça n'apporte aucune fonctionnalité supplémentaire par rapport à (TI89?xx:xx).
Un code plus compact, plus rapide, plus petit.

>Ça ne fait qu'appeler _rowread
Avec un test a calculator. alors que joypad ne fait qu'un btst.

>Mais c'est une abbréviation valable pour dire "librairie dynamique".
Absolument pas ! Les DLL windows, c'est de la merde !
Je proteste ouvertement de cet abus de langage !

>Le terme "librairie" vient de "function library" ("bibliothèque de fonctions"). Un fichier de données n'est pas une librairie.
Ou est que tu as lu ca ?

>Au contraire, c'est très simple à faire. Il suffit de vérifier les octets de taille.
On pourra toujours passer outre.

>Ca n'est pas notre faute si des trucs sont breakés par TI...
Et puis, je voudrais t'y voir, toi, à updater tous ces programmes, avec aussi peu de temps...
d'ou l'interet du kernel !

>Pitoyable. Même nous, qui n'aimons pas le kernel, te faisons des suggestions (notamment pour l'amélioration de ces RAM_CALLs de fonts qui sont actuellement implémentés n'importe comment: très lent, pas sûr...)
1. On s'en fout de la vitesse de detection. On n'est pas a 1 ms pret.
2. Ca marche.
3. Ce sont les fonts du boot qui DOIVENT etre exportes.
4. J'ai deja propose des trucs mais personne ne m'ecoute.

>Ton code ExtGraph est mal écrit, soit par ignorance, soit exprès.
>Voilà l'équivalent ExtGraph de ton code XLib, codé correctement:
>>if (!GrayOn()) return;
>>ClearGrayScreen();
>>GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
>> GrayGetPlane(LIGHT_PLANE),GrayGetPlane(DARK_PLANE));
>>ngetchx();
>>GrayOff();
>C'est plus court. Seul l'appel GraySprite16_MASK est un peu plus long, mais c'est pour plus de flexibilité, et pour éviter de devoir faire l'équivalent de PortSet ou de XGPlanc.
Moi je compte 6 lignes pour les deux. Et si je compte le nbr de caractere, Xlib est plus petit.

>As-tu une bonne raison d'utiliser USE_KERNEL? Parce qu'en principe, tout ce qui est possible avec TIGCCLIB en mode kernel est aussi possible en mode _nostub?
A oui ?
Et un appel a genalib__0000(malloc(10000)); en nostub on fait comment ?

>Ben, il suffirait d'envoyer des cease-and-desist menaçant une action légale, parce que ça serait illégal.
Tu as les moyens de faire un proces ? C'est cher !

>Ben, tant mieux pour eux s'ils peuvent lancer le programme sans se casser la tête! Ce que tu présentes comme un inconvénient est en fait un avantage! Trouves-tu vraiment qu'il faut forcer les utilisateurs à économiser de la place sur leur calculatrice??? Moi, je ne trouve pas ça du tout!
Doit-on les forcer a rester ignorant ? Ne doit-on pas les eduquer ?


>Si, genlib et ExtGraph+gray.h sont utilisées dans exactement les mêmes conditions: quand on a besoin d'une librairie pour l'affichage graphique.
Equivalent de put_fgrd_dhz_plane en tigcclib/extgraph ?




194

Putain, plus je lis ca, plus j'a envie de prog en kernel!
"Scrutant profondément ces ténèbres, je me tins longtemps plein d'étonnement, de crainte, de doute..."
Edgar Allan Poe

195

>>Pitoyable. Même nous, qui n'aimons pas le kernel, te faisons des suggestions (notamment pour l'amélioration de ces RAM_CALLs de fonts qui sont actuellement implémentés n'importe comment: très lent, pas sûr...)
> 1. On s'en fout de la vitesse de detection. On n'est pas a 1 ms pret.
Ta version ne prend pas 1 ms...
> 2. Ca marche.
Non, pas sous AMS 2.xx si les fonts sont redéfinies...

> 3. Ce sont les fonts du boot qui DOIVENT etre exportes.
Pourquoi ?

> 4. J'ai deja propose des trucs mais personne ne m'ecoute.
Nous aussi, nous avons proposé des trucs, mais tu ne nous as pas répondu...

Tu ne respectes pas les autres, ne t'attends pas à être respecté... Dorénavant, je cesserai de ne pas être agressif envers toi...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

196

TiMad
a écrit : On reprend parce ca devient vraiment n'importe quoi.. on veux afficher 2 sprites maskés avec un VS:

Pourquoi utiliser un écran virtuel juste pour afficher 2 sprites?
if (!GrayOn()) 
 { 
   print(erreur ram less...);
   ngetchx();
   exit(0); 
 }

if(a=malloc(LCD_SIZE*2)
{
ClearGrayScreen();
GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
                  a,a+LCD_SIZE);
GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
                  a,a+LCD_SIZE);
memset(...);  // ouai ya ptetre un equivalent Extgraphlibn la n'est pas le prob
memset(...);
free(a);
ngetchx();
}
else
 printf(erreur ram less ...);

ngetchx();
GrayOff();

C'est quoi cette horreur? Non seulement, c'est écrit de manière excessivement longue, mais en plus tu affiches ton message d'erreur avant le GrayOff.

Voilà comment on fait ce que tu veux faire (mais pourquoi utiliser un écran virtuel pour 2 sprites???):
#define sprite(x,y,s,p) GraySprite16_MASK((x),(y),16,(s),(s)+16,(s)+32,(s)+32,(p),(void*)(p)+3840)
if (!GrayOn()) {e: ST_helpMsg("Not enough memory");return;}
void *a=malloc(7680);
if(!a) {GrayOff();goto e;}
ClearGrayScreen2B(a,a+3840);
sprite(1,1,blabla,a);
sprite(1,1,blabla,a);
FastCopyScreen(a,GrayGetPlane(DARK_PLANE));
FastCopyScreen(a+3840,GrayGetPlane(LIGHT_PLANE));
free(a);
ngetchx();
GrayOff();

Oui, c'est un peu long, mais c'est parce que tu utilises un écran virtuel pour rien.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

197

Uther Lightbringer
a écrit : Qu'est ce qui te fais croire que je n'utilise que TIGCCLIB

Tu utilises quoi d'autre. genlib? Elle est aussi disponible en pseudo-_nostub, donc pas besoin de USE_KERNEL pour ça.
On vera bien mais vu que les dernière versions de TIGCC étaient relatiment peu boggées et que apparament vous avez changé pas mal de truc, ca me semble probable que le nombre de bug augmentent

Tu ne t'imagines pas le nombre de bogues qu'on a corrigés dans la série des bêtas 0.94. Au moins une demi-douzaine par bêta en moyenne. Et il y a eu 22 bêtas.
Il ne savent pas qu'il perdent de la place c'est tout. C'est ce qui arrive a force d'assister les utilisateurs.

Ben, moi je le sais très bien, et je garde quand-même mes lanceurs personnalisés, même si j'utilise TICTEX la plupart du temps. Donc les gens qui utilisent les lanceurs personnalisés ne sont pas forcément des ignorants comme tu as l'air de le présupposer.
>Mais quand on est dans l'ordre de grandeur des millisecondes (et plus des microsecondes), on a déjà fait la somme! Tout dépends de la complexité de ton jeu

Certes, mais ça ne veut pas dire qu'on dépasse l'ordre de grandeur des millisecondes même dans un jeu complexe. Les optimisations classiques de la vitesse au détriment de la taille (déroulement de boucles, multiplication des routines pour traîter des cas différents, ...) n'apportent pratiquement jamais de différence que l'utilisateur puisse remarquer. Les optimisations vraiment efficaces sont celles qui simplifient les routines, et donc améliorent à la fois taille et vitesse.
Bien! Pourquoi pas conseiller genlib pour réaliser un shell aussi! Genlib est fait pour les jeux demandant de la puissance(d'ailleurs il gère bien plus de choses que les graphismes) alors qu'extragraph+gray.h s'utilisent de facon plus généraliste et uniquement pour les graphismes.

Ben oui, ExtGraph est plus flexible. Mais partout où on peut utiliser genlib, on peut aussi utiliser ExtGraph!
jackiechan a écrit :
Ben moi, j'avais fait un test sur real TI et on remaquait quand même une différence de fluidité entre 10 et 20 fps au-delà de 20, ça devenait plus difficile. Mais le fait d'accélérer les fonctions ne permet pas forcément que d'augmenter le fps, il peut servir à laisser plus de temps au CPU pour calculer des trucs (genre dans un moteur 3D, il n'y a pas énormément de trucs à afficher (s'il n'est pas texturé), mais c'est quand même nettement mieux d'accélérer au maximum l'affichage pour compenser le temps que mettent les calculs.

Il faudra m'expliquer quels sont ces "trucs" que tu veux calculer et qui mettent tellement de temps à être calculé. L'IA de Backgammon calcule pas mal de trucs (elle évalue tous les coups légaux), et pourtant la réponse est "instantanée". L'IA de TI-Chess calcule elle aussi pas mal de trucs même en L1 et pourtant la réponse en L1 est pratiquement instantanée. Et les IAs de jeux comme Backgammon ou TI-Chess ont nettement plus de trucs à calculer que les jeux en "temps réel".
Ximoon
a écrit : Kevin> tu devrais essayer de faire toi-même un jeu en temps réel demandant une grande puissance d'affichage pour te rendre compte que tout n'est pas aussi simple que tu sembles le croire. Après tu comprendra peut-être ce que 4 cycles processeurs peuvent chnager dans une routine de sprites, ou pourquoi utiliser des écrans virtuels plus grands que l'écran.

Si j'avais le temps, je voudrais bien essayer...

Mais en tout cas, les jeux de plateforme en "temps réel" avec ExtGraph, ça existe!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

198

PpHd a écrit :
>De toute façon, il restera au moins pour la version 0.95, et probablement encore beaucoup plus longtemps. (Maintenant qu'il est supporté par le nouveau linker, on n'a plus vraiment de raison de le supprimer.) Je te fais confiance pour trouver des raisons de le supprimer. Je ne m'inquietes pas a ce sujet.

Tu sais que je ne ferai jamais ça sans l'accord de Sebastian, et qu'il veut garder le support pour USE_KERNEL. Donc on le garde.
>Je me demande si on ne devrait pas mettre TIGCCLIB sous LGPL. Ça obligerait les programmeurs de faire en sorte qu'on puisse recompiler/relinker le programme pour mettre à jour TIGCCLIB, c'est-à-dire de distribuer soit les sources, soit les fichiers objet (*.o). Comme ça, le problème de la disparition des programmeurs serait règlé. Encore une raison pour garder les anciennes versions !

Je te signale que j'ai dit "Je me demande si on ne devrait pas". Pas "On va probablement...". Et en y pensant plus, je ne pense pas que ce soit une bonne idée en fin de compte. Déjà, je n'ai pas envie de perdre mon temps à faire respecter une telle licence, et je suis presque sûr que c'est exactement la même chose pour Sebastian et Zeljko, et puis la possibilité de mise à jour avec des fichiers .o est seulement théorique vu le nombre de macros dans TIGCCLIB. Donc poubelle. De toute façon, je ne compte pas mettre une licence plus restrictive sans demander l'avis de la communauté avant.

Et puis de toute façon, ce n'est pas de notre faute si les auteurs disparaissent sans laisser leurs sources.
>Le problème est que pour que la mise à jour avec les fichiers .o seuls soit vraiment effective, il faudrait remplacer nos macros par des fonctions, et ça pessimiserait pas mal le code. Ce problème concerne d'ailleurs aussi les librairies dynamiques. Il n'y a pas mal de macros dans les headers de genlib (même dans le header assembleur). Ils n'ont qu'a distribuer les sources, voyons, c'est si simple !

Je te signale que tu es passé totalement à côté de mon argument, qui est que les librairies dynamiques peuvent elles aussi avoir des problèmes de mise à jour si certaines fonctions sont codées sous forme de macros. Et genlib est dans ce cas-là.
>Et c'est la faute des programmeurs s'ils ne distribuent ni leurs sources ni leurs fichiers objet. Ce n'est pas la faute du système des librairies statiques, mais du fait que les programmeurs ne s'y adaptent pas. Lol. Moi je vous conseilles de programmer avec des libs dynamiques kernels. Au moins y'a pas ce probleme.

Cf ci-dessus.

Et je trouve quand-même que le minimum d'effort qu'on puisse attendre d'un programmeur, même s'il ne s'intéresse plus à la programmation sur calculatrices, est de faire Project/Build. S'il n'est pas prêt à faire ça, ni à laisser ses sources pour qu'un autre puisse le faire, c'est de l'égoïsme de la part de l'auteur. Ça n'a rien à voir avec le format de l'exécutable.
>C'est le plus souvent le cas pour ceux qui trouvent ça plus pratique et qui s'en fichent de la consommation d'archive. Mais dans ce cas, c'est leur problème, et il ne faut pas compter ça dans le décompte de la taille (vu que ce n'est pas nécessaire pour utiliser le programme). Mais alors pourquoi tu en tiens compte dans tes calculs ?

J'ai l'impression que tu m'as encore une fois mal compris. Je répète donc avec d'autres mots, que j'espère être plus clairs:
Je compte un seul lanceur quand je calcule la taille parce que je compte ce qui est nécessaire pour lancer le programme, pas ce que l'utilisateur choisit d'utiliser. Sinon, je code un kernel de 64 KO et je dis: "Moi, j'utilise mon kernel de 64 KO, donc je compte 64 KO pour chaque programme pour kernel. grin"
>Même dans un jeu de plateau, on n'est pas à 1 ms près. Si ton Mario ou Sonic met 1 ms de plus pour un saut, personne ne le remarquera. S'il y a 20 ennemies a l'ecran et que les 20 sautent, ca fait 20ms, et ca, ca se remarque (a 20 fps, ca fait 400ms par seconde).

Tu as déjà vu un Mario avec 20 ennemis qui sautent en même temps, toi?
>Et d'ailleurs même un jeu de plateforme très lent, par exemple un Mario en BASIC, peut être jouable. (J'ai essayé personnellement.) Certes. Mais ?

Donc la vitesse n'est pas aussi importante que vous avez l'air de croire.
>- est due à la suppression de OSVRegisterTimer et OSVFreeTimer par AMS Y'a en d'autres qui ont disparus !!

Bon, EM_blockErase et fonctions liées et quoi d'autre? Rien qui était en utilisation réelle. Et puis les kernels n'ont rien fait pour résoudre ce problème. Nous oui: on a mis OSVRegisterTimer et OSVFreeTimer dans tigcc.a.
>- concerne aussi le mode kernel. Les kernels n'ont rien fait pour résoudre ce problème. Cette histoire de "il suffit de mettre à jour le kernel" est un mensonge courant, mais quand-même un mensonge. C'est très loin de la réalité.
Si tu veux je peux le resoudre, mais c'est inutile car je n'ai pas eu le temps de le faire.
Alors que faire ? Laisse comme c'est oué. Mais le kernel aurait pu faire cela sans probleme !

Mais nous, on a résolu le problème très vite. Les kernels n'ont rien fait pour le résoudre.
>- peut être résolue par une simple recompilation sans aucun changement des sources Y'a le mot recompilation qui me gene.

Je sais déjà que tu es anti-recompilation. grin
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

199

Tu as déjà vu un Mario avec 20 ennemis qui sautent en même temps, toi?

j'ai déjà vu un KryptonII avec plus de 100 missiles simultanément à l'écran (il y a une super-arme qui permet d'en générer 96 simultanément smile, plus les missiles "normaux" qui, qd on a toutes les armes, sont plus de 20 à l'écran), plus les murs, plus les murs animés, plus les missiles ennemis, plsu les ennemis, ....
Mais, tu vas dire que c du vaporware, vu qu'il n'y a pas eu de bêta publique smile
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

200

PpHd a écrit :
>Parce que tu penses qu'en optimisant en taille, on pert une milliseconde entière par frame? On est plutôt dans l'ordre de grandeur de quelques microsecondes par frame. Oué on peut arriver en optimisant vraiment en taille a ca !

C'est ironique?
Je te signale que je ne parle pas du temps total mis pour calculer un frame, mais de la différence entre le temps mis par une routine optimisée en vitesse et le temps mis par une routine optimisée en taille. Je ne pense pas que ça dépasse l'ordre de grandeur des 100 µs (1200 cycles). Peut-être que je me trompe, mais il faudra des chiffres pour montrer que j'ai tord.
>CounterStrike n'est pas un jeu de plateau. C'est un jeu multijoueur où le temps de réaction compte beaucoup. C'est totalement différent. Un mario/sonic est beaucoup plus qu'un simple jeu de plateaux.

Mais ça n'a rien à voir avec un CounterStrike!
>Et puis, pour n'importe quel jeu, au-delà d'une dizaine ou au maximum une vingtaine de FPS (au-delà de 10 FPS selon Thomas Nussbaumer), plus personne ne remarque la différence. Ca depend si le jeu a ete concu pour fonctionner a ce frame rate. Aucun jeu d'action a l'heure actuelle n'est prevu pour (il ne faut pas fournir des images statiques, mais des images dynamiques en pretraitant l'integration des photons par l'oeil).

L'œil n'arrive quand-même pas à distinguer par exemple entre 100 et 200 FPS. (J'ai utilisé exprès de très grosses valeurs pour que la valeur exacte à partir de laquelle on ne voit plus la différence ne rentre pas dans l'équation.)
>On ne dirait pas en te lisant. Tu veux que je sortes le programme interdisant l'emploi des nostub ?

Non.
>Peut-être, mais genlib prend plus de 2 fois plus de place que les fonctions de TIGCCLIB (gray.h) et ExtGraph utilisées habituellement. Peut-être, mais genlib offre largement plus de 2 fois le nombre de fonctions offertes par gray.h et extgraph.

Mais les fonctions offertes par genlib sont sur la calculatrice même si elles ne sont pas utilisées!
>Au lieu de mettre un pointeur en auto-modifiant, tu le prélèves dans un paramètre comme le fait ExtGraph. Ce n'est pratiquement pas plus lent. Et ça donne du code plus petit dans ta librairie Pushe ce parametre, le lire, est lent. Beaucoup trop lent pour moi, desole.

Tu connais le passage par registres? Il me semblait que oui, mais j'ai des doûtes là. grin
Tu peux même utiliser une "global register variable". Comme ça, il n'y a rien à copier, sauvegarder ou restaurer (sauf au tout début et tout à la fin).
>Mais une simple optimisation de taille ne fera certainement pas perdre 1 ms par unité graphique.
Si ! Compare donc Les routines de sprites de tigcclib a celles d'extgraph !

Bon, d'accord, je vais tester ça.
>Tu fais trop de calculs de vitesse dans un ordre de grandeur qui est de toute façon négligeable. Déjà, tes 5% sont très probablement une surestimation, et puis on n'est pas à 5% près.
5% est la marge a partir de laquelle le gain est plus que le bienvenu. En dessous, ca peut se discuter.

C'est raisonnable comme position.
Mais personnellement, je mettrais plutôt la marge à un facteur de 2/3 (c'est-à-dire 33% ou 50%, en fonction de la référence qu'on prend).
>Moi oui, mais pas tout le monde qui utilise un anti-crash.
Mais ca n'empeche pas que ca solution d'afficher un message n'est pas terrible ! En plus, ca ne marche que sur AMS 2.0x

KerNO 2.xx ne fonctionne que sur AMS 2.0x. Ce n'est pas un bogue, c'est fait exprès.
>Je suis sûr que Greg Dietsche accepte les conseils d'amélioration. Maile-lui. Je n'en ai aucun pour le moment.

Ben, tu peux lui conseiller de ne pas afficher de message dans ce cas, par exemple. roll
>Non. Ce que tu toi, tu appelles "flexible" est tout simplement lourd. J'ai déjà dit dans ce topic pourquoi le format kernel est en fait moins flexible que le format _nostub. Moins flexible ? Pourquoi faut-il patcher les executables pour qu'il marche sur V200 alors ? Tu appelles ca de la flexbilite ?

Ce que j'appelle un format flexible, c'est le format qui fixe le moins de trucs possibles, et laisse donc le maximum de choix au programmeur et à son outil de développement. C'est à l'outil de développement de fournir les fonctionnalités au programmeur, pas au format de l'exécutable.
>On peut aussi intercepter les appels à un programme _nostub. Il suffit de modifier un peu le hook du trap #11 de h220xTSR. Tu peux même rajouter un "trampoline" en changeant quelques adresses, ce qui te permet de détecter aussi quand le programme a fini l'exécution. Ca ne marche pas sur AMS 1.0x !

Tant pis.
Je vois nettement plus de personnes qui utilisent DoorsOS que AMS 1.0x, et pourtant tu t'en fiches de la compatibilité avec DoorsOS.
>Mais c'est un hack. Si un programme non-TSR installe un TSR, c'est un hack. C'est même un leak de mémoire. Mais c'est AUTONOME ! Gagne !

Un leak de mémoire est un bogue, donc tu as perdu. tongue
>Je répète: Si tu n'aimes pas, personne ne t'empêche de n'utiliser que ttstart ou TICTEX. Si d'autres utilisateurs préfèrent l'autre solution, c'est leur problème, et tu n'as pas à t'en mêler. Les programmes compressés avec ExePack permettent à l'utilisateur de choisir la solution qu'il préfère. Et avec les pack archive, au moins il n'y a pas ce probleme. C'est bien de centraliser les problemes.

En quoi la liberté de choix est-elle un problème??? Ta manière de "centraliser" les problèmes est celle utilisée par les régimes autoritaires.
>Désolé, je n'ai pas compris ta question là.
Normal, elle etait incomprehensible. Certains utilisateurs demandent de l'aide avant meme d'essayer le programme. C'etait le point ou je voulais te faire venir.

Ça m'arrive rarement. Les mails que je reçois le plus souvent sont de style "ur chem program doesnt work,it gives me an error.could u plz give me step by step instructions on how to solve an equation with it?" (j'ai mis des erreurs exprès parce que les messages que je reçois au sujet de CHEMISLV sont rarement sans erreurs). La raison habituelle est que certains gens se croient malins en l'envoyant dans un répertoire autre que "main" et de ne pas changer le répertoire courant avant de l'utiliser. Donc, comme c'est du BASIC, il ne trouve plus ses sous-programmes. Mais les gens qui demandent de l'aide avant même d'avoir essayé sont assez rares.
>Le mien est qu'il est tout simplement impossible d'"éduquer" les utilisateurs, et qu'un programme doit prévoir toutes les c*nneries qu'un utilisateur pourrait faire.
C'est strictement impossible ! Un utilisateur pourra toujours faire des conneries ! 'J'ai fait delvar tictex. Tictex marche plus, c'est normal monsieur ?'

rotfl
>Un programme bien utilisable est un programme qui peut être utilisé même par le pire des idiots.
Et bien bon courage. Le pire des idiots ne saura meme pas allumer la machine. D'ailleurs il n'aura aucun interet dans le programme.

rotfl
Mais ce n'est qu'en ayant cet idéal-là (même si ce n'est évidemment qu'un idéal) qu'on crée des programmes faciles à utiliser.
>Ils n'ont pas leur archive pleine à 95% ou plus normalement. J'ai des doutes... Sondage ?

Si tu veux.
>Les TI-89/92+/V200 ne sont pas une bonne plateforme "host" (par opposition à "target") pour le développement en C. Il ne tient qu'a nous d'en faire une bonne plate forme !

Comment ça? Le matériel est totalement inadapté.
>Mais c'est tout dans l'autre sens que dans celui duquel je parle. Et y'a aussi kernel::exec qui est incompatible. Ou la facon d'acceder aux repertoire home/main.

Bon, OK. Mais tout ce système de librairies dynamiques est copié directement sur Fargo.
>Ce n'est pas une émulation, mais de la compatibilité antérieure, parce que c'est le même format. Je m'embrouille. Tu parles de compatibilite anterieure avec les precentes versions d'AMS. Mais c'est faux. Exemple : mon programme d'install de cf peut planter sur les nouvelles versions d'ams.

La compatibilité antérieure est rarement parfaite. Il arrive souvent de trouver des contre-exemples. Il y a aussi des programmes qui marchent avec Windows Me et pas XP, par exemple.
>Windows 3.1 est un OS complet implémenté par dessus un autre OS. La différence entre Windows 3.1 et le format kernel est qu'un programme Windows 3.1 n'appelle (normalement) pas les appels DOS alors qu'un programme kernel TI-89/92+/V200 appelle les ROM_CALLs de AMS. Hein ? C'est totalement faux. Ne serait-ce que pour le systeme de fichiers.

Les programmes appellent-ils les fonctions de fichiers de DOS directement? Je ne pense pas.
>Ben, PlusShell et les premières bêtas de DoorsOS sont quand-même les premiers kernels, et donc la motivation derrière ces 2 kernels est la motivation derrière le système de kernels en général. Et les Pack Archive ? C'est compatibilite fargo encore ?

Non, et c'est pour ça que je n'arrête pas de dire que c'est inutile. Tu essayes de faire faire au kernel des choses pour lesquelles il n'était tout simplement pas prévu.
>Ce sont des ajouts d'ordre mineur. Ça ne change rien à l'idée de base derrière le format. Ce format est tres different de celui de fargo (rom_calls, ram_calls <rappel fargo n'a ni romcall, ni ramcall mais deux libraries 'tios' et 'kernel',

... ce qui revient au même en pratique.
exit, exportation des fonctions de programmes, multi-linkages de libs,

Ce sont des améliorations d'ordre vraiment mineur.
etc).

Etc. quoi? Je suppose que ce sont des changements (même pas forcément des améliorations) d'ordre encore moins important.
>Solution: corriger les bogues. Les versions 1.00 des logiciels de la TICT ne sont pas ultra-bogués. Je ne dis pas qu'il n'y a pas de bogues (un logiciel sans bogues est quelque chose de pas très réalisable en pratique), mais entre "aucun bogue" et "ultra-bogué", il y a une marge Ca prend du temps de corriger les bogues et d'ajouter des features. Il faut laisser le temps a l'utilisateur de tester.

On corrige les bogues avant et on rajoute les nouveaux features après. La TICT a toujours fonctionné comme ça, et ça se voit: rares sont les programmes aussi stables que les programmes TICT.
>Si seulement tout le monde faisait ça... Avec le nombre de flames en public qu'on a eu au sujet de bogues dans TIGCC 0.9x, on est très loin de ça. Je vous ai deja enfonce pour un bogue ?

Toi non. Mais certains autres, oui.
>En théorie oui, mais bonjour la taille de ton programme. Pas forcement. Moins d'un mega je pense.

Vive les disques durs de plusieurs GO! grin
Les programmes pour PC ont tous tendance à être beaucoup trop gros à mon avis. sad
>Alors qu'un programme _nostub peut remplir toutes les fonctionnalités d'un programme kernel avec au maximum 5 KO de plus (parce que le kernel est un programme _nostub de 5 KO). Et ce qui rend le tout intéressant, c'est que normalement, un programme _nostub a besoin de nettement moins de 5 KO pour remplir lui-même les fonctionnalités offertes par le kernel. Sauf tout ce qui touche a la partie TSR.

Mais on n'a pas besoin de la partie TSR en _nostub. Sauf si on installe un TSR, mais comme ce n'est pas possible (de manière propre) en mode kernel, ce n'est pas en discussion.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

201

Kevin Kofler a écrit :
Il faudra m'expliquer quels sont ces "trucs" que tu veux calculer et qui mettent tellement de temps à être calculé. L'IA de Backgammon calcule pas mal de trucs (elle évalue tous les coups légaux), et pourtant la réponse est "instantanée". L'IA de TI-Chess calcule elle aussi pas mal de trucs même en L1 et pourtant la réponse en L1 est pratiquement instantanée. Et les IAs de jeux comme Backgammon ou TI-Chess ont nettement plus de trucs à calculer que les jeux en "temps réel".

Ben par exemple (dans le cas d'un moteur 3D), il faut d'abord éliminer les polygones qui sont en dehors du champ de vision pour ne pas avoir à calculer quoi que ce soit pour eux (et oui, ça prend quand même un peu de tps de vouloir gagner du temps), ensuite calculer les rotations et translations à appliquer à chaque polygone, ensuite, il faut les clipper, projeter leurs coordonnées dans l'écran, et là on peut les afficher.
Si par exemple, le temps de calculer tout ça n'est que de deux dixièmes de seconde, ça paraît instantanné, mais le moteur ne tournera pas à plus de 5 fps (sachant qu'il faut en plus prendre du temps pour tout afficher)...

202

PpHd a écrit :
>Le mode _nostub n'est pas "imparfait" (certes, rien n'est vraiment parfait, mais le mode _nostub est très bien fait). Et pourrais-tu détailler "redondant"? Parce que je ne vois pas la redondance dans le format (sauf si tu parles de ce qui permet d'éviter le dérelogement - si c'est ça, il y a une raison, donc ce n'est pas une redondance).
Ca peut etre eviter en faisant comme ne kernel et en rajoutant juste une long contenant la valeur de la precedente relocation. Pour rereallouer un programme, il suffirait de faire une relocation de (nouvelle_valeur-ancienne_valeur) pour que ca marche smile

La solution de AMS a quand-même un avantage. Le suivant marche en _nostub et pas en mode kernel:
.include "os.h"

.xdef _ti89
.xdef _ti92plus
.xdef _v200
.xdef _nostub
|.xdef _main
|main:
move.l %d3,-(%a7)
moveq.l #1,%d3
loop:
pea.l loop:l
pea.l format(%PC)
pea.l buffer(%PC)
move.l 0xc8:w,%a0
move.l sprintf*4(%a0),%a0
jsr (%a0)
lea.l 12(%a7),%a7
pea.l buffer(%PC)
move.l 0xc8:w,%a0
move.l ST_helpMsg*4(%a0),%a0
jsr (%a0)
addq.l #4,%a7
move.l 0xc8:w,%a0
move.l ngetchx*4(%a0),%a0
jsr (%a0)
move.l #0xc8,loop+2
dbra.w %d3,loop
move.l (%a7)+,%d3
rts

format: .asciz "%lp"
buffer: .space 9

Comme tu vois, si l'adresse relogée est corrompue pour une raison ou une autre, l'adresse correcte est restaurée en mode _nostub, alors qu'en mode kernel, ou avec la solution que tu proposes, l'adresse calculée peut valoir n'importe quoi et faire tout planter (pas dans cet exemple-là, mais dans un cas concret).
>1. TIGCC a toujours été codé en pensant au confort du programmeur qui l'utilisera. Pour le programmeur nostub.

TIGCCLIB supporte exactement les mêmes fonctionnalités (sauf EXECUTE_IN_GHOST_SPACE et ENABLE_ERROR_RETURN) en mode kernel et en mode _nostub.
>2. Je ne vois pas le rapport entre "support du mode kernel" et "confort du programmeur". C'est plus simple en kernel : moins de lignes de code, plus d'aisances.

Seulement si tu passes à côté de l'abstraction de TIGCCLIB. Avec TIGCCLIB, des choses comme CALCULATOR fonctionnent exactement de la même manière dans les 2 cas.
>Ben, si on oublie de déreloger. Qui reloge ? Qui dereloge ? Le kernel !

Sauf si on fait comme DB92. smile
Et preos a un systeme qui permet de passer outre les problemes d'oublis de derelogement.

Comment ça?
>Pour les #defines mal tapés, je ne vois pas comment on devrait résoudre ce problème-là. Utiliser un #include n'est pas une bonne idée. Ça ralentit et alourdit la compilation et ça oblige à rajouter des headers supplémentaires, tout ça pour très peu de gains. Et puis, les headers de TIGCC suivent les conventions 8.3, donc execute_in_ghost_space.h est trop long. Des pragmas ?

Ça nous obligerait à patcher GCC pour des trucs qui devraient être sous la responsabilité des headers.
>Ce n'est pas possible pour la compatibilité avec les très vieux programmes, qui ne mettent aucun #define, mais des short _ti89; pour sélectionner les modèles. Changer le nom de l'include principal alors ! Et garder tigcclib pour la compatibilite anterieure.

Hors de question. On ne va pas changer le nom de TIGCCLIB, et on ne va pas rajouter un neuvième caractère (numéro de version) au nom du fichier non plus.
>Je ne trouve pas. Le problème n'existerait pas si Doors Explorer était codé correctement. Tu connais un programme code correctement ?

http://tict.ticalc.org smile
>addstupc toto.89z inuse.bin. C'est très simple. En theorie.

Je ne vois pas le problème que ça poserait en pratique.
>Mais tu as quand-même "copié" SET_FILE_IN_USE_BIT. C'est un BUG d'AMS ! Il fallait que je le corrige !

Ben, nous aussi. grin
Et on se retrouve avec le problème résolu 2 fois dans certains cas. Mais bon, tu as raison, il vaut mieux résoudre un problème 2 fois plutôt que pas du tout.
>Aucune des nouvelles fonctionnalités est suffisamment importante pour justifier l'effort de maintenance supplémentaire. Et puis, USE_KERNEL n'est supporté que pour permettre de compiler les vieux programmes qui l'utilisent. On ne compte pas y rajouter quoi que ce soit. C'est bien pour ca que j'ai sorti un VRAI include pour faire du bon mode kernel.

Ton include utilise des hacks assez bizarres. Je te les ai signalés, mais tu as refusé d'en corriger quelques uns. Par exemple, pourquoi ton hack pour le support pour exit? Le code de tipatch.lib marche très bien! Et même mieux, parce que ton code ne permet pas NO_EXIT_SUPPORT. D'ailleurs, tu risques d'avoir des ennuis quand le code de tipatch.lib sera changé en "startup sections" dans le nouveau linker de Sebastian.
>Tu es vraiment un égoïste. Je ne pensais pas que tu étais égoïste à ce point-là. Et toi tu ne l'es pas ? Qui ne l'est pas ? Je plains celui qui n'est pas egoiste ! Il n'est pas fait pour vivre dans ce monde. Paix a son ame.

Vive l'optimisme! grin roll sad
>Tu n'as pas compris ce que j'ai voulu dire. Le problème est le découpage automatique en morceaux de 64 KO. C'est ça la partie dure. Pas tant que ca. Un simple algo (pas forcement optimum) pourra faire l'affaire. Apres tout tant pis si c'est en 3 ou 2 fichiers.

Dis-moi comment on était censés implémenter le découpage lors du linking avec un système de linking en 2 étapes: ld ne peut sortir qu'un .o, obj2ti ne reçoit qu'un seul fichier .o. Ce découpage sera réalisable (mais pas nécessairement réalisé) avec ld-tigcc (TIGCC 0.95), mais il ne l'était pas du tout quand le support des DLLs a été introduit.
>Le problème est où? Le manque de coherence dans le nom des romcalls d'un module a l'autre.

C'est vrai (il y a des DrawStr et des push_parse_text), mais ce n'est pas un gros problème.
D'un surabondance de fonctions inutiles, et d'un manque de fonctions utiles.

Les fonctions que tu juges "inutiles" ne le sont pas nécessairement. Certaines fonctions utiles manquent, mais les APIs parfaites n'existent pas.
push_internal_simplify par exemple.

Et ton problème est où? C'est accessible à partir de AMS 1.01:
[Main]
Name=push_internal_simplify
Type=Function
Subtype=ROM Call
Header Files=estack.h
Definition=void push_internal_simplify (CESI ptr);
Real Definition=#define push_internal_simplify (*(__push_internal_simplify__type__)
(AMS_1xx ? (*((void**)((char*)_rom_call_addr(385) + 22))) : _rom_call(void,(CESI),4F8)))
MinAMS=1.01

[ROM Call]
Index=$4F8

>Les fonctions les plus importantes d'un runtime C sont toutes dans la ROM: malloc, free, sprintf, ... fopen, printf, etc aussi, n'est ce pas ?

Il y a des fonctions Fopen et liées qui ressemblent à du C ANSI, mais ne le sont pas vraiment, dans AMS 2. Mais de toute façon, fopen est implémentable en assez peu d'octets en termes de vat.h, comme on l'a fait dans tigcc.a.
Pour printf: il y a vcbprintf dans la ROM, et cette fonction fait presque tout le travail de printf et permet au printf de tigcc.a d'être très compact.
stdin, stdout, stderr, aussi n'est-il pas ?

Ça ne fait pas vraiment partie des fonctions les plus importantes.
>Les fonctions graphiques essentielles comme l'effaçage d'écran et le tracé de texte, de lignes et d'autres objets géométriques y sont aussi. Ainsi que DrawTexturedPolygon n'est il pas ?

AMS != OpenGL grin
Il y a FillTriangle, ça suffit largement. De toute façon, le texture mapping avec la vitesse de AMS serait inutilisable. grin
>Il faut quand-même une infrastructure pour le linking sous demande (c'est-à-dire pour ne linker que les fichiers objets réellement utilisés). Bof. Pas si dur. Il faut quand meme pas exagerer la difficulte.

Il est vrai que ça n'a pas pris très longtemps à Sebastian pour ld-tigcc. Bien moins que le support du mode kernel. Mais ce n'est quand-même pas trivial.
>C'est un abus du format!!! Pourquoi utiliser des PRGM pour des programmes en assembleur???
Parce que les programmes PRGM peuvent faire plus de 24K et etre executes sans probleme. PS: C'est vrai.

Au fait, je traînais depuis longtemps l'idée de mettre un lanceur de style ttstart en Exec et de cacher le vrai programme dans le début du PRGM. Mais je n'ai jamais essayé de la réaliser, parce que je trouve ça vraiment abusé que de mettre de l'assembleur dans un PRGM.
>Et TI-Connect ne transfèrera très probablement pas tes fichiers On verra bien. Je pense que si.

Et moi, je pense que non. smile Il rejette normalement les fichiers "corrompus" (par exemple les chaînes de caractère qui n'en sont pas).
>Nous aussi. A recompiler tous les fichiers et programmes ?

C'est trop demander que de demander aux auteurs de recompiler leur programme une fois tous les 4 ans? Ben moi, je trouve que non.
En tout cas, _keytest et tous les #defines de compat.h sont prêts pour un nouveau modèle.

Et d'ailleurs, un troisième type de modèle totalement différent f**trait aussi la m*rde en mode kernel et obligerait donc aussi de recompiler pas mal de programmes:
- Beaucoup de programmes (entre autres ceux compilés avec TIGCC, mais pas seulement - cf. TxtRider, ziplib, ...) choisissent des constantes en fonction du résultat de tst.w CALCULATOR. Le kernel n'a aucun moyen de rajouter une troisième possibilité sans que le programme soit recompilé.
- Les EXTRA_RAM_CALLS cesseront eux aussi de fonctionner en présence d'un troisième modèle radicalement différent des 2 autres (parce qu'il n'y a que le choix entre 2 valeurs - c'est d'ailleurs un bon argument contre l'utilisation des EXTRA_RAM_CALLS dans TIGCC: ils ne sont pas du tout conçus de manière extensible, donc on fait quoi quand un nouveau modèle arrive?). D'ailleurs, déjà pour la V200, si un programme avait utilisé des EXTRA_RAM_CALLS pour choisir entre 0x2xxxxx et 0x4xxxxx, il n'aurait plus fonctionné.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

203

PpHd a écrit :
>Ben, si tu es trop paresseux pour taper 4 lignes (ou une douzaine en ASM), on se demande pourquoi tu programmes. En tout cas pas pour taper des lignes sans interet, auxquelles je peux me passer.

C'est bien ça: tu es paresseux. grin
Ça explique aussi pourquoi tu te plains des quelques #defines à mettre si tu veux désactiver le code d'initialisation de TIGCC.
>Ça arrive si souvent qu'on arrête d'utiliser un fichier de données où on l'utilisait à un moment? Dans les rares cas où ça arrive, est-il vraiment si dur de retirer 4 lignes ou de les mettre sous #if 0 (ou ifne 0)??? Ca arrive. Et dans ce cas, il faut rechercher l'importation du fichier de donnees dans le code source.

[Ctrl]+[F]SymFindPtr[ENTER]
>Tu appelles tes variables malib@1234, toi? Si c'est le cas, alors 5678(a3) est tout aussi clair. Sauf que malib@1234 peut changer sans arret d'offset, mais pas 5678(a3).

Si c'est vraiment un problème, il suffit d'utiliser une indirection supplémentaire.
>Les 12 registres sont là pour être utilisés. Autant les utiliser pour autre chose. 12 registres c'est peu.

Sauf que ce sont 16, pas 12. grin Désolé, j'ai raté cette erreur en me relisant. embarrassed Mais tu ne l'as pas remarquée, toi non plus. grin
>Si on a implémenté une fonctionnalité et qu'on se rend compte que ce n'est pas une bonne idée, mais qu'on n'ose pas la supprimer pour des raisons de compatibilité, le minimum à faire est de déconseiller son utilisation, pas de la conseiller Sauf que moi je conseille de les utiliser !

C'est justement ça que je te reproche.
>On peut toujours exprimer ça en termes d'écrans de taille normale et de routines clippées. Comment remplir un BackBuffer de taille 400x300 par exemple ?

On n'utilise pas de BackBuffer. grin

Et puis le fait de permettre à la taille de l'écran d'être variable ralentit et agrandit pas mal les routines graphiques. Cf. BitmapPut. La dernière fois que j'ai regardé, genlib n'avait pas l'air de supporter les écrans 400×300 non plus...
>C'est un hack qui tourne autour du problème au lieu de le résoudre à sa base.
Un hack ? Ou ca ? eek

C'est un hack parce que tu implémentes un système d'allocation totalement différent par dessus celui du système d'exploitation.
C'est tres propre et ca offre des fonctionnalites manquantes (Je dis bien que malloc n'est pas concu pour le meme usage que genalib__alloc).

N'empêche que tu tournes autour du problème alors qu'il suffirait d'adapter les programmes pour utiliser des stratégies d'allocation plus adaptées à la plateforme.
>Ben, dans ce cas, c'est que les documentations sont insuffisantes. En d'autres mots, envoie ce que tu as trouvé à Doc@tigcc.ticalc.org (c'est Sebastian qui lit cette adresse) s'il te plaît. Ce que j'ai trouve ? C'est en testant jusqu'a que ca marche !

Et as-tu des résultats documentables? Si tu sais pourquoi une combinaison est mieux qu'une autre, documente-le. Sinon, ben tant pis. sad
>Ça nous fait encore plus de travail, pour quelque chose qui n'apporte aucune fonctionnalité nouvelle (compat.h de TIGCCLIB marche très bien comme c'est). Qui ameliore une fonctionnalite passee. Ou est le probleme ? Pourquoi pire ?

Le problème est que c'est beaucoup de travail pour quelque chose qui n'est ni une correction de bogue, ni vraiment une addition de fonctionnalité. Mais je ne dis pas du tout que la réponse définitive sera "non". Il faut suggérer l'amélioration à Sebastian, il demandera mon avis et éventuellement celui de Zeljko, et puis on prendra une décision. Alors: comptes-tu suggérer ça à Sebastian ou dois-je le faire?
>Ça n'apporte aucune fonctionnalité supplémentaire par rapport à (TI89?xx:xx). Un code plus compact, plus rapide, plus petit.

Est-ce vraiment une fonctionnalité (surtout vu que ça donne du code "plus compact, plus rapide, plus petit" seulement en mode kernel)?
>Mais c'est une abbréviation valable pour dire "librairie dynamique".
Absolument pas ! Les DLL windows, c'est de la merde ! Je proteste ouvertement de cet abus de langage !

DLL = dynamically linked library. C'est exactement la même chose que le terme "librairie dynamique".
>Le terme "librairie" vient de "function library" ("bibliothèque de fonctions"). Un fichier de données n'est pas une librairie. Ou est que tu as lu ca ?

Je ne sais plus. Mais en tout cas, on ne parle pas de "library" pour des données normalement.
>Au contraire, c'est très simple à faire. Il suffit de vérifier les octets de taille. On pourra toujours passer outre.

Évidemment qu'on peut toujours faire des âneries si on veut. Mais ça décourage quand-même.
>Ca n'est pas notre faute si des trucs sont breakés par TI...
Et puis, je voudrais t'y voir, toi, à updater tous ces programmes, avec aussi peu de temps... d'ou l'interet du kernel !

Ben non. Thomas Nussbaumer est un auteur qui agit de manière responsable et altruiste. Il met toujours à jour ses programmes quand il y a des problèmes. Tous les programmeurs devraient suivre son exemple.
>Pitoyable. Même nous, qui n'aimons pas le kernel, te faisons des suggestions (notamment pour l'amélioration de ces RAM_CALLs de fonts qui sont actuellement implémentés n'importe comment: très lent, pas sûr...) 1. On s'en fout de la vitesse de detection. On n'est pas a 1 ms pret.

Depuis quand? grin
2. Ca marche.

Non. Ça prend la mauvaise fonte si on utilise ROMedit ou Font Installer Demo.
3. Ce sont les fonts du boot qui DOIVENT etre exportes.

Pour _RAM_CALL_00E oui. Pour les autres absolument pas. Et rien ne t'empêche de rajouter un autre RAM_CALL pour tios::font_medium (maintenant que le problème de tios::font_small et tios::font_large définis en ses termes est résolu), et de renommer _RAM_CALL_00E en tios::boot_fonts.
4. J'ai deja propose des trucs mais personne ne m'ecoute.

Parce que tes suggestions sont soit irréalisables, soit extrèmement difficilement réalisables.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

204

PpHd a écrit :
>Ton code ExtGraph est mal écrit, soit par ignorance, soit exprès.
>Voilà l'équivalent ExtGraph de ton code XLib, codé correctement:
>>if (!GrayOn()) return;
>>ClearGrayScreen();
>>GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
>> GrayGetPlane(LIGHT_PLANE),GrayGetPlane(DARK_PLANE));
>>ngetchx();
>>GrayOff();
>C'est plus court. Seul l'appel GraySprite16_MASK est un peu plus long, mais c'est pour plus de flexibilité, et pour éviter de devoir faire l'équivalent de PortSet ou de XGPlanc. Moi je compte 6 lignes pour les deux. Et si je compte le nbr de caractere, Xlib est plus petit.

Il y a 6 lignes seulement parce que j'ai été obligé de couper l'appel à GraySprite16_MASK en 2 lignes à cause de la largeur limite du forum. Il était en 5 lignes avant.
>As-tu une bonne raison d'utiliser USE_KERNEL? Parce qu'en principe, tout ce qui est possible avec TIGCCLIB en mode kernel est aussi possible en mode _nostub?
A oui ? Et un appel a genalib__0000(malloc(10000)); en nostub on fait comment ?

genalib pourrait très bien exister en statique. Ce n'est que parce que toi, tu refuses de faire une version statique qu'elle ne marche qu'en mode kernel.
>Ben, tant mieux pour eux s'ils peuvent lancer le programme sans se casser la tête! Ce que tu présentes comme un inconvénient est en fait un avantage! Trouves-tu vraiment qu'il faut forcer les utilisateurs à économiser de la place sur leur calculatrice??? Moi, je ne trouve pas ça du tout! Doit-on les forcer a rester ignorant ? Ne doit-on pas les eduquer ?

Entre les forcer à rester ignorants et les forcer à apprendre, il y a une grosse marge.
>Si, genlib et ExtGraph+gray.h sont utilisées dans exactement les mêmes conditions: quand on a besoin d'une librairie pour l'affichage graphique. Equivalent de put_fgrd_dhz_plane en tigcclib/extgraph ?

À part toi, qui utilise ça? grin
Il faut déjà une journée pour avoir une idée vague de son fonctionnement. C'est beaucoup trop compliqué.
MacIntoc
a écrit : Nan, pasque sur GBS, les éléments ne vont pas à la même vitesse (les balles, par exemple). S'il commence à virer des frames, les balles, on les verras plus partir.

On les verra partir, mais plus vite (à la même vitesse que sur TI-89).
xeno
a écrit : Putain, plus je lis ca, plus j'a envie de prog en kernel!

what
squale92 a écrit :
j'ai déjà vu un KryptonII avec plus de 100 missiles simultanément à l'écran (il y a une super-arme qui permet d'en générer 96 simultanément smile, plus les missiles "normaux" qui, qd on a toutes les armes, sont plus de 20 à l'écran), plus les murs, plus les murs animés, plus les missiles ennemis, plsu les ennemis, ....

Oui, mais toi, tu fais exprès. smile 96 missiles à la fois!?!
Mais, tu vas dire que c du vaporware, vu qu'il n'y a pas eu de bêta publique smile

Oui, en plus. smile
jackiechan a écrit :
Ben par exemple (dans le cas d'un moteur 3D), il faut d'abord éliminer les polygones qui sont en dehors du champ de vision pour ne pas avoir à calculer quoi que ce soit pour eux (et oui, ça prend quand même un peu de tps de vouloir gagner du temps), ensuite calculer les rotations et translations à appliquer à chaque polygone, ensuite, il faut les clipper, projeter leurs coordonnées dans l'écran, et là on peut les afficher. Si par exemple, le temps de calculer tout ça n'est que de deux dixièmes de seconde, ça paraît instantanné, mais le moteur ne tournera pas à plus de 5 fps (sachant qu'il faut en plus prendre du temps pour tout afficher)...

Un moteur 3D est un cas bien particulier. Oui, chaque FPS compte en 3D. Mais de toute façon, une librairie graphique 2D n'est pas ce qu'il y a de plus adapté pour du 3D. Sauf éventuellement une routine de tracé de lignes, mais celle de ExtGraph (FastDrawLine) marche très bien (elle est rapide), et elle va bientôt être encore plus rapide.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

205

Kevin Kofler
a écrit : Un moteur 3D est un cas bien particulier. Oui, chaque FPS compte en 3D.

Oui, mais pas seulement en 3D, comme l'a souligné Squale92, un shoot them up par exemple nécessite parfois que beaucoup de missiles soient affichés en même temps à l'écran.
Mais de toute façon, une librairie graphique 2D n'est pas ce qu'il y a de plus adapté pour du 3D.
Effectivement. Mais je n'ai pas dit le contraire. Je voulais juste te montrer l'importance que pouvaient avoir quelques millisecondes.
Sauf éventuellement une routine de tracé de lignes, mais celle de ExtGraph (FastDrawLine) marche très bien (elle est rapide), et elle va bientôt être encore plus rapide.
[pub]Oui, ainsi qu'une fonction de tracé de ligne horizontale très rapide[/pub] grin (c'est XDanger et moi qui l'avons écrite)

206

Kevin Kofler a écrit :
C'est quoi cette horreur? Non seulement, c'est écrit de manière excessivement longue, mais en plus tu affiches ton message d'erreur avant le GrayOff.

Voilà comment on fait ce que tu veux faire (mais pourquoi utiliser un écran virtuel pour 2 sprites???):
#define sprite(x,y,s,p) GraySprite16_MASK((x),(y),16,(s),(s)+16,(s)+32,(s)+32,(p),(void*)(p)+3840)
if (!GrayOn()) {e: ST_helpMsg("Not enough memory");return;}
void *a=malloc(7680);
if(!a) {GrayOff();goto e;}
ClearGrayScreen2B(a,a+3840);
sprite(1,1,blabla,a);
sprite(1,1,blabla,a);
FastCopyScreen(a,GrayGetPlane(DARK_PLANE));
FastCopyScreen(a+3840,GrayGetPlane(LIGHT_PLANE));
free(a);
ngetchx();
GrayOff();
Oui, c'est un peu long, mais c'est parce que tu utilises un écran virtuel pour rien.



[kevin]C'est quoi cette horreur?[/kevin]

#define sprite(x,y,s,p) GraySprite16_MASK((x),(y),16,(s),(s)+16,(s)+32,(s)+32,(p),(void*)(p)+3840)

if (!GrayOn())
  {
e:
    ST_helpMsg("Not enough memory");
    return;
  }
void *a = malloc(7680);
if(!a)
  {
    GrayOff();
    goto e;
  }
ClearGrayScreen2B(a,a+3840);
sprite(1,1,blabla,a);
sprite(1,1,blabla,a);
FastCopyScreen(a,GrayGetPlane(DARK_PLANE));
FastCopyScreen(a+3840,GrayGetPlane(LIGHT_PLANE));
free(a);
ngetchx();
GrayOff();


moi je dis, c'est vraiment tres porc tout ca triso (grin)
en plus ton goto qui sert a rien.. rholala... voila la raison pour laquelle on nous interdit aussi les goto, pour eviter qu'ils soient utilises abusivement comme tu l'as fait... roll

#define sprite(x,y,s,p) GraySprite16_MASK((x),(y),16,(s),(s)+16,(s)+32,(s)+32,(p),(void*)(p)+3840)

void   *a;

if (!(a = malloc(7680)) || !GrayOn())
  {
    ST_helpMsg("Not enough memory");
    return;
  }
ClearGrayScreen2B(a, a + 3840);
sprite(1, 1, blabla, a);
sprite(1, 1, blabla, a);
FastCopyScreen(a, GrayGetPlane(DARK_PLANE));
FastCopyScreen(a + 3840, GrayGetPlane(LIGHT_PLANE));
free(a);
ngetchx();
GrayOff();

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

207

et tu vois, si t'avais utilise une [pub]belle/bonne[/pub] grin norme, t'aurais dessuite vu que ton code puait... triso
dailleurs j'av pas fait gaffe avant de le rendre lisible...
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

208

Oui, mais toi, tu fais exprès. 96 missiles à la fois!?!

c'est une des super-arme smile
(en mode de difficulté normale, il est possible de tirer ainsi 5 fois par niveau...)



avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

209

sBibi a écrit :
#define sprite(x,y,s,p) GraySprite16_MASK((x),(y),16,(s),(s)+16,(s)+32,(s)+32,(p),(void*)(p)+3840)

void   *a;

if (!(a = malloc(7680)) || !GrayOn())
  {
    ST_helpMsg("Not enough memory");
    return;
  }
ClearGrayScreen2B(a, a + 3840);
sprite(1, 1, blabla, a);
sprite(1, 1, blabla, a);
FastCopyScreen(a, GrayGetPlane(DARK_PLANE));
FastCopyScreen(a + 3840, GrayGetPlane(LIGHT_PLANE));
free(a);
ngetchx();
GrayOff();

Oui, mais avec toi, on ne libère pas forcément l'écran virtuel (si l'activation des nvg ne marche pas). Il faut rajouter if(a)free(a); au début (entre le ST_helpMsg et le return).

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

210

sBibi
a écrit : en plus ton goto qui sert a rien.. rholala...

Il sert à éviter de devoir copier les 2 instructions, et donc à réduire à la fois la taille de la source et la taille de l'exécutable.
voila la raison pour laquelle on nous interdit aussi les goto, pour eviter qu'ils soient utilises abusivement comme tu l'as fait... roll

Ce n'est pas abusif, ça évite la duplication de code.

Et puis, comme l'a déjà fait remarquer jackiechan, ton code est faux.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité