Xlib Pang2 Demo + Impression - Page 1

Ca y est g regardé un peu xlib et voila une pitite demo (screenshot+D/L) faite dans la soirée :



http://membres.lycos.fr/aghnar666/download/xpang2demo.zip


malheureusement J'aurais voulu implementer bcp d'autres choses mais a cause de certains probs (cf plus loin) de xlib g pas pu :/

Mes premieres impressions :

_ On ecrit tres tres vite des programmes...

_ on n'a pas l'impression de tout maitrisé, c assez desagreable (m'enfin comme pour graphX ou genlib)

_ Les noms des définitions des fonctions sont peu etre un peu trop nombreuses et compliqués dans leur terminologie, on est tjrs en train de se réfrer au readme...

_ la lib semble assez stable et rapide (+ rapide k'extgraph a 1ere vue)

_ On se retrouve avec une lib batarde puiqu'il y a un linkage statique + une lib dynamique...
c chiant pour le programmer (enfin pour moa en tout cas), je pense k ce serait mieux de laisser le choix pour choisir entre un prog avec ou sans dll dynamique...



GROSSES lacunes de Xlib :

_ pas d'outils sur le site de xlib pour creer des images à partir de .bmp... il faut se rabattre sur des outils supportant genlib comme tipaintplus par ex...

_ pas de fonctions de backgrounds. pas d'outils non plus pour creer (a partir de bmp) les backgrounds "artificiellement" grace aux fonction pic 16x16y de xlib....

_ pas de zoom.

_ pas de routines 8x8 et 32x32 !!!! hmmm ????

_ on peut pas changer de fonte pendant le prog (ou alors, pas facilment : ou est la fonction XChangeFont(*XFont) ?)

_ pas de centrage de texte automatique, pas de format de fonte personnalisable. ( void XLoadFont(*XFont) par exemple)



Vala Vala gros Encouragement à JS !parck avec quelques améliorations, Xlib Rulezzz !

houla !
Xlib semble avoir du succès, pr les démos

en tout cas, je suis d'accord avec toi en gros sur tout ce que tu dis.

Ok merci de tes remarques, je vais essayer d'en repondre a qqs une:

On a pas l'impression de tout maitrisé:

Je ne comprend pas trop la remarque.. XLib est plutot souple d'utilisation, d'ailleur si il n'y a pas de tripble swapbuffering.. c'est pour garder une certaine maitrise du programme.
Apres en comparaison avec Extgraphlib, je les trouve semblable, a savoir que tu n'est pas obligé par exemple d'utiliser le Joypad.. (il est dans l'archive ..)...

On se retrouve avec une lib batarde puiqu'il y a un linkage statique + une lib dynamique... :
Le mixtage des deux est pour une meilleur souplesse de XLib.. a savoir que les fonctions indispensable à X tienne environ 8.5 Ko contrairement à genlib (18 Ko)
Le but de la *.a etant les ajout des fonctions suplémentaire, mais pas indispensable (XPrintf... XJoyPad).
Ce ne fut pas facile de le mettre le format mixte, car TIGCC a vraiment du mal qu niveau linker... mais je pense que c'est le meilleur moyen pour avoir un maximum de rapidité tout en évitant de gaspiller la ram..
Sur ma calc, j'ai deja 2 jeux fait avec XLib (que je vais bientot distribuer)+ XShiper de neuroo et je peux vous dire que le gain en archive est non négligeable (8.5*3=25.5 Ko)
sachant que le seul desavantage etant un peu pres 1 ko pour les appelles de la dll
, qui est compensé car la routine de tigcc fait 1 Ko et qu'elle est dans la dll.

>_ pas d'outils sur le site de xlib pour creer des images à partir de .bmp... il faut se rabattre sur des outils supportant genlib comme tipaintplus par ex...
cela va etre corriger demain. (faut que je les programme)

>pas de fonctions de backgrounds. pas d'outils non plus pour creer (a partir de bmp) les backgrounds "artificiellement" grace aux fonction pic 16x16y de xlib....

j'ai deja programmer un XLevelEditor (qui marchais avec XDrawLevel) , mais je l'ai pas distribuer car je pensais que chaque personne preferais faire son propre moteur... (la lib serai encore moins souple ... et il n'y aurait quasiment plus rien a faire

>_ pas de zoom.
Je pense que cela n'est pas necessaire... sur ti, cela ne serait pas assez rapide pour l'implanter dans un jeu..
Enfin si cela est tres indispensable je peux en faire une, mais je garantie pas un bon resultat (il suffit de regarder les routines de pphd ...)

>_ pas de routines 8x8 et 32x32 !!!! hmmm ????
il y a des routines 32x32... il suffit de prendre le format Pic , mais je l'admet j'ai pas encore eut le temps de programmer l'editeur /convertisseur bmp=> pic.
Pour le 8x8, il y a le format small qui s'en approche.. et la perte de mem niveau graphique est minime , sachant que cela me permet de ne pas inclure une autre fonction dans la dll.. le gain au niveau de la dll est non negligeable , sachant que le small est prevu dans tous les format (transparence maské...) imagine, si il faut les routines 8x8 pour tous ces formats..


> pour les fontes, il faut savoir que j'ai inclus les routines a la va vite dans cette version...
dans la prochaine version, il y aura le choix entre le mode d'affichage, la possiblilit" d'importer d'autres fontes.. comme des fontes perso que l'on peu modifier avec les effets GLOW...
Il manque encore pas mal au niveau de la gestion des fontes et j'en suis conscient.. mais je tenais a sortir XLib avant la fin des vacances

_ on peut pas changer de fonte pendant le prog (ou alors, pas facilment : ou est la fonction XChangeFont(*XFont) ?)
il sera possible de charger plusieurs fontes a la fois.. mais patience

_ pas de centrage de texte automatique, pas de format de fonte personnalisable. ( void XLoadFont(*XFont) par exemple)
cfr dessus.
Pour le centrage du texte.. il suffit de faire un petit macro.. mais il sera ajouter dans le prochain header XLib...

Sinon..
pour les logiciels, il faut savoir que j'en ai programmer un nouveau qui gere tous les formats.. et que Neuroo a debuguer le sien

Voila, sinon merci de tes remaque, je vais en tenir compte

J'ai vérifié pour pas dire de conneries, et les appels DLL font pas loin de 2 Ko, voire 2 Ko tout rond. assez logique, mon RPG est passé de 6 Ko à 9 Ko ( 6Ko avant avec Xlib en static moins approximativement les fonctions d'Xlib : prog pur, et maintenant 9 Ko, avec Xlib en DLL, et environs 1 Ko de code en plus car le RPG a un peu évolué).

Au début de la DLL, je me suis dis (pareilement à Aghnard), qu'il vaudrait mieux l'avoir en static aussi. Mais comme l'a souligné Timad, les moindres fonctions de sprite (XGN et XGM au minimum ds tous mes projets) et les fonctions de plan (création, effacement, copie) prennent au moins 4.5 Ko, donc on economise tout de même 2.5 Ko si on fait plusieurs projets. Car contre il y a d'autres fonctions en DLL que je n'utiliserai peut-être jamais, mais bon, la DLL archivée ne coute rien (8.5 Ko, c pas la mort sur toute notre FlashRom, c'est la même taille que flib1/Vertel, et tout le monde l'a sur sa calc sans se pleindre )

Sinon je suis d'accord avec squale et Aghnard, il manque qq éditeur pour nos sprites et backgrounds, mais comme tu l'as signalé ça arrive bientôt et pour l'instant on a tjs qq logiciels de dépannage

Sinon le zoom, PpHd m'en avait parlé, mais il m'avait dit que les résultats sur CF n'étaient pas satisfaisant du tout, et qu'il avait laissé le zoom de côté, je ne pense donc pas qu'une fonction de zoom soit très utile (en DLL du moins ).

il n'y a pas que les appelles dans les 2 Ko...

y'a quoi aussi ?

bah j'ai dis ça par rapport à un prog sans Xlib, et un prog avec

XOn();

et XOff(); à la fin

bein vi.. mais XOn prend kk octets...

Mais bon dans un prog normal, il faut compter la routine de niveau de gris qui prend 1Ko donc c'est vraiment négligable...

c'est la même taille que flib1/Vertel, et tout le monde l'a sur sa calc sans se pleindre

FAUX !
je n'ai aucun des deux sur ma calc !

Mais tu auras XLib

Bon puisque la bouteille de malibu est vide , je vais repondre à une question avant d'aller coder BrikaX.

"Les noms des définitions des fonctions sont peu etre un peu trop nombreuses et compliqués dans leur terminologie, on est tjrs en train de se réfrer au readme... "

Dans Xlib, les noms sembles compliqué, mais en fait c'est tres simple.
> tous les noms commencent par X car je suis un gros perver.

Pour les sprites/Small:
X
+ le mode de couleur BW ou G)
+ Le type dans le cas d'un sprite G : (N T M)
+ La couleur de transparence dans le cas de T (W B)
+ format

ainsi pour le nom de la routine masqué c'est:
X + G + M + Sprite => XGMSprite
pour un Small en mode transparence avec pour couleur de transparence le blanc:
X + G + T + W + Small => XGTWSmall
Pour un Sprite en noir et blanc:
X + BW + Sprite

)=> toutes les fonctions de sprites sont faciles à retenir.

Pour les pxl :
X + (BW || G) + Pxl + (couleur si Put) + (fonction : Put || Test)
)=> facile a retenir

