Vous la voulez? - Page 10

oki, cool. Si tu peux, un truc que je trouvais dommage sur ton prog, c'est que pour colorer une case, il fallait obligatoirement cliquer dessus (1 clic par case), et on ne pouvait pas faire glisser toute la sourie en maintenant le bouton gauche, sur les cases pour les colorer. Le truc bien à faire serait de colorer tant que le bouton de clic est enfoncé, et non pas colorer quand on clique et qu'on relache obligatoirement dessus.
Tu vois ce que je veux dire ???

oué mais ca c pas moi qui gere, c automatique en utilisant les fonctions que je souhaite utiliser (ca ausi me faisait chiez)

pkoi pas le faire en Java?

oué, je me suis en effet posé la question .. en plus ce serait portable mais bon, pour l'instant, je n'ai jamais prorgammé en java mais ca viendra peut-etre

Ca sort quand ?

Et CF s'en est où ?

nEUrOne, en parlant du XGon (cf page précédente) : oué, enfin, c juste l'initialisation de la lib ... donc si y'a pu de mem, kess tu comptes faire ?

Le gérer par moi-même, pr afficher mon propre message.
Par exemple, dire combien de mémoire le jeu exige, et combien est actuellement disponible (c'est ce que je fais dans KII), ou autre chose du même style.

cela dit, je suis d'accord (et merde, encore une fois !), avec Pim qd il dit qu'il suffit de modifier la foncition, si le code est fourni

erf .. un jour viendra))

non serieux, je termine la dll.

Pour ce qui est de quitter le programme, c'est tout simplement pour des raison de facilité!!!
Vous allez pas traitez a chaque fois les 7 messages d'erreurs! (oui cela ne se limite pas a une simple valeur booleene
En revancghe XOff ne quitte pas le programme.. et vous etes libre de faire ce que vous voulez...

En revancghe XOff ne quitte pas le programme.. et vous etes libre de faire ce que vous voulez...

=> Encore heureux

Pour ce qui est de quitter le programme, c'est tout simplement pour des raison de facilité!!! Vous allez pas traitez a chaque fois les 7 messages d'erreurs!

=> 7 messages d'erreur... hé ben, alors :
* 0 => pas de pb
* de 1 à 7 => pb.
et ensuite, laisses l'utilisateur gérer lui-même son message d'erreur !
la question de facilité, je crois que c pas non plus le plus important : si on est capable d'écrire un jeu qui demande la puissance de Xlib, on est qd même capable de gérer 7 cas d'erreur de par soi-même !

Erf mais ca sert a rien...
les messages sont fait dans une boite TIOS.. une fois pour toute!
C'est ridicule de vouloir reprogrammer ca , sachant que vous ne connaisez meme pas les version de X compatible ou non etc...
Combien de personne va oublier de gerer le Ghost space ? .. etc... apres on va dire que XLib est bugée..

ouerf remarque, il faudrait donc qu'Xlib regarde si y'a eu une erreur (style Xon() ect), et en cas d'erreur grave pour la suite du prog (comme les Gray qui s'activent pas), Xlib quitte TOUT.

NON !
Une librairie ne doit pas avoir un droit de "vie ou de mort" sur l'exécution d'un programme !
Le seul à avoir ce droit, c'est le programme lui-même (et par là, donc, le programmeur de ce programme !)

Récapitulatif:

XOn quitte le prog en cas d'erreur, et ceci sera conservé pour assuré un securité bas niveau.
Apres libre a vous de tester si il y a assez de ram avant l'appele de XOn, apres je m'en fou.
Moi ce que je veux, c'est etre sur qu'un programme ne plante pas a cause de XLib...

TiMad : si je peux te donner un conseil à mon tour, tu fais comme moi dans GraphX : tu ajoutes un paramètre à Xon. Quand l'utilisateur passe FALSE alors tu interromps le programme en cas d'erreur, et quand il passe TRUE tu renvoies juste une valeur indiquant le problème.

c'est inutile.. les msg ne seront jamais apparant.. et si l'utilisateur veux traiter les msg d'erreur.. il peut le faire avant l'appelle de la fonction..

