Gdl - Page 3

Si tu voulais faire du pseudo orienté objet tu pourrait simplement avoir dans tes structure des pointeur sur tes fonctions avec une fonction constructeur qui initialise ces pointeur de fonction. Ensuite l'utilisateur pourrait meme raccorder ses propre fonction dans ta lib.

oua ca a l'air pas mal ca
je c pas du tout comment marche les pointeur sur fct, mais mmm en gros si g bien compris, on pourra faire comme du c++, my_map.draw()
mais comment la fonction saura qu'il faut afficher my_map, la fonction acedera au données contenus ds la stucture ou je devrais faire my_map.draw(&my_map) ?

bon, v rechercher mon bouquin sur le C ^^'

lol le Hs login sur le C est pas tres explicite la dessus (en + les listing sont sur le cd qui est heu ... lol) et mon bouquin sur le C doit etre qq part pas loin du cd

par contre c bien expliqué ds mon bouquin sur le cpp
v déjà utiliser les pointeur sur fonction pour utiliser les mm nom de fonction pour le 8 et le 16 bit

mais g tj pas compris comment la fonction saura quelle map afficher sans que je lui donne ^^

Pour déclarer un type de fonction

typedef void (*GDLRender)(void* _pData);

ensuite tu déclares une structure

typedef struct
{
GDLRender* Render;
void vDummy;
}GDLMap;

Tu écris tes fonctions de rendu

void GDLMapRender8(void* _pData)
{
...
}

void GDLMapRender16(void* _pData)
{
...
}

tu crées une fonction constructeur

GDLMap* GDLMapNew(u32 _u32Mode)
{
GDLMap* pResult;

pResult = malloc(sizeof(GDLMap));

if ( _u32Mode==8 )
pResult->Render = GDLMapRender8;
else
pResult->Render = GDLMapRender16;

return pResult;
}

void GDLMapDelete(GDLMap* _pMap)
{
if ( pMap!=NULL )
free(pMap);
}

Et finallement l'utilissteur a juste a faire

GDLMap* pMyMap;

pMyMap = GDLMapNew(16);
pMyMap->Render(NULL);

GDLMapDelete(pMyMap);
pMyMap = NULL;

Pour le probleme de recupere le "this" de la classe je pense qu'il faut pas faire tres compliquer et simplement le redonner en premier argument. C'est redondant, mais c'est la meilleur et la plus simple solution.

typedef void (*GDLRender)(void* _pThis);

De tout facon la meilleur solution c'est tout de meme d'ecrire tout ca directement en C++ au lieu d'emuler une pseudo version.

moi je dis la gdl ets tres bien faites et simple d'utilisation vive rov ^_^

merci pour le cour :-)

mais si il faut remettre l'adresse de la map, l'interet est plus que limité :/

MrPomme -> elle est pas si bien faite que ca, y a des truc que j'aime pas dedans...
a la base ct pas une lib, juste des fonctions de colision crées pour NoiDz
donc elle a pas été pensée comme une lib... et c pas cool ^^

rov :
mais si il faut remettre l'adresse de la map, l'interet est plus que limité :/

Ah ca, j'ai jamais dis que c'etait la facon ultime de programmer, c'est juste que c'est une facon de s'approcher de la facon de programmer en objet. Ca quand meme ses avantages genre un code plus clair a lire et aussi un code facilement tweakable par l'utilisateur sans etre obliger plein d'appel a des fonction partout dans le code.
Moi personnelement, je prefere programmer en C pure avec une bonne nomenclature comme tu l'as fait jusqu'a maintenant, mais c'est pas du tout de l'orienté objet ^^.

voila la 0.4f qui viens juste de sortir,
c tj pas de l'orienté objet mais gdl gere maintenant le format pcx, ainsi que l'affichage de menu & MsgBox

ca se trouve tj la : http://procvor.free.fr/gdl/

vala vala :-)

(06:04) r0v43v<=======oua moi je dort juska 11h le dimanche

rov est un vampire

mouhahah super brvao rov felicitation aisniq ue tout ceux qui y ont participé

oua il etait enteré profond ce thread ^^

bon, je suis en train de reecrire completement Gdl, en C++
et j'aimerais bien savoir ce que vous trouvez po cool ds la premiere mouture et ce qu'il y manque ... :]

Tout d'abord je suis pas un codeur, mais à ce que j'en sais :

