Une bibliothèque graphique puissante et pourtant simple d'utilisation - Page 4

Thibaut>ben vas-y, vu l'importance de ce qu'il n'y aura pas ... y'a que le convertisseur qui peut avoir une petite importance mais pas pour le debut; pour tester la lib ...

freka> c koi une demo representative de condition de jeux pour toi ?

Ben toute simplement un screenshot de moteur de jeux toute simple, faire defiler un decor avec quelques effets et anims dedans, et c'est tout.
je sais bien qu'un vrai jeu ou programme a une charge bien plus importante liée a la gestion de tout le reste, mais ca n'empeche pas de s'apercevoir des qualités de la lib!

200 lignes de code doivent suffir! mais je parle pas de publier un beta, mais de mettre un screen dans le topic avec le source lié au screen! Il doit bien avoir des exemple, puisqu'il l'a programmé, il a du la testé lui meme!

Comme ca on pourra voir avec quelle aisance on peut utiliser son api dans un exemple concret, et voir si elle tient un minimum le coup

oki

T'inquiètes elle doit tenir le coup vu qu'elle est plus rapide qu'ExtGraph (c'est PpHd qui l'a dit)

>> Il doit bien avoir des exemple, puisqu'il l'a programmé, il a du la testé lui meme!
J'ai un exemple tout petit (celui que vous aurez ) : il n'y a vraiment pas besoin de 200 lignes ce code pour voir si telle fonction marche comme prévu

Thibaut> j'espere en tout cas qu'elle prend pas bcp de place ...

Voilà, démerdez-vous (vous pouviez quand même attendre pour faire les benchs, votre vie ne tient pas à ça ...)
http://alineasofts.free.fr/extern/graphx.zip

Ne benchez aucune fonction de sprites 8x8 ni la fonction de sprites 16x16 masqués : elles ne sont pas encore optimisées.

merci

Je viens de voir que j'ai fait une erreur dans un commentaire vers la fin de l'exemple :
GX_PutSprite16_MX(s_16x16n, x, y); // affichage dans le buffer de travail d'un sprite qui efface tout les pixels sous lui
Il faut lire :
GX_PutSprite16_MX(s_16x16n, x, y); // affichage dans le buffer de travail d'un sprite qui se mélange à l'image déjà présente (OR)

Attention, la variable "_nostub" est exportée à certains endroits de GraphX.a. Dans les fonctions écrites en C, il faudrait rajouter #define _GENERIC_ARCHIVE parmi les directives au début. (C'est peut-être de ma faute: j'avais oublié le '_' du début quand je t'ai parlé de la directive.)

