Vous la voulez? - Page 8

Thibeau: Non celemant graphx est plus lente, mais en plus elle ne propose que des routines 16x16 ce qui est lamentable.. alors bon....
En ce qui conserne la taille, je suis pas sur quelle soit bein plus gros que la tienne (cf Gxteste.89z...)

Squale92: Le joypad va etre passer en ASM, il deviendra alors beaucoup plus interessant.
Pour les fontes, t'as pas vues comme elle sont zolie

Le probleme de mettre 7 Ko en statique c'est que ca fait beaucoup... alors qu'une dll ca pose pas trop de probleme car de toute maniere tu utilisera 99% des routines dedans (a part les pxl et le joypad...).

Et ce probleme n'est pas du qu'a X, regarder les executables de GX, vous obtiendrez le mee probleme!

TiMad : quand est-ce que tu arrêteras de raconter des conneries ! sur mon site y'a la doc complète de la lib, y'a le readme, j'ai montré à plusieurs reprises sur le forum le .h (qui contient la déclaration de toutes les fonctions de GX), etc. La doc tu l'as vue. Alors pourquoi tu racontes des conneries ? t'es vraiment bizarre.

Bon puisqu'il faut te prendre par la main : voilà tu cliques ici : http://alineasofts.free.fr/graphx/documentation.htm


En ce qui concerne la taille, je suis sûr qu'un programme utilisant GraphX est bien moins gros que s'il utilisait Xlib, ce qui me fait penser ça c'est tout simplement notre comparatif d'hier, souviens-toi... 340 octets VS plus de 1 ko...


Y'a des fois je ne te comprend vraiment plus

Lol Le Ko je l'ai deduit a l'arrache, mais vue que dans 5 Ko, j'arrive a mettre:
La routine de gray, les routines de plan , les routines XGTWSprite XGMSprite XGNSprite et XBWSprite XGLSprite et XGDSprite.. je crois que tu va vite comprendre que l'erreur relative tend vers 80%...

enfn:
GX_PutSprite08_ER
GX_PutSprite08_MS
GX_PutSprite08_MX
GX_PutSprite16_ER
GX_PutSprite16_MS
GX_PutSprite16_MX
GX_PutSprite32_ER
GX_PutSprite32_MS
GX_PutSprite32_MX


ca fait un peu beaucoup de routine sachant que avec une seul routine sous X, tu peux dessiner un sprite 16x16 16x8 16x24 etc.. ainsi que des image de dim 16x*16x...
Enfin tu comprendras donc qu'il se pourait meme que XLib soit plus optimisée que GraphX niveau ram... (oui car je n'ai pas develloper mes routines entierement pourtant elles sont encore plus rapide que les tiennes .

Enfin Tu attendras la sortie de XLib pour le constater toi meme.. mais je tiens a dire que je n'ai pas envie de sotire des disaines de version donc c'est pour ca qu'avec NeurOO on prend notre temps.

On n'a pas les mêmes ambitions. Tu ne l'as toujours pas compris ?

XGTWSprite, XGNSprite >> késako ?? elles font quoi ???
Je connais que XGT et XGM moi

Bon, TISSHOT saccade à fond, c dommage, c'est bcp plus propre et fluide en vrai, et puis aussi mes map sont merdiques, je vais en ripper des belles d'ici là, y'a juste les def de sprite et le tableau donnant les num des tiles à changer (map externes évidemment, plus rapide à recompiler ). Si vous voulez le voir au mieux de sa forme, DL ce gif pour le voir à partir de votre DD, ça sera tjs un peu moins saccadé.

Elle est pas belle la vie?
Et ca prend que 400 octets (calculer a la bourin, je penche plutot pour 200..).

Croix rouge !

Erf copie l'adresse et vas y...
http://www.ifrance.fr/xlibforever/screen.bmp (pour les flaimars

Faut savoir que c'est généré a partir de la fonte TIOS donc ca prend que 200 octets dans ton prog, tu peux aussi modifier la couleur de remplisage (ici c'est en LGray).

Et il y a d'autres fontes prévues))

erf, sympas ces fontes persos !

cpas des fontes persos, c des GLOW

oups

Si tu veux, dans ton programme t'as pas de fonte, il la construit lui meme par un effet de GLOW a partir de la fonte TIOS.
L'avantage: ca evite de perdre de la place pour une fonte dans un programme..

, j'avais compris

[sondage=13126]
A savoir que si l'on optimise en mem, on pert un peu en vitesse..

Pour l'instant je pense que la DLL va me servir, mais qui sait, j'aurais peut-être besoin d'Xlib en *.a ensuite, faut voir. Les 2 serait le top !!

Au fait, si tu met Xlib en DLL, il faudra expliquer rapidemment comment l'inclure au prog, enfin, il doit bien y avoir des trucs à mettre pour lui dire qu'elle est en DLL.

Au fait, pour les def de sprites, est ce que c'est sur que les définitions sont les mêmes pour la vieille fonction XGSprite16x() (celle que j'utilise en ce moment), et la nouvelle : XGTSprite16x() ??? car je commence à ripper qq map pour mon RPG, et j'aurais pas envie de tout refaire juste car les def sont un poil différentes pour ces 2 fonctions et que du coup le résultat à l'écran est plus du tout le même.