La difference c'est ausi que XLib est en dll, il y a pas mal de cas ou XOn peut planter (ghost space ...) et que l'utilisateur sais pas forcement ce que c'est.. c'est pour ca que si Squale92 veux gerer ses cas, il a qu'a les traiter avant l'appelle de XOn ce qui ne change rien au reste.

Voila le but de la dll:
faire rentrer dans moins de 10ko:

XClrGPlan,
XClrDPlan,
XClrLPlan,
XClrBWPlan,
XGPlanc,
XBWPlanc,
XCpyBWPlanToLPlan,
XCpyBWPlanToDPlan,
XCpyGPlanToLCD,
XCpyGPlanToInvLCD,
XCpyDPlanToLLCD,
XCpyDPlanToLCD,
XCpyLPlanToDLCD,
XCpyLPlanToLCD,
XCpyGPlanToGPlan,
XNewGPlan,
XNewBWPlan,
XGNSprite,
XGTWSprite,
XGTBSprite,
XBWSprite,
XGDSprite,
XGLSprite,
XGTWSmall
XGTBSmall
XBWSmall
XGDSmall
XGLSmall.
+
Routine de grays.

A plus aussi:
XGAMSmall
XGAMSprite.

, c vraiment ces fonctions là qui sont le plus utilisées !

au fait , si les Gplan ne sont plus des buffer plus large de 32 pxl tout autour, comment gères tu le clipping ?????
test pour chaque bits s'il rentre sur l'écran ???

TiMad> l'idée de Thibaut (post 283) est pas mauvaise, au contraire !

Mes idées ne sont jamais mauvaises

Squale92, si tu veux traiter toi meme les erreurs, tu le fait a fond, donc tu fais ta propre fonction qui traite les erreures de XLib...avant XOn...
XLib rend completement libre l'utilisateur.... et n'interdit s pas la gestion des messages d'erreurs avant XOn..

arf, arf, arf, arf, arf, ARF !
mis bon sang ! c plus pratique pr le codeur du jeu de profiter qu'il y ait une fonction qui analyse déjà les erreurs (qui renvoie le code de l'erreur, je veux dire), pr se baser dessus pr afficher ses messages ensuite !

Bon ben écoute squale, te prend pas la tête et utilise graphX : en cas de pb à l'initialisation, GX_PowerOn renvoie FALSE

(bon je veux pas foutre ma merde dans ce topic )

Il y a une diff fondamentale entre ta fonction thibeau et celle de XLib..

Squale92: tu vas me dire que tu ne peux pas tester la ram libre toi meme

d'après ce que tu disais hier, il ne s'agit pas de tester QUE la ram libre...

Le reste des cas c'est en particulier pour aider le programmeur pas les users..

XGAM=
Sprite Maské avec un sprite autogénéré, c'ad une sorte de hallo a la genlike
XGM=
Sprite maské a la tradi..

C'est soit l'un soit l'autre alors fetes le bon choix

[sondage=13131]

Bah moi j'ai déjà dit ce que je trouvais le mieux. Il vaut mieux laisser le soin au programmeur de faire ses propres mask, comme il les veut, aussi tordus qu'il veut, donc garder en DLL la fonction XGMSprite()
Mais par contre, faire une préfonction de calcul de mask ds le *.a comme le fait XGAM, et qui copie la nouvelle def maské (mask calculé) en RAM, et utilise la fonction classique en DLL XGMSprite() pour l'afficher.
Comme ça ça permet de garder les mask qu'on veut, ou bien de les auto-calculer avec Xlib si on veut garder de la place ...

arggg, pourquoi quand je compile le moindre prog (mon RPG, votre exemple ect) avec Xlib en DLL, j'ai tjs l'erreur "GHOST SPACE" à chaque lancement ???!!!!!

Ca vient de quoi ?? j'ai tt le temps ça , avec tous les petits ou gros progs utilisant Xlib en DLL ....

Ca vient de VTI peut-être ?? pourtant j'ai bien la version modifié de JM qui émule le ghost space je crois, donc pourquoi cela ???

TiMad >> ça marche chez toi ?? quel VTI tu as ?