Vous la voulez? - Page 12

J'aurais bien aimé faire ça, mais je ne peux pas , la beta que j'ai eu ne comportais que les fonctions de gray, de plans, et de sprite.

Sinon j'ai enfin rippé une map (l'auberge ,hier soir), ça prend vraiment de la gueule, et j'ai aussi rajouté des animations comme neurone me l'avait proposé (ex : le feu de la cheminée est animé, l'eau sur le lac n'est pas figée, elle "bouge" ).

Sinon la version officielle Xlib devait pas sortir aujourd'hui ?

j'attend neuroo (j'ai la lib, et il a le header )

et j'ai aussi une demo qui marche(rait mieux si j'avais les times avec 4plans de scroll diff, je me suis amusé

vas y, balance !!!!

Sinon TiMad, ça serait cool qu'on puisse les adresses des 2 plans (clair et foncé), avec Getplane(), car comme je disais sur IRC, desfois ça aide bien ...

Ou alors il faudrait trouver une fonction de pic (largeur et hauteur réglables) pour bientôt, ce qui est en préparation je crois

Les adresses c'est simple:
VGScreen=XNewGPlan..

le Light plan c'est VGScreen
le Dark c'est V..+3840..

Mais stp met pas des fonctions tios.. parce que ca rallentit a mort un jeu..

