Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Stef]

@troudki>
C'est assez bizarre tes résultats. En gros tu as déjà les fichiers .s des ressources c'est pour ça qu'il ne recompile pas tout.
Par contre vu l'erreur que tu obtiens c'est comme si les fichiers .h générés étaient corrompus ou incorrects, tu peux me montrer le contenu de l'un d'entre eux ?

Sinon je te conseille de ré essayer en faisant un clean avant :

Code:

make.exe -f C:\SGDK\makefile.gen clean

On ne sait jamais

[Tryphon]

Oui le clean est une astuce qui marche souvent

[troudki]

trouvé..
c'est la compression lz4w appelé par rescomp lors d'une compression FAST
j'ai un "unable to access jarfile lz4w.jar" ..
sans compression ça compile jusqu'au bout..

[Stef]

Ah oui, il faut java sur ta machine virtual box.. la compression lz4w utilise un compresseur écrit en java.

[Tryphon]

Question : je veux faire de l'héritage de structures. La façon normale en C est d'écrire un truc du genre :

Code:

struct parent {
   int a;
}

struct enfant {
   struct parent base;
   int   b;
   }

struct enfant truc;
truc.parent.a = 42;
truc.b = 54;


Mais il paraît qu'en Visual C on peut carrément faire :

Code:


struct enfant {
   struct parent; // structure anonyme
   int   b;
   }

struct enfant truc;
truc.a = 42;


ce qui est quand même vachement plus pratique.

Et ça serait accepté par GCC, à condition de compiler avec l'option -fms-extensions.

Est-ce que la version de GCC que tu utilises accepte cette option, et si oui, sais-tu si elle peut avoir des effets secondaires moches ?

[Stef]

Question con mais qu'est ce qui se passe si struct parent et struct enfant ont une variable avec un nom identique O_o ? t'es sur que ça passe ça en Visual C ???

[Tryphon]

Je suppose que tu as une erreur à la compilation.

Non, je ne suis pas sûr que ça passe (je n'ai jamais utilisé Visual Machin), mais c'est tiré d'une réponse acceptée sur Stackoverflow (avec la commande GCC) donc c'est quand même du sérieux

Edit : le lien : http://stackoverflow.com/questions/1237266/how-can-inheritance-be-modelled-using-c

Edit 2 : lien vers la page de GCC sur l'option, qui confirme qu'une erreur est émise en cas d'ambiguité : https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html

[Stef]

Honnetement je n'ai jamais essayé cette option, SGDK est livré avec un GCC en version 3.4.6 donc il faut voir si cette option est supportée dans cette (vieille) version de GCC.
Perso j'utilise toujours des typedef pour les structures pour la lisibilité des déclarations. Je comprends l'intérêt des structures anonymes (dans le même genre tu dois avoir le même genre de chose pour les unions), en quelques sortes ça te concatène tes structures à l'intérieur d'une autre.

[Tryphon]

Oui, ça te permet de faire de l'héritage (une structure qui enrichit une autre). Par exemple, dans mon moteur, j'ai une structure Object qui représente tout objet mobile, avec son (méta)-sprite associé, sa physique, ses fonctions callback, etc.

Mais les combattants sont des Objects assez complexes, avec plein de paramètres dont un objet "normal" (un élément du décor par exemple, ou même la GUI) n'a pas besoin. Je voudrai donc faire une classe Fighter qui étend (hérite de) Object.

Je pourrais tout mettre dans Object et n'utiliser que ce dont j'ai besoin pour un objet "normal", mais ça serait un sacré gaspillage de RAM.

[Stef]

Oui oui effectivement je vois bien la notion d'héritage que ça peut apporter ici, c'est assez interessant pour ça il faut le reconnaitre :) Bon après moi ça me gène pas de "préfixer" chaque accès aux structs même si c'est un peu galère (genre base.xx position.xx player.xx status.xx...) et si ce n'est pas une fonctionnalité très "standard" du C, je préfère ne pas trop l'imposer directement dans SGDK qui peut être potentiellement utilisé avec différente version de GCC, voir pourquoi pas n autre compilo C (même si l'asm inline met déjà tout par terre à ce niveau ^^).

