>comptes pas?
>skrnklib < ttstart. Certes, mais sizeof(shrnklib)>0.
je resumerai:
0<shrnklib<ttstart<<ttstart*nombre de programes utilisant un lanceur comme c'est le plus souvent le cas
Kevin Kofler a écrit :
Le mieux, c'est de toujours optimiser en taille. On n'est pas à 1 ms près.
Kevin Kofler a écrit :
Ne t'inquiète pas, j'édite rarement des fichiers on-calc. (Je ne fais presque plus de BASIC.) Et je n'utilise cette précaution-là que si je n'ai pas une copie récente sur PC, ce qui est rarement le cas.
Bah, si tu appelles tios::EM_twinSymFromExtMem, c'est normal que ça ne compile pas pour Fargo.
Mais beaucoup de programmes Fargo peuvent être compilés pour DoorsOS et compatibles avec pas ou très très peu de changements.
C'est de l'émulation parce que les fonctionnalités compatibles sont implémentées en grande partie en temps d'exécution.
Et même si le mode kernel n'est pas tout à fait de l'émulation Fargo (parce que, comme tu l'as fait remarquer, ce n'est pas compatible de manière binaire), c'est de l'émulation d'une plateforme imaginaire qui lui ressemble beaucoup. C'est pour ça que je parle d'émulation Fargo. Et je dis que c'est de l'émulation d'une plateforme parce que le kernel utilise son propre format d'exécutables, pas celui du système d'exploitation, et que c'est une plateforme imaginaire parce qu'il n'existe pour l'instant (en attendant la sortie officielle de Pedrom) aucun système d'exploitation qui utilise ce format d'exécutables nativement.
N'empêche que ça montre que PlusShell avait été écrit avec comme but la compatibilité avec Fargo.
Pas du tout. Ça dépend de si:
sizeof(librairie plus petite) + sizeof(librairie plus grande compressée par la librairie plus petite) < sizeof(librairie plus grande non compressée)
ou pas. Je ne pense pas que ça ait de bonnes chances d'être le cas.
Lui aussi jamais sorti de l'état de "Demo Release". genlib m'a l'air de ne pas être une librairie pour jeux, mais une librairie pour bêtas éternelles.
C'est du vaporware parce que ce n'est pas sorti officiellement.
"ne consommant pas de ressources pour rien" ne veut pas forcément dire "dépassé" ni "qui manque de fonctionnalités". Le DOS est dépassé et manque de fonctionnalités par rapport à Windows ou Linux. Le _nostub n'est pas du tout dépassé et ne manque pas du tout de fonctionnalités par rapport aux alternatives (DoorsOS, FlashApps).
Kevin Kofler a écrit :
Il est lourd en quoi??? Il est très léger! C'est le format kernel qui est lourd!
Ben, Sebastian et moi, on travaille sur un linkeur, donc ça nous concerne quand-même un peu.
Personnellement, j'avais très envie de supprimer le support pour le format kernel avec TIGCC 0.95. Mais pour te calmer: Sebastian l'a déjà implémenté maintenant.
Si, le dérelogement peut toujours être une source d'ennuis supplémentaire. Je retiens qu'il vaut mieux avoir une source d'ennuis possible de moins qu'une de plus.
Tu n'as peut-être pas tord, mais le "startup code" de TIGCC n'est lui aussi utilisé que pour les programmes en C.
Je te signale que c'est déjà nettement mieux que ce qui est fait d'habitude dans les compilateurs C sur PC: ils incluent toujours tout le "startup code", même celui qui ne sert à rien, et il y a rarement un moyen de le désactiver. Nous, on vous laisse le choix de désactiver notre "startup code".
La logique est que, si c'est un ajout indispensable pour éviter un plantage dans certains cas, il est mis par défaut. J'aurais d'ailleurs mis SET_FILE_IN_USE_BIT, et peut être aussi EXECUTE_IN_GHOST_SPACE, par défaut également puisqu'ils remplissent aussi ce critère. Mais Sebastian était contre pour la raison que ces 2 directives prennent beaucoup de place et ne sont nécessaires que rarement. Quant au support pour exit et fonctions liées, il est mis par défaut parce qu'il ne prend presque pas de place et qu'il est nécessaire pour faire fonctionner certaines fonctions de la librairie C standard.
Il n'était pas nécessaire de corriger ça dans le kernel parce que c'est déjà corrigé dans TIGCC.
Je considère le fait que le Doors Explorer ne marque pas sa variable comme en utilisation (cachée) lui-même comme un bogue grave, vu que ça permet les appels récursifs, qui peuvent facilement être source d'ennuis. TICTEX a toujours marqué ses variables comme étant en utilisation. Bref, les explorateurs codés correctement n'ont jamais été victimes du problème en question.
Il suffit de rajouter le "startup code" en question au début, et de rajouter l'offset dans les entrées de la table des relogements. Un patch pour cela est tout à fait faisable. Si suffisamment de personnes y voient un intérêt réel, je peux faire un "startup code adder" automatique, capable de rajouter automatiquement des patches comme SET_FILE_IN_USE_BIT, EXECUTE_IN_GHOST_SPACE, ENABLE_ERROR_RETURN, vérification de la version de AMS et du modèle et même SAVE_SCREEN.
En fait, il n'y en a pas tellement. Certaines étaient déjà là avant (SAVE_SCREEN, EXECUTE_GHOST_SPACE qui est géré par h220xTSR). Un qui me vient à l'esprit: Vérification du modèle. Il y a d'autres kernels qui ne font pas ça. TeOS par exemple. Mais bon, il est vrai que tu n'as pas vraiment copié ça sur nous. Et aussi l'émulateur Line1111.
C'est encore cette attitude-là. Nous sommes pour la compatibilité, nous. Je trouve que c'est du manque de respect pour l'utilisateur de demander un kernel très spécifique. Il n'y a pas de fonctionnalités vraiment indispensables parmi celles que tu as rajoutées. (Je t'ai déjà dit ça plusieurs fois.)
Pour l'instant, nous maintenons la compatibilité avec tous les kernels, et nous ne rajoutons rien qui est incompatible avec les anciens kernels.
Kevin Kofler a écrit :
Encore des trucs du côté du linker. Personnellement, je déteste ça. Et à l'époque, on n'avait pas de système de linking auquel on peut rajouter des trucs du genre facilement. Maintenant, avec le nouveau linker de Sebastian, c'est peut-être faisable. Tu peux le lui suggérer si tu veux.
Mais ça aurait été très difficile à implémenter, surtout avec l'infrastructure de l'époque.
Tiens, tu viens de dire que les librairies dynamiques pour le partage du code sont un désavantage là.
Parce qu'il n'y avait:
- pratiquement pas de ROM_CALLs
- pas de linker supportant les librairies statiques
Les librairies dynamiques étaient donc la seule solution pour rajouter des fonctions indispensables. Maintenant:
- les ROM_CALLs sont exportés et documentés.
- on a un linker supportant les librairies statiques.
Donc les librairies dynamiques ne sont plus nécessaires.
J'ai déjà expliqué plusieurs fois ce que je voulais dire. Et ici, j'ai bien dit "émulation du fonctionnement de Fargo", pas "émulation de Fargo". Je pense que ce que je voulais dire est clair ici.
Et bonne chance pour l'émulation binaire de Fargo.
Ah, parce que ça arrive si souvent que ça que TI sort une nouvelle variante de la
machine avec les touches à un endroit différent.
Il n'y a eu que 2 telles mises à jour depuis la sortie de la TI-92+:
- TI-89 (1998). Et il n'aurait pas suffi de changer les touches dans ta libraire pour que les programmes soient compatibles, vu qu'il y a aussi l'écran qui est plus petit.
- Voyage 200 (2002, 4 ans plus tard).
Statistiquement, la prochaine mise à jour avec un changement important des touches n'est à attendre qu'en 2006.
Mais alors là pas du tout. Avec un fichier de données de type personnalisé, tu obtiens rapidement un pointeur sur les données (avec les ROM_CALLs de vat.h - ça prend 4 lignes de C avec les vérifications de non-nullité), et tu peux faire tout le reste avec des x(an). Si tu n'arrives pas à te rappeller des offsets, utilise des equates. Tu as aussi besoin d'equates pour les "libs read-only" de toute façon.
Tu appelles ça "transparent" d'avoir des fichiers de données avec une extension "ASM"? Pas moi. L'extension "ASM" est faite pour les programmes lançables directement. Les DLLs kernel sont déjà un abus du format, et si on commence par les utiliser pour des fichiers de données, c'est encore pire.
Pourrais-tu développer? Parce que là, je ne vois pas du tout pourquoi on en aurait besoin.
Kevin Kofler a écrit :
Soit tu utilises memmove, soit tu écris une valeur réservée par dessus. Soit encore tu fais 2 tableaux: un tableau de données et un tableau de pointeurs, et tu laisses les données dans le tableau de données, et tu fais un memmove (ou un remplacement par NULL) dans le tableau des pointeurs.
Je ne vois pas le rapport avec la phrase que tu as citée. Je parlais de structures dans la phrase citée, pas de tableaux. Mais j'ai déjà répondu ci-dessus.
Je connais suffisamment le système de handles des TI-89/92+/V200 pour savoir que les longues listes chaînées sont totalement inadaptées à cette plateforme.
Ben, moi je présuppose que le programmeur est une personne intelligente, renseignée et diligente.
C'est pire qu'un ajout au format, c'est un ajout du côté du linkeur.
Tu peux en parler à Sebastian. Le problème est que ça ne marche qu'avec les constantes. Mais pour la plupart de compat.h, ça devrait en effet marcher.
Évidemment, on peut aussi utiliser _rowread directement, mais c'est compliqué, alors que _keytest est très simple.
Ben, il y a quand-même une solution simple: on ne change pas les noms, ou alors on supporte les 2 (un #define en C ou un equate en assembleur suffisent pour cela).
DLL = librairie dynamique. C'est la même chose. Même si on sous-entend souvent "DLL" = DLL _nostub et "librairie dynamique" = DLL kernel, ce n'est pas strictement compris dans le sens des mots.
Parce que c'est un abus du format. Et parce qu'une DLL _nostub est toujours copiée en RAM (il n'y a pas de flag "read-only"), et qu'il serait donc vraiment stupide de faire cela.
Ben, alors, comment l'implanterais-tu (sans changer le linker radicalement - ce n'était pas possible de manière pratique quand le format DLL _nostub a été introduit)?
Si on ne lit pas la documentation ou si on s'appelle TiMad et veut faire exprès d'embêter le monde, alors oui. Mais sinon, non. La documentation dit clairement qu'il ne faut pas faire ça.
Mais je me dis quand-même qu'on aurait vraiment dû mettre la restriction que le programme et la DLL doivent tous les 2 être >32 KO. Sebastian et Zeljko étaient contre, malheureusement.
On ne t'accuse pas d'avoir abusé du format, mais juste de ne pas avoir compris l'intérêt. Tu n'as pas l'air d'avoir lu la documentation. Et puis, il faudra m'expliquer ce qui est "bâtard" dans le format.
mais il me semble qu'il n'y a pas de fonction maskée... de toute maniere là n'est pas le prob..
)
Uther Lightbringer
a écrit : Attends la sortie de GTC avant de supprimer le support du Kernel s'il te plait.
De toute facon si jamais il sort une version de TIGCC sans kernel je garderai l'ancienne.
C'est quand même trop si d'ici la des programmeur ont disparu, on est bon pour convertir les programme a coup d'éditeur hexadécimal voire completement dans la merde si les modifications sont plus importantes. et puis ca peut serir a corriger des bogue aussi
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).
Tu ne fais pas beaucoup de jeux avancés, moi je vais sans doute m'en servir pour un projet que j'ai encore au fond d'un placard. Ca peut par exemple servir a faire des scrollings simplement(dans certain cas particuliers).
Vu le nombre de question auquel tu réponds tu devrais savoir que ce n'est pas le cas
je resumerai: 0<shrnklib<ttstart<<ttstart*nombre de programes utilisant un lanceur comme c'est le plus souvent le cas
BiHi
a écrit : Quand on a entendu ça déjà le débat s'arrête sur les librairies jeux/graphismes. Tout le monde ne fait pas que des Backgammon comme toi, Kevin, ou des jeux de plateaux comme la TICT. Ce n'est pas une critique envers ces jeux, mais certaines personnes veulent faire des jeux de plate-forme, d'action, ou autre, et parfois il est nécessaire de gagner de la vitesse pour pouvoir ajouter des fonctionnalités.
Ensuite comme PpHd le rappelle à chaque fois qu'il y a ce débat, le mode kernel permet de rajouter une couche qui permet de protéger les programmes des incompatibilités liées à ces *** d'ingénieurs de TI. Les programmes de la TICT sont chacun 15 version pour les mettre à jour tout le temps, dès qu'il y a quelque chose de nouveau, sans augmenter les fonctionnalités, juste pour les maintenir en état de marche, comme le prouve la dernière news sur le site de la TICT "I have released various maintenance updates for TICT programs". Au lieu de mettre à jour chaque programme (il faut penser que la plupart des utilisateurs n'ont pas 1 heure à passer par semaine sur leur TI, ils mettent quelques jeux, quelques programmes, quelques cours, et ça leur fait plusieurs mois), seul le kernel est à changer.
Ca serait insupportable à regarder.Thibaut a écrit :
> Si ton Mario ou Sonic met 1 ms de plus pour un saut, personne ne le remarquera. C'est n'importe quoi. Il faut multiplier ta milliseconde par le nombre de frames affichées pendant le saut.
> Et d'ailleurs même un jeu de plateforme très lent, par exemple un Mario en BASIC, peut être jouable. C'est n'importe quoi. C'est beaucoup plus agréable à jouer quand c'est rapide.
Tu crois que CounterStrike, par exemple, se vendrait s'il était à 2 FPSCa serait insupportable à regarder.
PpHd a écrit :
>Ben, s'il n'y a pas de raison, c'est du fanatisme... Ce n'est pas bien. Certes. Mais je ne l'exporte pas.
>>Entre 1 et l'infini, il y a de la marge, tu ne crois pas ? Et 2, 4 ou 5 ? Ou meme 10 ?
>Franchement, vu la taille du jeu moyen qui utilise genlib, 1 est beaucoup plus proche
>de la réalité que 10 dans le cas de genlib (comme l'a déjà dit XDanger, d'ailleurs). Et 2 ?
>>Pas forcement. Elle peut etre tres bien codee mais n'avoir qu'un seul fichier objet.
>Non. C'est une erreur de conception que d'utiliser un seul fichier objet pour une librairie statique. Mais il est vrai j'aurais probablement dû être plus précis et mettre "conçue correctement" plutôt que "codée correctement". On peut ne pas pouvoir faire autrement. Surtout si on fait du self modifyng code pour accellerer les fonctions.
>>J'ai optimise en vitesse lorsque c'etait necessaire. En taille, ailleurs.
>>Il me semble que c'est le mieux non ?
>Le mieux, c'est de toujours optimiser en taille. On n'est pas à 1 ms près. 1ms par unite graphique, ca peut faire beaucoup a la fin.
>>Tu n'as jamais fait de programmation oriente temps reel a ce que je vois.
>Vu qu'on n'a pas besoin d'effacer l'écran très souvent, le nombre de fps ne changera
>pratiquement pas en fonction de la vitesse de la routine d'effaçage de l'écran. Mais 5% c'est deja ca de gagner !
>>Pourquoi ne resete-t-il pas tout de suite alors ?
>>Pourquoi afficher une fenetre suceptible de faire tout planter irremediablement ?
>Là, tu n'as pas tord. Mais au moins il fait l'effort de détecter la condition
>problématique. Je croyais que tu reseter ineluctablement ta calc.
Et ca me parait insuffisant aussi.
>>Parce que le format nostub est trop limite. Le format kernel est bien plus evolue et flexible.
>Traduction: le format kernel est bien plus complexe et lourd. Traduction: Flexible == lourd.
>Et puis il y a quoi qui est plus flexible? Tout ce qu'un programme kernel peut faire, un
>programme _nostub peut le faire également. La preuve: le kernel est un programme
>_nostub. Oui mais c'est plus facile a faire. Et on peut intercepter les appels.
>>1. Le programme ne devient plus "autonome". Il y a 2 fichiers.
>Il est "autonome" dans le sens qu'il peut être lancé directement sans qu'il y ait besoin d'installer quoi que ce soit avant. Donc tu dois dire aussi que certains fichiers kernels sont autonomes (auto-installation).
>>2. Combien de personnes ont grace a cela, plusieurs lanceurs de fichiers type 'ttstart' ? Des milliers ? Surement.
>Et le problème est où? Ils ont le droit de trouver ça plus pratique. Si tu n'aimes pas, personne ne t'empêche de n'utiliser que ttstart ou TICTEX. Le problème ? Une perte de place manifeste.
>>Je n'ai jamais pretendu que le kernel etait pour les noeudnoeuds.
>C'est une des choses que je critique le plus. Ça représente une attitude élitiste et un manque de respect pour l'utilisateur. As-tu deja eu des utilisateurs t'avertir par mail de leur reponse ?
Il faut EDUQUER les utilisateurs pour qu'ils fassent un MINIMUM. Ensuite, reste le debat sur comment les eduquer.
PpHd
a écrit : Mais les autres ?
Et GTC ?
Non. Y'a aussi SYM_ENTRY.sizeof qui n'est pas defini dans Fargo, par exemple. La limite des 32K aussi.
Des fonctions manquantes aussi. DrawCharXY
2. Heu... Dans ce cas, on peut dire que AMS 2.05 est une emulation d'AMS 1.01. Tu t'enfonces la.
Bin. Et les executables windows 3.1, de son temps ? Ils etaient des executables d'une plateforme imaginaire (Rappel Windows 3.1 n'est pas un OS) ?
On s'ecarte du sujet. Et PlusShell oui, si ca te fait plaisir.
Les versions suivantes non. (Par exemple, _exit qui n'est pas supporte par fargo).
Qui te permets de l'affirmer ?
Il faut tester !
Que veux-tu ? Je n'aime pas les versions 1.00 ultra-bugguees.
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.
Et je pardonne aux versions <1.0x leurs bugs.
De facon publique, non. Mais peut-on qualifier ca de vaproware, une distribution restreinte ?
Tu peux ecrire en DOS TOUTES les fonctionnalites qui te manquent pour faire un windows like ou un linux like.
PpHd a écrit :
Mauvais mot. Plutot imparfait, redondant.
Depuis quand tu penses au confort du programmeur ?
>Si, le dérelogement peut toujours être une source d'ennuis supplémentaire. Je retiens qu'il vaut mieux avoir une source d'ennuis possible de moins qu'une de plus. Exemples ?
J'aurais aime : une fonctionnalite == un define (ou plutot un include car les include contrairement aux define ne sont pas soumis aux aleas de l'ecriture). Plutot qu'une fonctionnalite == un retrait parfois.
C'est pas illogique non plus c'est vrai.
Mais le porbleme des erreurs de detection des erruers de syntaxe ?
Et aussi, j'aurais aime que par defaut, ca compile pour 89/92+/v200.
Et les programmes deja existant ? Ils font comment ?
Tu detournes le probleme la.
Ca sera toujours bien plus complique que de le faire en kernel.
SaveScreen: C'est unios qui l'a mis pour faire plaisir a PenPen.
GhostSpace: Inutile en kernel.
Verification du modele: C'est normal dispo depuis la 2nd version du kernel...
Line1111: Bien avant vous !
Mais pour toi il n'y a pas de raisons au kernel, donc ton avis n'a que peu de valeur. Et je ne vois pas en quoi c'est un manque de respect...
Ben un MIN_KERNEL/NO_KERNEL_DETECT assurerait a la fois la compatibilite et les ajouts, non ?
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.)
Si tu veux garder tous les bogues, tant pis pour toi.
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é.
Mais on peut toujours exprimer ces mêmes scrollings en utilisant un écran de taille normale et des routines de sprites clippées.
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).
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.
On ne dirait pas en te lisant.
Peut-être, mais genlib prend plus de 2 fois plus de place que les fonctions de TIGCCLIB (gray.h) et ExtGraph utilisées habituellement.
PpHd a écrit :
Moi non. J'aime bien que le nostub traine ses lacunes comme un boulet
Petits joueurs. Tout le code en mode kernel aurait pu etre reemploye pour le faire.
A la rigueur. Mais les rom_calls c'est pas genial. Elles sont en general pas bien concues. Au niveau SDK.
Tu crois que c'etait difficile pour lui de rajouter ce support
Les romcalls n'offrent pas toutes les fonctionnalites necessaires.
Les libs statiques existaient depuis tres longtemps avec Fargo.
Tu crois que c'est si difficile ? Je ne penses pas.
J'ai deja plus ou moins fait ca car le nouveau format kernel sera ...
du fargo remanie. Plus de fichiers ASM, mais des fichiers PRGM
Oui mais je suis pret moi
1. Ca prend : 0 lignes en C et en ASM.
2. Ca s'eneleve tout seul lorsque tu n'importes plus rien.
3. Pas besoin d'EQUate pour les libs en RO.
Si c'est le cas, alors 5678(a3) est tout aussi clair.
4. Ca consomme aucun registres.
Je connais ton point de vue. Mais c'est trop tard. Elles sont deja lancees dans la nature.
Pretraiter un grand Back-Buffer que l'on affichera apres en clippes.
PpHd a écrit :
<< Soit tu utilises memmove, soit tu écris une valeur réservée par dessus. Soit encore tu fais 2 tableaux: un tableau de données et un tableau de pointeurs, et tu laisses les données dans le tableau de données, et tu fais un memmove (ou un remplacement par NULL) dans le tableau des pointeurs. >> C'est loin d'etre aussi simple !
Mes solutions marchent toutes.
Oui. Tout a fait. C'est le pourquoi de genalib.
Tout est une question de niveaux et de mesure. Ce n'est pas si simple, il me semble de se renseigner la dessus.
Pourquoi pire ?
Oui ca ne marche qu'avec les constantes. Et oui c'est utile.
<< Évidemment, on peut aussi utiliser _rowread directement, mais c'est compliqué, alors que _keytest est très simple. Mais lourd.
<< Ben, il y a quand-même une solution simple: on ne change pas les noms, ou alors on supporte les 2 (un #define en C ou un equate en assembleur suffisent pour cela). >> Certes. Mais tu solutionnes pas vraiment le probleme.
DLL = WINDOWS = MERDE. Non j'aime vraiment pas ce mot de DLL.
C'est un fichier lies dynamiquement aux programmes.
On n'est pas obblige de suivre la documentation.
Difficile a faire.
Et ca ne resoud pas le probleme.
XDanger a écrit :
> Moi non. J'aime bien que le nostub traine ses lacunes comme un boulet 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...)
TiMad
a écrit : pssssssssssssssss qu'est ce qu'on entend pas comme conn***...
Genre les dll.. on en fait ce qu'on veut.. si ca vous plait pas tant mieux!!
heu Xlib est de loin plus facile que Extgraphlib...
comparons les codes:
XOn()
a=XNewGPlan();
XGPlanc(a);
XGMSprite(1,1,blabla);
XWait(Enter);
XOff();
equivalent:
if (GrayOn())
{
if (a=malloc(2*LCD_SIZE))
{
afichietrucmuchsprite(1,1,mon sprite,16,a);
afichietrucmuchsprite(1,1,mon sprite,16,a+LCD_SIZE);// scuse connais pas ces fonctions
free(a);
}
GrayOff(); }
if (!GrayOn()) return;
ClearGrayScreen();
GraySprite16_MASK(1,1,blabla,blabla+16,blabla+32,blabla+32,
GrayGetPlane(LIGHT_PLANE),GrayGetPlane(DARK_PLANE));
ngetchx();
GrayOff();
TiMad
a écrit : bein deja tu dis que Extgraphlib est plus simple d'utilisation alors que c'est faux...
Par exemple, ici, on n'a pas besoin d'allouer un double-plan, on peut utiliser celui alloué automatiquement par le support des niveaux de gris.
Thibaut a écrit :
Kevin > C'est de toute façon le seul compilateur C sérieux disponible pour TI-89/92+/V200 actuellement.
Non. Il y aura bientôt un compilateur sérieux. TIGCC est un compilo TRES sérieux
MacIntoc a écrit :
Euh... pour le fps, je t'arrètes tous de suite. GBS sur 92+ ou sur 89, la différence de vitesse, tu la sent plus que nécessaires
Uther Lightbringer
a écrit : Tu me rassures la.
Je suis pret a parier que les versions a venir auront plein de nouveau bogues aussi
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.
Bah tu trouvera toujours du monde qui ne respectera pas ca!
C'est pas vraiment une solution et perso j'aime pas trop le LGPL.
Dans mon cas précis(absolument pas général) ca serait beaucoup se compliquer la tache et perdre de la place pour rien
Plein de gens ne se posent meme pas la question ppg ou non: ils utilisent le lanceur sans chercher a savoir.
1ms + 1ms +... peut donner un programme vraiment lent.
Si on fait le concourt du plus grand exportateur fanatique Kevin est de loin le roi!
Compare ce qui est comparable: Genlib ne sutilise pas dans le memes condition qu'extagraph et encore moins que TIGCCLIB.