Neurone >> revois les def maskées données par ton créateur de sprite, ce ne sont pas les bonnes (l'affichage est pas bon, TiMad a confirmé)

La nouvelle DLL est très bien , ce qui est dommage c'est de perdre facile 3 Ko pour l'appel DLL et companie. j'étais un peu en dessous de 7 Ko avant cette nouvelle DLL (j'avais juste l'ancienne DLL), et là avec cette nouvelle, le RPG tombe à 9.8 Ko

Erf, si un jour les fonctions sortent pas en DLL, mais en static, enfin au choix, je comparerai la taille des fonctions que j'utilise incluses comparé au appel DLL stocké ds le prog.

Mais bon, l'avantage de la DLL, c'est qu'au moins 5 projets Xlib, c'est que les fonctions ne sont pas stockées ds les 5 progs

Pim89> je c .. je l'avais prevenu :-)

il est plus Open-source ?

PS: TiMad> ça serait possible que tu remette des fonctions de SprtT16x24 et 16x32 ?

le 16x32.. c'est le format pic..
Pour le 16x24.. tu peux emuler la fonction avec un Sprite + 1 small.

moué, mais ça me fait appeler 2 fonctions au lieu d'une (c'est là qu'est à mes yueux le pb )
si j'utilisais les fonctions 16x32 et 16x24, ct justement pr n'en appeler qu'une

bein tu fais ta propre fonction
#define XSprite_Small(x,y,Sprite) { XGNSprite(x,y,Sprite); XGNSmall(x,y,Sprite+16*2*2); }

niveau rapidité.. je pense que ce sera aussi rapide qu'avec l'ancienne fonction.

la fonction XPrintf() marche t'elle ????

j'y arrive pas ... aussi, elle affiche le texte en noir ou en nvg ???

Je fais un
XPrintf(0, 0, "Hello") XCopyGPlanToLCD();

mais rien ne se passe (tt cela est utilisé en dehors de la fonction qui déclare le Gplan, je sais pas si ça a à avoir, enfin .... ).

Arf...
ll faut initialier la str...

XIniDrawStr(F_4x6,GLOW);

et apres il faudra la detruire..
XDestrFont();

Sinon posez vos question dans le nouveu topic XLib.. sinon il va couler

TiMad a écrit :
Je voudrais bien sortir XLib, mais elle marche pas avec la derniere version de TIGCC Je vais la passer en DLL, peut etre que ca va marcher.

nEUrOne a écrit :
le mm probleme que moi ? _rowread_internal ???

Et vous êtes surs d'avoir compilé le fichier .a et le programme avec la même version de TIGCC? Parce qu'il me semble que non d'après la description du problème.
Essayez aussi de remettre la macro _rowread des anciennes versions de TIGCC directement dans votre source, ça devrait résoudre le problème.

TiMad a écrit :
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.

Ce n'est pas du tout le but de notre support de DLLs.

squale92 a écrit :
Je v me la jouer à la Kevin's style :
c'est à ça que ça sert les libs statiques


(sauf que lui l'aurait dit mieux que moi °

Tu l'as bien dit.

nEUrOne
a écrit : oué, c vrai .. mais faut dire que la DLL est bien pratique lorsque vous aurez 2/3 jeux fonctionnant avec XLib sur votre TI ... nan?

Non. Le code de chargement de la DLL prend presque autant de place que prendraient les fonctions elles-mêmes. Si on rajoute les 8 KO de la DLL elle-même, le gain de place est soit totalement inexistant, soit vraiment négligeable.

Pim89 a écrit :
La nouvelle DLL est très bien ,

Pas d'accord.

ce qui est dommage c'est de perdre facile 3 Ko pour l'appel DLL et companie. j'étais un peu en dessous de 7 Ko avant cette nouvelle DLL (j'avais juste l'ancienne DLL), et là avec cette nouvelle, le RPG tombe à 9.8 Ko

En effet.

Erf, si un jour les fonctions sortent pas en DLL, mais en static, enfin au choix, je comparerai la taille des fonctions que j'utilise incluses comparé au appel DLL stocké ds le prog.

Et tu verrais que la librairie statique prend à peu près la même place, et qu'on économise la taille de la DLL elle-même!

Mais bon, l'avantage de la DLL, c'est qu'au moins 5 projets Xlib, c'est que les fonctions ne sont pas stockées ds les 5 progs

Ça ne sert à rien si le code de chargement est (presque) tout aussi gros que les fonctions elle-même.

Le code de chargement est negligeable face a la taille des fonctions!
Sans parler du fait que dans la dll.. on peux optimiser certains sauts ce qu'interdit le linker.

"Non. Le code de chargement de la DLL prend presque autant de place que prendraient les fonctions elles-mêmes. Si on rajoute les 8 KO de la DLL elle-même, le gain de place est soit totalement inexistant, soit vraiment négligeable. "

Bein alors t'as des lacunes en maths..

Puis la dll peux évolué.. les fonctions de levels prennent elles aussi de la place (1.5 Ko max)
mais ca tend vers 10 Ko...

Kevin> c tout a fait ca, timad a DL la derniere version de tigcc et ca a marché de ce jour là

Pourquoi ne pas faire une version en archive alors? Vous dites qu'on doit vous laisser faire une DLL parce qu'il faut laisser les programmeurs choisir, ben alors laissez choisir aussi les programmeurs qui utilisent _X_Lib!

Et pourquoi une dll c'est nulle???

- Ça risque de créer des problèmes de compatibilité entre versions (en particulier vu que tu n'arrêtes pas de changer tout dans _X_Lib - d'accord, ce sont des améliorations, mais tu risque d'avoir des problèmes avec ta DLL).
- Le code de chargement prend de la place (et c'est relativement beaucoup).
- Ça fait un fichier supplémentaire sur la calculatrice qui crée du désordre pour rien.
- Le support des DLLs risque beaucoup plus de devenir incomatible avec un AMS futur qu'une librairie statique. Et inutile de mettre à jour la DLL si le problème est dans le code de chargement (ce qui est le cas de figure le plus probable).
- Tu abuses un système de DLLs qui n'a été crée que pour passer la limite des 64 KO, rien d'autre!

kevin> pke si une personne utilise XLib en 100% archive alors la DLL ne sert a rien du tout ... donc pour garder l'avantage de la DLL il faut garder uniquement la version acutelle de XLib

Alors on vire la DLL.

nan.