[Invité]

Il me semble que la notion d'héritage n'est pas un concept du C mais du C++ ..

[Tryphon]

@ Stef :
Ça me gêne pas non plus (d'autant plus que le code C est généré automatiquement la plupart du temps par des scripts), c'est juste plus agréable à lire.

C'est justement parce que tu connaissais cette histoire de bug de l'inline que je t'ai posé la question

Moi j'aurais collé du inline partout sans me rendre compte de rien (après tout ça compile)... D'ailleurs ce bug du inline est pour moi de loin le plus gênant : il m'oblige à écrire mon code inliné en macros, et la syntaxe des macros n'est VRAIMENT pas agréable.

Je sais qu'on t'a posé souvent la question de mettre une version plus récente de GCC, et je sais que tu as répondu que les dernières versions produisaient du code moins bien optimisé pour le 68000. Mais j'ai cru comprendre que certaines versions intermédiaires ne se débrouillaient pas si mal, voire pouvaient se débrouiller mieux avec les bonnes options d'optimisation.

Maintenant, n'étant pas du tout un spécialiste des compilateurs et de GCC (ce que je regrette d'ailleurs), je ne suis pas sûr d'avoir tout compris au débat.

Il en était sorti quoi au final ? On peut éventuellement upgrader son GCC sans trop de dommages ? Tu l'envisages dans ta distribution SGDK ? Ou c'est sans intérêt / casse-pieds ?

@ TOUKO : non l'héritage n'est une notion ni du C, ni du C++, mais de la programmation orientée objet. Tu peux faire de la POO avec n'importe quel langage, mais certains ont été mieux écrits que d'autres pour ça. En particulier, le C date de bien avant le concept de POO, et n'est pas du tout prévu pour. Mais tu peux en faire quand même (par exemple, The GIMP, GTK et Gnome sont un bon exemple de code C écrit selon les préceptes de la POO). OK, c'est assez lourd à lire, c'est pourquoi je demande à Stef pour l'option.

Cela dit, le C++ c'est assez lourd à lire aussi

[Invité]

Tu peux faire de la POO avec n'importe quel langage

Oui je sais, mais le sujet était le C, c'est pour ça que j'ai cité le C++, qui est du C orienté objet   .
Mais sinon tu as raison c'est une notion de langage orienté objet,et pas spécifiquement du C++ .

[TotOOntHeMooN]

@ TOUKO : non l'héritage n'est une notion ni du C, ni du C++, mais de la programmation orientée objet.

TOUKO répond à Stef en parlant de C... Et donc que l'héritage est lié au C++ et non au C de base. 

EDIT: oups, j'avais pas vu la réponse. 

[Stef]

Quand je parlais d'héritage, je parlais bien de la notion d'héritage que ça apportait sur la structure en temps que telle, pas du vrai héritage qu'on trouve dans le C++.
Mais comme Tryphon le dit l'héritage est un concept de la POO et bien que le C n'est pas un langage OO rien de t'empêche d'utiliser le concept POO avec même si forcément ça sera moins élégant qu'avec du C++ ou du Java par exemple

@Tryphon> On a effectivement déjà beaucoup discuté de ces différentes version de GCC, il en ressort qu'il y a quand même un soucis avec les versions plus récentes sur le code généré. Tu peux améliorer les choses en utilisant les flags qu'il faut mais tu seras toujours en dessous en terme de performance par rapport aux versions antérieures... et c'est quand même bien gênant je trouve. Après ce bug du inline est mega chiant, pour moi c'est aussi le problème numéro 1 de GCC 3.4.6 :-/
Mais pour l'instant j'avoue ne pas avoir trouvé de meilleur alternative à cette version...

Edit: tu peux toujours changer la version de GCC, il faut "juste" mettre les bons exe avec les bonnes dépendances dans le répertoire bin

[Tryphon]