Pour les plans:
X + fonction (Clr || Cpy) + Type de plan + To (si Cpy) + Type de Plan
exemple:
XCpyGPlanToGPlan
XCpyBWPlanToLPlan..
XClrGPlan

Il y a 2 cas particuliers: LPlan To Plan et non LPlan .. (et celui de DPlan..)

Pour le JoyPad:
XJoyPad(); celle la il faut la connaitre sinon les touche:
Press + . + Touche avec une majuscule.
Exemple:
Press.Esc

Pour Les routines de fonte, je l'admet , elles sont pas évidentes, car le systeme de fonte n'est pas implanter encore correctement mais ca va venir

A R G . . .
Salté de TIGCC ! Un jour je vais le tuer...

squale >>> je parle de ceux encore au lycée, nombreux sont ceux qui ont flib1 et flib2 && || Vertel et c'est 8 Ko pour chacune.

TiMad >> oui, ok, les appels DLL sont peut-être un peu moins gros, mais bon, pour UTILISER Xlib en DLL (l'activer, la désactiver + appels aux fonctions), c'est 2 Ko ou plus.

le zoom serverait juste à rendre compatible les bgs/splashscreens sur les 89/92+ donc pas besoin d'etre rapides...

Cela impliquerai que l'affichage ne serai pas optimisé pour 92...

TiMad, 8> tant que je testerai KII, oui.
une fois que KII sera fini, il est possible que je ne conserve pas Xlib sur ma calc (si le programme suivant que je développerai ne l'utilise pas. je ne sais pas).

tous les noms commencent par X car je suis un gros perver

Ouéééé, je suis pas le seul

Pim> arf, oué, OK.

MDR !!

Aghnar)>XPicEditor est en dl sur le site du X bien sur

cool je v voir

au fait ce serait cool d'avoir des fonctions de bg super rapides comme sur GBA

genre une fonction d'affichage d'une image 240x128 (transparence noire ou blanche) super rapide...(parcque sprite16x16y n'est surement pas adpaté pour ca ...)

ca pourrait faire des scrolls differentiels bien sympa


UPDATE :
Rahhh ton prog de pic editor plante grave kan on veut convertir des images > 32x32 !!!!!!! C fait expres ? en tout cas du cous je peux tjrs pas faire grand chose du coup...

Sinon ce serait cool d'avoir une version dos de ton prog ki accepte des wildcard en arguments (*.bmp par ex) pour faire des conversions à la chaine avec des fichier .bat...

Erf je n'ai pas les connaissance en delphi pour le mettre en mode dos.
Sinon j'aai teste mon programme avec des images 16x32 32x16 32x32, peut tu me donners des info supplémentaire? (l'image en elle meme, le mode choisi.. et comment tu a porcé dé de a à z pour la convertir..)
NB: il faut que ce soit des multiple de 16...
Pour le mode dos, je peux compensé en pouvant inclure une fonction permettant de lire dqans un fichier texte et d'executé...

Pour les bgs, je peux en effet aller plus vite, mais je l'ai pas fait pour des raisons de memoire? (je peux suppromier tout les teste de clipping + les calculs des coordonnées..)
Puis faut il un Bgs mix? c'ad ou l'on peu choisir sont monde de transparence pour chaque SPrite?...

!! ATTENTION !! Il fut utiliser les couleurs de la palette, sinon on se retrouve avec des images B&W..

oui oui g vu je me suis fait une palette sous psp... d'ailleurs c bien chiant de devoir faire la correction "à la main"

Je sais...
Mais je ne suis pas un programmeur pc.. et je suis un peu newbees ...
Je fais de mon mieux... mais neuro devrai venir à mon aide

ca va bientot arriver en pre-beta ...
http://xlib.kouette.com/download/Xss.JPG

neurone >> 404

Neurone>404

Timad>oué demande à olivier martin aussi (tipaintplus)
Sinon pour le DOS y a rien de + facile tu codes un prog console en C (sous Visual C++ par ex)

Note : pour tipaint+, il a juste le format de Mask a demander, car le format XGN (sprite nvg normal) est le même que le plub in "genlib C".
Bon ok y'a toutes les transparences après, mais XGN et XGM c'est les principaux déjà

erf...
Il suffit que je rajoute une palette modifiable apres tout est bon...

Neurone > a kan la 1ere beta de xspritestudio ?

le plus rapidement possible ... ca avance ... ca avance ...