(La variable "_nostub" ne doit en aucun cas être exportée dans une librairie statique parce que soit le programme principal est en _nostub et alors c'est lui qui exporte la variable "_nostub", soit le programme principal est en mode kernel, et alors si la librairie statique exporte la variable "_nostub", il y aura une erreur du linker.)

C'est fait exprès pour forcer le mode _nostub, ça devrait te plaire !

Kevin : Tu avais oublié le '_' c'est de ta faute
Comment tu fais pour voir quels sont les labels exportés ? en ouvrant avec NotePad pour y rechercher (F3) les chaînes ?

qqch me dit qu'il n'a pas renifler son doigt apres se l'etre foutu dans le cul pour trouver ca
ah la la

BiHi a écrit :
C'est fait exprès pour forcer le mode _nostub, ça devrait te plaire !

Thibaut
a écrit : Comment tu fais pour voir quels sont les labels exportés ? en ouvrant avec NotePad pour y rechercher (F3) les chaînes ?

Quand on ouvre un fichier .a dans un viewer/éditeur de textes, on remarque tout de suite les symboles, vu que ce sont les seuls chaînes lisibles.

Ok c'est ce que je pensais ça n'existe pas des "éditeurs" de fichiers archives ?

Ben, ar.
Et tu peux utiliser ar pour décomposer l'archive en fichiers .o, et ensuite objdump pour extraire des informations des fichiers .o. (objdump n'est pas livré avec la distribution binaire de TIGCC, il te faut compiler Binutils à partir des sources pour l'avoir.)

Thibaut> ta lib est une vraie concurrente de ExtGraph ... et plus orientée jeux que extgraph .. c bien

Alors ? par rapport à Xlib tu as mesuré ? et GenLib, ExtGraph ?
Tu as testé quelles fonctions ? tu peux me montrer le code ?

bon, j'ai pas comparé avec EXTGraph ... mais avec XLib !

je fais sur un temps d'à peu pres une seconde ... (USER_TIMER = 20 donc bourin) et j'arrive (avec une vieille version de XLib, sur le pxlput: graphx est a 80% de la vitesse de XLib mais bon ... ca veut pas dire grand chose comme ca ...
ce type de bench ne donne qu'une idée ... pis ct sous VTI .. enfin ... c que du test limite

par contre, je trouve que GraphX est plus compliquée que XLib à utiliser c dommage

Quoi !!!!!! Alors là, explique ce que tu trouves compliqué, parceque je ne vois vraiment pas comment faire plus simple !!!!!!!!!


Sinon ton test ne veut effectivement RIEN dire :
- tu as fait ça sous VTI en te basant sur une int déjà imprécise à la base, alors sous VTI....
- je suppose que tu as testé sur une (V)TI89, alors qu'il faut tester sur TI92+ pour que ce soit comparable (certaines parties de Xlib sont un peu plus rapides sur TI89, non ?).
- enfin, c'est plutôt les fonctions de sprites qu'il aurait fallu tester, pas le PutPixel car ce n'est franchement pas ce qui sert le plus dans un jeu

>j'ais pas dis que c'etait compliqué ... mais que c'etait plus compliqué que XLib ..

> le test que j'ai fait, c'est juste pour donner une idée .... car c'est la même condition de test pour les 2 ...
> XLib travaille pareil sur 92 et 89 .. une 89 est une 92 pour lui ... enfin .. tu me comprends
> ca m'interesse pas trop les sprites

Tu peux dire les choses qui sont plus compliquées que Xlib, et poster les 2 codes sources de tes tests ? merci

de pas bien> pas de transparence pour les buffer de gray (transparence .. on ne sais pas ce qui se passe), exemple, couleur tu pxlput ?????

le code, ca donnait ca;

OSFreeTimer(USER_TIMER);
OSRegisterTimer(USER_TIMER,20);

long jk = 0, jm=0;

OSTimerRestart(USER_TIMER);
while(!OSTimerExpired(USER_TIMER)) {GX_PutPixel (10,10); jk++;}

OSTimerRestart(USER_TIMER);
VGScreen=XNewGPlan();
XGPlanc(VGScreen);
XGOn();
OSTimerRestart(USER_TIMER);

while(!OSTimerExpired(USER_TIMER)) {XGPxlBPut(120,10,2); jm++;}

XDestrGPlan(VGScreen);
XGOff();

Comment ça on ne sait pas ce qui se passe ? je comprend pas ce que tu veux dire

Autrement, je vois que tu as oublié d'initialiser GraphX, tu as dû écrire n'importe où en mémoire

Et ton test me semble encore moins significatif... à ce que j'ai dit au post #108, il faut ajouter : "- tu as testé avec des coordonnées fixes, ce qui peut avoir une influence, surtout avec les sprites, mais peut-être aussi avec les pixels pour Xlib"

c ca les inits:

 GX_HANDLE workHdl;  //GraphX
  short x, y;
  void *VBWScreen = NULL; //XLib
  char buff[3840];
  
  if (!GX_PowerOn())
  {
    return;
  }
  
  workHdl= GX_CreateBuffer();
  if (workHdl == H_NULL)
  {
    GX_PowerOff(TRUE);
    return;
  }
  
  GX_SetWorkBuffer(workHdl); 

je les avait pas mis ici ..
et j'ai mis ca apres le bench de ton putpxl:

	GX_PowerOff(TRUE);

je pensais pas que tu voulais tout le code ...
je me suis planté ???
PS: je n'ai pas testé les sprt


thibaut> je veux dire par on ne vois pas ce qui se passe, c'est: comment je fais si je veux connaitre l'etat du buffer le LIGHT_GRAY ?

HéHé...
Si XLib n'est pas sortit, c'est pas qu'elle n'est pas terminée.. loin de la.. ca fait un baille que le code est terminé...mais faut faire:
La doc
Le convertiseur de sprite
L'editeur de level


ce qui prend pas mal de temps.. pour cela j'ai du apprendre le C++ et le pascal orienté objet.

Sinon niveau simplicite.. ca va etre dure de faire plus facile que X:



void main(void)
{
void *VScreen = NULL;
unsigned short i;

XGOn();
VScreen:=NewGPlan();
XPlanc(VScreen);

for (i=0;i<130;i++)
{
XBWLevel(i,i,&BackGround);
XTLevel(i<<2;i,&ForGround); // format transparence ou alors XNLevel format normal
}

}

et voila t'a ton scroll diff... cet exemple est compilable directement avec TIGCC apres avoir construit la lib avec un programme qui optimise les bcc... en ordonnant certaines primitives de la lib.

timad, faudra qu'on se parle sur IRC pour voir où on en est.

Ca a l'air ces nouvelles fonctions TiMad et nEUrOne !!

>> comment je fais si je veux connaitre l'etat du buffer le LIGHT_GRAY ?

Heu je ne comprend toujours pas, désolé c'est quoi l'"état du buffer" ?

S'il est complement rempli(redessiné) ou pas, je pense!

Tu veux dire s'il est entièrement affiché à l'écran ou pas ?

On n'a pas besoin de le savoir, car GraphX fonctionne avec deux buffers : un buffer de travail et un buffer d'affichage. Il est impossible d'écrire dans le buffer d'affichage donc on dessine dans le buffer de travail, et quand on a fini on appelle GX_DisplayWorkBuffer qui effectue un simple échange de pointeurs.

Pas de problème de synchronisation, donc.