Ben si je perds en code mal optimisé ce que je gagne en code inliné, c'est pas très intéressant de changer de version de GCC

Est-ce que tu peux m'en dire un peu plus sur ce problème de inline ? C'est lié à la compilation 68000 ou ça déconne quel que soit le processeur destination ? Ce bug est documenté quelque part ? Même avec -o3 ça inline pas ?

[Stef]

Ben si je perds en code mal optimisé ce que je gagne en code inliné, c'est pas très intéressant de changer de version de GCC

Est-ce que tu peux m'en dire un peu plus sur ce problème de inline ? C'est lié à la compilation 68000 ou ça déconne quel que soit le processeur destination ? Ce bug est documenté quelque part ? Même avec -o3 ça inline pas ?

Je ne sais plus si c'est lié au CPU ou pas mais logiquement non, je pense que c'est GCC 3.4.6 qui a un réel bug avec ça. Mais je me souviens avoir investigué un peu à l'époque et j'avais réussi à avoir de l'inline en utilisant des pragmas un peu tordus et ça ne fonctionnait que dans certains cas bien particuliers (fonctions dans la même unité ou quelque chose de ce genre). A voir :
http://stackoverflow.com/questions/8381293/how-do-i-force-gcc-to-inline-a-function

[Invité]

Coucou,


Bon voila, je suis en pleine intégration de mon Terrain avec les différents objets.
J'aurai une question précise et besoin de quelques pistes :

Je voudrais charger en VRAM un tileset (Decor) de ce type :


Il s'agit de 6 patterns de 32x32, soit une image de 64x96 avec une Palette PAL1.

1/ Comment la charger correctement en VRAM ?


Pour ma part, j'utilise VDP_loadTileSet(Decor.tileset,ind,TRUE);
Je ne sais pas si c'est la bonne méthode, bien que j'arrive à voir en VRAM, mes petits Tile. :)

2/ Comment ensuite afficher correctement une pattern de ce TileSet à une coordonnée précise sur l'un de mes Plans ?

Par exemple, je voudrais afficher le Tile N°2 de 32x32 (X,Y ) de taille, aux coordonnées x,y.
Je pensais utiliser VDP_fillTileMapRectInc(PLAN_A,TILE_ATTR_FULL(PAL, FALSE, FALSE, FALSE, ind),x,y,X,Y), mais ça ne m'affiche pas vraiment ce que je voudrais.

Grand merci par avance ! 

Alain

[Tryphon]

