XOn() a=XNewGPlan(); XGPlanc(a); XGMSprite(1,1,blabla); XCpyGPlanToLCD(); XWait(Enter); XOff();
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();
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?
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.
Ben, il suffirait d'envoyer des cease-and-desist menaçant une action légale, parce que ça serait illégal.
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.
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!
Mais quand on est dans l'ordre de grandeur des millisecondes (et plus des microsecondes), on a déjà fait la somme!
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.
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.
Kevin Kofler
a écrit : Mais ce "moment", ce sont les 10 FPS dont on parle.
LOL
TiMad
a écrit : On reprend parce ca devient vraiment n'importe quoi.. on veux afficher 2 sprites maskés avec un VS:
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();
#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();
Uther Lightbringer
a écrit : Qu'est ce qui te fais croire que je n'utilise que TIGCCLIB
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
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
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.
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.
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.
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.
>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.
Tu as déjà vu un Mario avec 20 ennemis qui sautent en même temps, toi?
, 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, ....
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 !
>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.
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".
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
.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
>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.
>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.
>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 !
>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.
[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 ?
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 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.
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 ?
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.
>Ç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.
Désolé, j'ai raté cette erreur en me relisant. 
Mais tu ne l'as pas remarquée, toi non plus.
>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 ?
>C'est un hack qui tourne autour du problème au lieu de le résoudre à sa base.
Un hack ? Ou ca ?
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.
>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.
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.
>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, 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 ?
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.
xeno
a écrit : Putain, plus je lis ca, plus j'a envie de prog en kernel!
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, 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, ....
96 missiles à la fois!?!
Mais, tu vas dire que c du vaporware, vu qu'il n'y a pas eu de bêta publique
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)...
Kevin Kofler
a écrit : 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.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]
(c'est XDanger et moi qui l'avons écrite)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.
#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();
()
#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();
norme, t'aurais dessuite vu que ton code puait...
Oui, mais toi, tu fais exprès. 96 missiles à la fois!?!
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();
sBibi
a écrit : 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...