Manque la gestion du son (mods, wav... ) ce serait bien
Pour les wavs uen gestion par piste.. genre 4 pistes ?
genre un "
loadwav(1,"gp://gpmm/gp/musiquedefond.wav);
loadwav(2,"gp://gpmm/gp/bip.wav);

playwav(1);
play(2,"gp://gpmm/gp/bip.wav);
"

Les sprites avec une couleur de transparence.. c lent...
Ce serait bien une fonction pour le degrés de transparence des gfxs en mode 16bits ( genre 50% )
ainsi qu'une belle fonction de zoom. pareil en pourcentage ?
et aussi pour cette fonction de zoom, ce serait bien pour le systeme d'affichage de sprite deux options suivant l'affichage de sprite, soit que le zoom soit axé sur le centre du sprite ou sur "en haut à gauche" du sprite.
C'est juste une idée.
Et enfin une fonction de rotation de sprites


Sinon pour les médias, intégré un systeme pour lancer les fichiers FLC, les fichiers d'animation de kof qui sont en fait des gifs animés. Format hyper interresant pour les intros ou les anims etc..
Ou bien carrément la prise en charge des gifs animés. ( avec un systeme d'affichage du temps écoulé pour l'anim et pouvoir y caller des sons au bon moment comme dans une timeline.. )



Bien sûr c le rêve tout ça

Sinon je dois dire que j'utilise certaines fonctions du GDL actuelle donc merci déja

Merci pour ton boulot ROV ^^

oui aussi une fonction toute faite pour automatiser le préchargement de fichiers externes si c'est possible...

tu me poses la question je réponds voila

pour les wav et mod, je connais rien du tout au son, mais les wav serons un jour suporté, pour les mod il y a la lib de chn

> Les sprites avec une couleur de transparence.. c lent...
plus ds gdl2 :]

pour le zoom et la transparence, ca sera géré mais plus tard
pour les rotations, vu comment fonctionne la lib ca va etre chaud si c pas pour faire du precalcul mais bon, c possible

gdl 2 est prevu pour charger/enregistrer ds de multiple formats, donc le flc pkoi pas, mais ca utilise Huffman donc heu ca sera pas ds la premiere mouture lol
les gif, animés ou non, pareil
par contre il y aura un format de fichier special

> avec un systeme d'affichage du temps écoulé pour l'anim et pouvoir y caller des sons au bon moment comme dans une timeline..
ca c pas con, ca sera suporté, pas ac le temps mais ac le numero de frame, et ca lira pas du son mais pourra executer une fct

> oui aussi une fonction toute faite pour automatiser le préchargement de fichiers externes si c'est possible...
g jamais essayer d'utiliser des thread sur gp, si j arrive, ui ca sera suporté :-))

enfin bon, tout ca c du haut niveau et ne sera pas suporté à la premiere release, qui se contentera de gerer les animations, sprites et fontes, avec chargement/save/affichage et sans colision ni clipping sur y :]

bien sur qu'il y a la lib de chn mais l'intégrer à GDL ce serait bien d'office ^^ un pack tout prêt quoi

ok bah c cool merci pour ces réponses et donc : Vivement comme on dit !!!

Bon courage en tout cas

merci :]

integrer la lib de chn n'est pas une mauvaise idée, ca sera surement fait.

si la lib de chn est integré, faut savoir que ca ne sera plus compatible avec certain compilo, de plus, faut integré la lib directement, et sdt ne le supporte pas. et oui, beaucoup sont sous sdt, faut aussi penser a eux

erf ui sdt, surtt que moi aussi je suis sous sdt :]

de tt façon, ca sera surement en c++, donc exit sdt ^^
et puis un petit #define desactivant le support du mod c pos tres dur a faire

dsl de débarqué, mais j'aurais bien aimé quelque fonctions, ptet qu'elles y sont déja maintenant....

-Lecture OGG Vorbis
-Rotation(ou table de cos/sin préintégré)
-Zoom peut etre, ce serais chouette non ?

c déja demandé mais c pas prévu pour tout de suite il parrait ^^

[sondage=14511]

Bah oui comme meme, question d'habitude ...
Pour les ports de jeux deja sdkifies aussi ......

c vre que au debut je croyais tt le tps que le max pour y etait en haut franchement vi met le en bas c plus logique

oui et non mais g repondu oui^^

faut respecter la norme, pas commencer a faire a sa guise hein


en haut a gauche, ca doit rester ainsi.

je fait en fct de ce qui est rapide, pas de la norme

de tt façon, les fct de blit aurons comme argument l'adresse ds l'ecran a la position bas gauche du sprite
et il y aurra des fct calculant cette adresse a partir de coordonnées normale ou inversée

ca me fait marrer la norme, qui code a la norme ANSI ici? Alors arretez un peu avec la norme.

moi

iceman
: moi

il est ou le smiley clapclap #clap#

bah moi aussi je code ansi, a part pour les commentaire // et ptet les definitions de stuctures
mais bon, que le haut a gauche soit 0.0 je pense pas que se soit ds une norme ^^

Ce n'est pas une norme, mais une question d'habitude/de logique héritée du hardware.
C'est presque aussi important.

Rov, tu peux expliquer pourquoi tu voudrais inverser l'axe des y ?