Je suis pas sûr de te donner la meilleure réponse vu que j'utilise toujours les fonctions bas niveau (je travaille sur des patterns 8x8), mais pour le 1) j'utilise VDP_loadTileData, et pour le 2) VDP_setTileMapXY (donc j'en écris 4 pour du 32x32).

[Invité]

Merci pour ta réponse.
EfEffectivement en gérant tout ça en 8*8 tel que la gère la MD, le bas niveau s'impose.
Mais moi je souhaite utiliser le haut niveau, Stef s'étant donné du mal pour faciliter la tache aux flemmards que nous sommes. :)

[Invité]

Bingo, j'ai enfin trouvé comment gérer le TileMaping avec les superbes fonctions de haut niveau de SgdK !

Je répond donc, à ma propre question ! 

Donc, pour charger un Tileset 'DECOR' de ce type, qui a été traité par Rescomp via IMAGE :



1/ 

Code:

VDP_loadTileSet(Decor.tileset,ind,0);

( Ou ind est l'indice de référence VRAM TILE_USERINDEX )

2/ Ensuite, pour afficher nos Pattern, utilisez :

Code:

VDP_setMapEx(PLAN_A, MapTile, TILE_ATTR_FULL(PAL1, 0, 0, 0, ind), CoordX,CoorY, TileX,TileY, SizeTileX,SizeTileY);

Alors ... Pour énumérer :
MapTile est la MAP de notre Tileset. Elle est crée grâce à Rescomp.
Il faut donc le définir ainsi :

Code:

Map *MapTile = Decor.map;

( *MapTile sera le pointeur direct de notre TileMap. )

- { CoordX et CoordY } sont les coordonnées ou nos Patterns seront affichées.
- { TileX et TileY } sont les coordonnées de nos Patterns dans notre TileSet.
- { SizeTileX et SizeTileY } sont la taille de nos Patterns. Donc dans notre cas -> 4 et 4 (4*8 = 32 px et 4*8 = 32 px ) !

Voila j'espère que cela aidera d'autres comme moi !

[uran]

Les coordonnées sont-elles toujours en multiple de 8, comme ce sont des tiles et non des pixels?

Sacré codeur du dimanche va;)

[Invité]

Oui copain, les coordonnées sont toujours des multiples de 8 !
Genre 10 et 5 <=> 80 et 40 en coordonnées pixels à l'écran.

Codeur du Dimanche toi même ! 

[uran]

Oui copain, les coordonnées sont toujours des multiples de 8 !
Genre 10 et 5 <=> 80 et 40 en coordonnées pixels à l'écran.

Codeur du Dimanche toi même ! 

Vu comme je galère sur des conneries en ce moment, c'est pas faux :|

[Invité]

Ahah !!

En fait, je n'ai pas vraiment résolu mon problème ... 
Moi qui pensait avoir trouvé ... bref, on verra ça plus tard !

[Tryphon]

Mmmh. J'ai passé 2h vendredi à modifier mon moteur Mugen pour avoir le sprite de Kung Fu Man à la place de celui de Ryu. Le résultat était immonde. 2h à chercher ce qui déconnait dans mon générateur de ressources. 2h à décortiquer les fichiers pcx pour savoir si la palette était encodée en RGB ou en BGR. 2h à regarder dans un éditeur hexa si un recoin du fichier sff ne contenait pas une palette cachée qui m'aurait échappée.

2h !

Pour, au bout des 2h, me rendre compte que j'avais oublié de modifier la ligne :

Code:

self->palette = ryu_palette;

en :

Code:

self->palette = kfm_palette;

Alors réjouissez-vous codeurs du dimanche, y'a des codeurs du vendredi

[Invité]

Ahhhh j'ai enfin trouvé d'ou venait mon problème !! 

En fait : 



Si l'on désire afficher le 2ème Tile ( le bac à fleur ) qui se trouve en X:0 et Y:1, en fait il faut multiplier ces coordonnées par 8 !! Et oui, on manipule des blocs de (8*8) ...
Donc voila, le codeur du Dimanche soir vous salue bien ! 

[uran]

Oui copain, les coordonnées sont toujours des multiples de 8 !
Genre 10 et 5 <=> 80 et 40 en coordonnées pixels à l'écran.

Tryphon, t'es pas tous seul dans ce genre de cas, je fais sous Sublime Text et compile en ligne de commande (c'est un choix qui me va bien). Mais !!! des fois je modifie quelques choses pour ajuster et je lance la compilation, et rien ne change... et cherche, refait l'algo sur papier/excel ... et non c'est bon ... frustration de l'incompréhension ... et puis "HA merde j'avais pas sauvegardé avant de compiler ..."
 

[Invité]

Tsss .. Je pensais que tu me parlais des coordonnées à l'écran, pas dans le TileSet !
De toute manière, demain mode chafouin camarade, comme tous les Lundi matin ..

[Tryphon]

uran : je connais, je code sous Notepad++ (encore plus rustique)
J'en suis d'ailleurs au point que quand rien ne change au lancement de la ROM, mon premier réflexe est de faire un "Save All" et de recompiler. Après seulement je regarde mon algo

[troudki]

hello, 

je suis également dans la manipulation des map et tiles..
j'utilisais jusqu'à présent genres et éditeur mappy (pas assez évolutif comme outil)

Alors ... Pour énumérer :
MapTile est la MAP de notre Tileset. Elle est crée grâce à Rescomp.

c'est quoi une Map structure et surtout comment on le charge avec rescomp .

MAP
---
NOT YET SUPPORTED !
Take an map file as input and transform it in SGDK Map structure.