Arggg, pas du tout en fait !

Je viens de mater la def donnée par XSpriteCreator ds le *.c ,et en fait vous bossez sur des "char" maintenant.

cad :

XGTSprite16x() : unsigned char srt[]= {8 1er bits LIGHT, 8 1ers bits DARK, 8 2nd bits LIGHT, 8 2nd bits DARK ...};

alors que moi, avec la version que j'ai, c : XGSprite16x() : unsigned short sprt[]= {16 1ers bits LIGHT, 16 1ers bit DARK , ...};

Du coup tout est faussé pour mes def actuelles (heureusement qu'il y en a pas trop, faudra tout refaire car je peux pas les racoller comme ça étant donné qu'il y a la def du DARK entre 2 groupes de 8 bits du LIGHT).

Bref, vivement la nouvelle version que je puisse enfin ripper correctement avec les bonnes def correspondant aux nouvelles fonctions !!!!

Sinon bravo neurone pour la nouvelle version du créateur de sprite, elle est bcp plus facile à gerer (notamment les mask à creer, un petit carré bleu dans le grand carré, c'est super maintenant ! ) !

extern void XGNSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));
extern void XGTWSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));
extern void XGMSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));
extern void XBWSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));
extern void XGDSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));
extern void XGLSprite(register short x asm("d0"),register short y asm("d1"),register void *XSprite asm("a1"));


ca peut peu etre te servir

toutes les versions

ok, mais ce que je demandais, c'était si les def générées par SpriteCreator était celle à employer avec la dernière version d'Xlib ??

Car les defs sont très différentes de celle d'avant, avant les def, on faisait des groupement de 16 bits LIGHT, 16 bits DARK, 16 bits Mask ect, alors que maintenant ce ne sont que des groupements de 8 bits si j'ai bien compris la def donnée par le créateur de sprite, est ce ça ???

si c'est des groupements de 8 bits, mais que ça donne :
2*8 bits light, puis 2*8bits dark, ...
ça reste bon.
2*8 == 16

le fait que ça soit organisé autrement au niveau de l'écritiure ne change rien au niveau du fichier binaire que te sort TIGCC.
(au pire, il suffit d'un cast ou deux pr pas que le compilo t'agresse)

neurone, tu veux dire que le générateur de sprite donne la def utilisable avec toutes les versions qui ont existé ???

Je t'assure que non, j'ai fait un sprite vite fait maské avec Sprite Creator, que j'ai utilisé avec la "vieille" fonction XGSpriteM16x(), et le sprite était tout déformé, les def de plan se mélangeaient ect !!!!

Bref, il me faut la new version d'Xlib au plus vite !!!

squale92 a écrit :
si c'est des groupements de 8 bits, mais que ça donne :
2*8 bits light, puis 2*8bits dark, ...
ça reste bon.
2*8 == 16

le fait que ça soit organisé autrement au niveau de l'écritiure ne change rien au niveau du fichier binaire que te sort TIGCC. (au pire, il suffit d'un cast ou deux pr pas que le compilo t'agresse)

non non, maintenant c :

{8 bits LIGHT, 8 bits DARK, 8 bits MASK, 8 bits LIGHT, 8 bits DARK, 8 bits MASK ...}

c plus des groupement de 2*8 bits (là ça aurait rie changé je suis d'accord), c'est des "découpages" tous les 8 bits au lieu de 16 bits comme avant !


ex : avant, un sprite 16*16 non maské constitué d'une seule ligne gris FONCE en haut, aurait donné (pour les 2 1ère ligne de la def) :

{
0b00000000,0b00000000, /*16 bits light*/0b11111111,0b11111111, /* 16 bits dark*/
....};

Mais maintenant, avec Sprite Creator, ça donne :

{0b00000000 /* 8 bits light*/,0b11111111 /*8 bits dark*/, 0b00000000, /*light*/ 0b11111111, /*dark*/,
...};

aRf, heu, ben .. heu comment dire ... normalement c bon

y'a qq coquilles mais je v refaire ce demain pour que ce soit bien compatible (avec la nvelle)
> pis je v faire en sorte de pouvoir loader un sprite.c ou .h pour pouvoir modifier car c vrai que c chiant

Ben ok, si la new version fonctionne comme les def données par SpriteCreator, pas de prob, j'attend cette nouvelle version, mais c juste pour dire que maintenant, c complètement != des anciennes versions.

arf, alors si le format de sprites a carément cha gé, c la galère...

D'après le créateur de sprite, c ça, mais j'en suis pas sur, j'ai pas les nouvelles fonctions pour tester.

TiMad, tu l'as programmé, tu dois le savoir, est ce que les def de sprite sont de cette forme à présent, ds la dernière version non-distrib d'Xlib :

{0b00000000 /* 8 bits light*/,0b11111111 /*8 bits dark*/, 0b00000000, /*8 b light*/ 0b11111111, /*8 b dark*/,
...};

???

heu, ca se trouve, c moi qui ait inversé des trucs j'ai pas pu vraiment vérifier car j'arrive pas a compiler avec XLib (je suis le seul ..)

et, vous allez rire, je me suis planté

ha lala

oué ben quand j'ai programmé ca au début je pensais mm pas le sortir