Vous la voulez? - Page 5

erf, désolé Thibaut (même si tu rigolais ) mais je pense (corrige moi si j'ai tout faux) que tu ne pourras pas faire bcp mieux qu'Xlib/Genlib.

Genlib était la plus rapide ect avant, d'après certain bench il parait qu'Xlib est un poil supérieure niveau vitesse (avec la vieille version d'Xlib). Donc Genlib qu'on croyez intouchable a été au moins égalée (voire plus avec ces benchs mais faudrait vérifier ça). Donc bon, faire encore plus que le top déjà fait, bref ...

nEUrOne >> merci

oula, j'ai eu un sale bug avec le prog nEUrOne !!

j'ouvre un sprite 32*32 transparent, et je quitte immédiatement0la fenêtre de sprite avec la croix, et là, boum, le prog cale, ne répond plus. [crtl]+[ALT]+[Suppr] et je le ferme, un écran bleu d'erreur, et finalement je reviens sous Windows (98 SE).
Bref ...

et je viens de refaire pour voir.

Si on ouvre un nouveau sprite 32*32 (jai pas testé pour les autres tailles), et qu'on ferme la fenêtre d'édition du sprite sans y toucher avec la croix, et ben le prog plante, il cale. Sauf que cette fois pas d'écran bleu après Crtl+Alt+Suppr ...

Il doit y avoir un piti problème quand on ferme la fenêtre avec la croix, car avec "Quitter" ou "double clic sur Nouveau", pas de prob.

PS : même bug quand on restaure juste la fenêtre d'édition de sprite, elle se restaure et là le prob plante.

Bon pour Xlib, demain elle ne sera pas prete pour cause perso...
La simple raison, c'est que j'ai voulu ajouter une emulation de MODE comme sur le gab etc.. et que c'etait pas le top...

Sinon pour la prochaine version c'est encore plus simple, d'ailleur ya meme pas de fonction pour effacer l'ecran ou autre.. ou alors elle seront emulée... (sens fig) car l'acces n'est pas directe.. car inutile.

Godzil>
A noter que le memcpy prend quand meme pas mal de temps
sinon tu auras remarquer que si tu testes ton prog certaines touches du JoyPad sont inversées. cela sera corrigé demain.

Sinon pour la difference en spriteN et spriteTW c'est que N toutes les couleures sont dites transparente, et sprite TW seul le WHITE est transparent.

Sinon pour ce qui est d'avoir toutes les couleurs a la fois, ya rien de plus facile, mais c'est completement inutile.. (sur GB, il n'utilise que des transparences..)
Tout ca pour revenir sur le fait que pphd avait raison et que je suis un gros bouffon, mais bon pas grave l'erreur sera corrigée§

Sinon pour les autres, vous avez aussi ce bug avec le prog de neurone ??

je sais bien que memcpy n'est pas optimisé pour sa, mais y auras t'il une fonction pour copier 2 plans comme je le fait dans la version qui sera distribué ??

Pasque mon exemple est bidon, mais sa sert bien quand meme
genre : XCpyGPlanToGPlan(void dest, void src)

TiMad
a écrit : Sinon pour ce qui est d'avoir toutes les couleurs a la fois, ya rien de plus facile, mais c'est completement inutile.. (sur GB, il n'utilise que des transparences..)

Ok, j'avais jamais fait attention, mais c juste par ex pour la demo, sa aurait mieux rendu un sprite non transparent, mais comme je l'ai distri, j'ai betement repiqué le sprite (ta du remarqué lol) et g pas modifié le masque, sa fait qu'il transparent a un endroit (bouuuuuu honte sur moi)

TiMad
a écrit : Tout ca pour revenir sur le fait que pphd avait raison et que je suis un gros bouffon, mais bon pas grave l'erreur sera corrigée

Ha! Qu'est-ce qu'il a encore dit pphd ??? C quoi cette histoire d'erreur ?

Pour la fonction de copie d'ecran.. c'est inutile!!!
Au pire si tu veux faire le meme programme, il suffit de cree un sprite..
XGTSprite mon_petit_sprite;

puis tu rentres tes pxl dedant et tu reaffiches tout. Ton exemple n'est pas une situation de jeu, car dans les jeu, les putpxl ne s'utilisent que pour des effets particuliers...

La fonction de copie de plan va etre supprimée.. parce qu'elle prend de la place pour rien je trouve.. sauf si vous voulez que je la remette..

Pim89 a écrit :
et je viens de refaire pour voir.

Si on ouvre un nouveau sprite 32*32 (jai pas testé pour les autres tailles), et qu'on ferme la fenêtre d'édition du sprite sans y toucher avec la croix, et ben le prog plante, il cale. Sauf que cette fois pas d'écran bleu après Crtl+Alt+Suppr ...

Il doit y avoir un piti problème quand on ferme la fenêtre avec la croix, car avec "Quitter" ou "double clic sur Nouveau", pas de prob.
PS : même bug quand on restaure juste la fenêtre d'édition de sprite, elle se restaure et là le prob plante.

je pense que ca vient de librairie (pas le courage de faire avec une autre .. car pas vraiment trouvé... pis DX c chiant et OpenGL ..) mais je crois que je vais retiré la croix(si je peux) ... car c pas tres propre si on quitte salement

tu utilises CMU?

TiMad a écrit :
Pour la fonction de copie d'ecran.. c'est inutile!!!
Au pire si tu veux faire le meme programme, il suffit de cree un sprite..
XGTSprite mon_petit_sprite;

Et si g un fond "constant" qui change pas (genre une image) on fait comment ?
D'ailleut ya ti des fonction pour afficher une image complete ? (pasque utiliser des sprites pour un fond, c pas super personnelement)

TiMad a écrit :
puis tu rentres tes pxl dedant et tu reaffiches tout. Ton exemple n'est pas une situation de jeu, car dans les jeu, les putpxl ne s'utilisent que pour des effets particuliers...

Ben la c un ca particulier

TiMad
a écrit : La fonction de copie de plan va etre supprimée.. parce qu'elle prend de la place pour rien je trouve.. sauf si vous voulez que je la remette..

Ben de tte, elle prend de la place dans les sources, mais ne prend pas de place dans le code, puisque qu'il ne sera pas copié par le compilot si on l'utilise pas. Enfin fautdrait demander a squale, si il utilise cette fonction

Il y a un format de XGTPic par exemple qui permet d'afficher une image de dimention par exemple:
12624x1248..

Oki cool

En 4gray je supose ?

bein oui
sinon il y a XBWPic pour les image noir et blanc...

erf, et cette beta ??

Si j'ai bien compris aussi, les nouveaux modes de sprites 16*16 seront

XGTSprite16()
XGMSprite16()

(ou 16x16 à la fin)

et qui fonctionneront pour le résultat sur l'écran et pour les def de sprite comme les anciennes fonction :
XGSprite16x()
XGSpriteM16x()

car si le résultat et les def sont les même, ça me fera pas trop de code à modifier par rapport à l'ancienne version

Le probleme etant que je ne sais pas si je remet les routines 16x8 etc.. car ca fait des modif lourde pour pas grand chose...

/me est content il a reussit a patcher proprement la routine de gray de tigcc, et son patche marche que ce soit pour les 4 ou 7 grays

Bon je vais pas tarder a sortir une nouvelle version de XLib, le probleme c'est qu'il faut que je redige la doc en fonction des changement ce qui risque de me prendre 1 ou 2 jours;(

Neurone: il est terminé ton editeur?
est ce qu'il gere le format XGTPic etc?

Si oui, prepare toi a en faire un pour les 7 niveaux de gris)

et essais de corriger les erreur de fenêtre, car le prog on peut pas le masquer non plus dérrière une autre fenêtre (ex : on crée un sprite et on clique sur la fenêtre de yN dans la barre d'outils en bas), sinon quand on revient dessus il est planté

bonne nouvelle: la lib est sous la forme d'un fichier *.a

TiMad> - j'utilise en effet cette merde de CMU
- pas de prob pour les 7 grays
- j'ai rectifier des trucs sur XSpriteCreator mais par contre, le prob de Pim89 ben je c pas comment le resoudre, parcontre, le probleme sur le mask est resolu
- j'ai pas encore fait XGWPic ni l'autre ... mais ca sera pas trop dur a fair,vu que j'avais prevu le coup
- les dialogues sont presque totalement gérés par une declaration comme ca: // la définitions des identifiants #define ID_PERSO1_001 "ID_PERSO1_001" #define ID_DIAG1 "DIAG1" // ... DIALOGUE Dialogue[] =  { // position_x, position_y, texte, identifiant {50, 10,"texte a afficher pour perso1",ID_DIALOGUE_PERSO1_001}, {5, 80,"texte ",ID_DIAG1} } //<-----APPEL----------> XSetDialog(B_TEXTURE3, F_4x4, Sprite_fond, ON); XDialog(ON,ID_DIAL1); //on affiche XDialog(OFF,ID_DIAL1); //on efface

- je peux te filer les fonctions geométriques et les textes pour l'archive


pim89> avec la lib que j'utilise doit pas y avoir de moyen propre ... mais je pourrais toujours essqyer des truc barbares (genre copies a la volée de la fenetre et la recoller ... mais bon ...)
par contre, il est pas planté ... mais il n'est plus affiché

erf, car toutes tes fenêtres tu les gère avec une lib graphique qui plante en fait ??

bah, si tu peux, si tu as le temps, regarde une autre lib qui te permettrait de pas faire planter les fenêtres, car ça va ennuyer plus d'un utilisateur ce problème (même si on s'en sort avec un CTRL+ALT+Suppr ).

Au lieu d'utiliser une lib, utilise l'API Win32 directement!

j'utilise une lib graphique qui gere mal et qu'est lente pour l'instant ..

Kevin> API Win32 et comment je fais pke j'ai pas la MSDN et je suis hors forfait pour l'instant ... mais c'est ce que je vais faire ou alors utiliser DirectX

sinon moi CMU ne plante pas en mode console...

oué, elle doit etre pratique en mode console (peut-etre moins que allegro) mais sous windows ... elle pue quand même ...

d'ailleurs, je vais utiliser Allegro pour windows histoire de voir ..

le probleme ne vient pas de CMU, mais de ta fenetre principale qui gere mal les MSG ..
donc le probleme vient de chez toi

nan, je crois pas.

si tu veux, y'a les sources de dispo dans le rep ... mais je ne pense pas que ce soit ca, le probleme vient surement du fait que c'est d'une fenetre windows classqiuement construite qui appelle la fenetre de CMU ...

t'as qu'a tout faire en cmu ?

d'ailleur CMU gere le doublebuff il me semble.

oui, il gere le double buffer, comment je fais les champs de textes et tout ca ??

pis de toute facon, le prog ne plante pas sauf si on a le malheur de cliquer sur la crox de la fenetre CMU, si on recouvre la fenetre CMU elle n'affiche plus le contenu, c'est tout