oué, mais tu es qd même un boss..
suffit de regarder CF pour s'en convaincre !
PpHd Le 28/02/2002 à 13:52 Il a quoiCf pour que tout le monde ne dise autant de bien.
Y'a rien (encore).
qd je l'ai lancé la première fois, j'ai été ébahit par la fluidité, et la vitesse.
>squale92: pourtant, [le mistub] pourrait être pratique pr faire un explorer qui zippe dézippe que si un kernel est installé
On peut s'arranger sans mistub. Par exemple:
- en utilisant le programme externe ziper.
- si PpHd mettait l'adresse de la table des RAM_calls dans la table des vecteurs. On pourrait utiliser ça pour appeler le code des libs conditionnelles.
- en linkant statiquement ziplib. Je peux le faire pour tictex si on me fait parvenir des sources qui marchent...
Le mistub n'est pas très adapté pour le C parce qu'on ne peut pas utiliser du _nostub et du kernel dans le même fichier avec TIGCCLIB. Donc il faudrait déjà plusieurs fichiers objet et toutes les complications qui vont avec. Et puis, il faudrait adapter non seulement Obj2ti, mais aussi tipatch.lib, parce qu'il faudrait prévoir 2 fichiers principaux: un pour la partie _nostub et un pour la partie kernel. Bref, c'est beaucoup trop de travail pour ce que ça donne.
Et puis, le mistub n'est pas une solution très sure. Avec les anciens kernels (c'est-à-dire tous sauf PreOs), si on lance un programme mistub dans un explorateur en mode kernel, il ne sera pas relogé correctement et ça fera planter tout. Je n'ai pas du tout envie de supporter un format pour lequel il y a un risque de plantage inévitable.
Voilà pourquoi le mistub n'est pas supporté dans TIGCC, et son support n'est pas prévu.
[edit]Edité par Kevin Kofler le 28-02-2002 à 17:27:01[/edit]
Oui, mais plusieurs fichiers objets principaux (2 pour la précision: un pour le _nostub et un pour le kernel), ce n'est pas prévu du tout par TIGCCLIB.
Et il y a aussi l'argument du plantage avec les kernels autres que PreOs.
Et pour finir, si tu y tiens tellement, tu n'as qu'à contribuer le support pour le mistub. Il y a toutes les sources qu'il faut.
[edit]Edité par Kevin Kofler le 28-02-2002 à 17:36:28[/edit]
ah d'accord...
pr le support du mistub... ma fois... je suis po trop doué..
un jour peut-être, qd j'aurai les connaissances appropriée.
PpHd Le 01/03/2002 à 12:43 >- si PpHd mettait l'adresse de la table des RAM_calls dans la table des vecteurs. On pourrait utiliser ça pour appeler le code des libs conditionnelles.
Tu le souhaites ? Je peux le faire (c'est tres, tres rapide).
>Avec les anciens kernels (c'est-à-dire tous sauf PreOs), si on lance un programme mistub dans un explorateur en mode kernel, il ne sera pas relogé correctement et ça fera planter tout.
Pourquoi ? Je ne comprends pas.
Les fonctions exec des anciens kernels ignorent la table de relogements de AMS.
Miles Le 01/03/2002 à 13:15 quand on parle d'Intel...
Pim89 Le 02/03/2002 à 10:27 PpHd >> j'imagine que si squale92 utilise Xlib, c'est aussi parce que C une des lib qu'on peut utiliser en C nostub.
D'ailleurs on patiente tjs pour Genlib utilisable en C nostub. Espérons que ça arrivera un jour.
Non-Webmaster et
non-programmeur du site. .Pour tout probleme ou question ,débrouillez vous avec les
Webmasters .«- Pas Moo ! ^^
et pkoi ne pas utiliser Genlib tout simplement, avec double buffer & Co comme dans les exemples? c simple, très rapide que du bonheur koi!
TiMad Le 03/03/2002 à 12:19 Oui si squale92 utilise Xlib, c'est parce qu'elle est nostub...
Mais bon pourquoi ne pas utiliser genlib... Bein vous verez bien a la prochaine version...
Et d'ailleur, il faut arreter de critiquer.. la prochaine version de Xlib sera presque aussi rapide que Genlib dans le fonctions normale (Oui parce que moi je ne sacrifie pas une couleur => perte de qualité, pour un gain en vitesse ridicule); le moteur Xlib sera plus rapide que ceux que vous pourez faire en GENERAL avec Genlib...
Et puis tout le monde veut des routines super optimise, mais quasiment personne (sauf 5/6 personnes) est capable d'utliser la verion Xlib a fond.. donc arreter de croir qu'une lib va faire un programme... en general la perte de vitesse se fait pas dans la lib, mais dans le moteur que vous n'optimisé pas...
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!
fait gaffe, tes chevilles vont enfler timad...
Je trouve qu'il n'a pas complètement tord non plus.

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.
hu? moi je t'ai donné un conseil? quoi donc? topic X? il est ou celui-la? tu sais moi je suis largué depuis quelque temps puisque je ne programme plus, si tu veux bien me rafraichir la memoire, je heureux
TiMad Le 03/03/2002 à 19:42 C'est carrement vieux...
La technique du shifting sur le plan et non sur chaque sprite...
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!
médor Le 04/03/2002 à 11:54 faut arreter de fantasmer devant chrono fantasy, le programme n'a presque rien, c genlib qui gere TOUT !
Les cartes !!!!
Je dois les retrouver ! :D:D:D
même si ça me fait bine chier, je suis d'accord avec les deux dernières lignes du post 76...
C'est l'algo général du prog qui fait ramer, le plus souvent, pas la lib graphique (je parles en connaissance de cause, et tous les bons codeurs diront la même chose, je penses)
Vark Le 05/03/2002 à 14:29 les chiens ça ne programme pas !!!!!!!!!!!
*** Ne sous-estimez pas la puissance de la Marmotte ***
©
Marmotte Team : LaMarmotte, sBibi, Vark & sabrina