Re: [ Demo Disponible !] - Papi Commando Tennis Megadrive - SGDK

[ShiningBZH]

J'adore les nouveaux sons et j'adhère au délire du texte comme je te l'ai dis sur Facebook ! Par contre comme les 2 avis précédents , je pense qu'il faudrait que se soit " ponctuel " une petite punchline en entrant sur le terrain , une autre à la moitié de la partie et le coup de grâce à la fin ( énervement du perdant dégoulinant de sueur :) )

[grostonton]

Je suis plutôt de l'avis de ShiningBZH, l'idée est vraiment bonne, mais à inclure plus à la manière d'un jeu de baston (avant, peut-être pendant, et à la fin). Comme dit aussi plus haut, ce n'est que mon avis ^^

[Invité]

Coucou,
Merci de vos avis !
Oui c'est vrai que c'est super lourdingue, c'est du WIP et c'est en plein chantier !
J'ai passé des heures pour réaliser ces 2 3 merdes, imaginez un peu !!
J'Ai vraiment ma vision du jeu en tête, ça va être un truc complètement différent des autres jeux, enfin pas tant que ça, mais ce de l'homebrew manouche 100% maison.
Bref, on verra bien ... De toute manière, l'important c'est l'ivresse de la création et je suis en plein dedans !! 
C'est fou le temps qu'il faut pour chaque petite chose : des heures pour les 3 personnes sur l'herbe, les dessiner, les animer, optimiser leur palette, les placer à l'écran, gérer l'événementiel, etc ...
L'oiseau, c'est 2h, les fenêtres et sa fonction presque 10h et c'est pas fini.
Les sons, animation des avatars 2 3h ... 
Sans compter à comment mettre tout ça en place, quand comment pourquoi ... Est ce que ça vaut le coup ??
Peut être pas, mais moi ça me fait marrer !!
Étant je suis encore loin du but final ... Ou la, le truc de ouf 
..
Mais tant que j'ai l'envie et surtout l'inspiration, je continue !

[TotOOntHeMooN]

[drfloyd]

de petits dialogues ca peut etre sympa, mais façon Strret Fighter II, et au debut du set, au changement de coté, ou à la fin du match. Et ca doit etre très court.

[Invité]

Coucou,

Ce soir j'ai réussi à optimiser la fonction qui me permet de créer des fenêtre de dialogue à la volée !!
( J'ai embêté Stef pour rienG .. Quoique !   )
Du coup, elles s'affichent à la vitesse de l'éclair quelque soit leur taille ...
Car sur la vidéo, on voit nettement que ça ramouillait un peu.

Merci la magie du C et de ses pointeurs qui, je le reconnais, ne me sont pas trop familier, enfin un peu .. petit à petit !!

Pour information, SgdK permet de compresser une Image pour un gain de place.
Cette image possède une Structure { Compression, TileSet, Map } et chaque élément possède aussi une structure ... 

Bref, quand on ne fait pas attention et que l'on veut afficher des éléments d'un Tileset, ça fonctionne, mais la routine va décompresser à chaque fois qu'elle est appelée. D'ou un gaspillage de cycles.

L'idée est de pointer l'adresse de la structure intéressée et décompressée.
Un peu comme ceci :

Code:

Map *Wind=unpackMap(Windows.map,NULL);

Map étant la structure, on va donc pointer l'adresse Windows.map qui a été préalablement décompresser, dans Wind.
Ensuite, c'est en mémoire et la balance dans notre routine d'affichage ...

Ne pas oublier ensuite, de libérer la mémoire quand on s'en sert plus !

Code:

MEM_free(Wind);

Voila, le gitan du C vous salue bienG ! Olé ! 

[Tryphon]

Comprendre exactement ce qui se passe dans la mémoire, et comment utiliser les pointeurs, c'est clairement pas évident (encore aujourd'hui parfois je me rends compte que j'ai fait une copie de struct sans faire exprès).

À la limite, c'est presque plus simple en assembleur parce que t'es obligé d'appeler les routines de décompression. C'est juste 15 fois plus long !

En fait le C c'est trop simple

[Invité]

Ahah !!
Oui en fait l'assembleur permet d'avoir la vue concrète du code mais au microscope électronique. 
Le C que je redecouvre, permet justement de jongler un peu avec le bas niveau avec les adressage mémoires. 
Le fait d'avoir fait un peu d'ASM aide beaucoup en tout cas ! :)

[Invité]

Je vous partage ma petite fonction qui permet d'afficher des belles fenêtres sur mesure  avec Sgdk !
Ca fera office de tutoriel ...

I/ On créer notre image



C'est une image 48x48 pixels, comme vous le voyez, c'est notre fenêtre entière !
Chaque case fait 16x16 px.

II/ On déclare tout ça dans notre ficher .res

Code:

IMAGE Windows "gfx/Fenetre16x16.png" -1

Je l'ai nommé Windows, ce qui suit ensuite est le chemin de l'image.
-1 étant le niveau de compression.
IMAGE, c'est la structure !

III/ La fameuse fonction 


Après avoir déclarer et créer une structure MaVariable 

Code:

 /* Structure MaVariable*/
  typedef struct
  {
    u16 TempoWindow;
    u8 DisplayWindows;                  
  } Mavar_;
  // Construction Variable
  Mavar_ MaVariable;

Code:

void Fenetre(u8 Largeur,u8 Longueur,u16 PosX,u16 PosY,u16 Tempo,u8 Text)
{
    u8 i=0;
    u8 j=0;
    u16 ind=TILE_USERINDEX;

    // Tempo d'affichage de la fenêtre
    MaVariable.TempoWindow++;

    // Affichage de la fenêtre  & Gestion
    if (Mavariable.DisplayWindow==0)
    {

        // On va pointer l'adresse de notre MAP !
        Map *Wind=unpackMap(Windows.map,NULL);

        // Affichage de la fenêtre sur le Plan A avec la Palette No3.
        VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX, PosY, 0, 0, 2, 2);
        VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+Longueur, PosY, 4, 0, 2, 2);
        VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX, PosY+Largeur, 0, 4, 2, 2);
        VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+Longueur, PosY+Largeur, 4, 4, 2, 2);
        for (i=0;i<Largeur-1;i++)
        {
            for (j=0;j<Longueur-1;j++)
            {
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+j+1, PosY+i, 2, 2, 2, 2);
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+1+j, PosY, 2, 0, 2, 2);
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+j+1, PosY+Largeur, 2, 4, 2, 2);
            }
            VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX, PosY+i+1, 0, 2, 2, 2);
            VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+Longueur, PosY+i+1, 4, 2, 2, 2);
        }
        // On libère la mémoire
        MEM_free(Wind);
        Mavariable.DisplayWindow=1;
      }

    if (MaVariable.TempoWindow>=Tempo)
    {
        TerrainTennis.TempoWindow=0;
        TerrainTennis.DisplayWindow=0;
        // On efface notre fenêtre du plan A
        VDP_clearTextAreaBG(PLAN_A,PosX,PosY,Longueur<<1,Largeur<<1);
    }
}

Voila !! Simple non ??

Tout est dans le secret de la fonction : VDP_setMapEx !

Je cite le Wiki de Stef :

u16 VDP_setMapEx	(	VDPPlan	plan,
		const Map *	map,
		u16	basetile,
		u16	x,
		u16	y,
		u16	xm,
		u16	ym,
		u16	wm,
		u16	hm
	)

Load Map region at specified position.
Parameters:

plan	Plan where we want to load Map. Accepted values are: PLAN_A PLAN_B PLAN_WINDOW
map	Map to load.
basetile	Base index and flags for tile attributes (see TILE_ATTR_FULL() macro).
x	Plan X destination position (in tile).
y	Plan Y destination position (in tile).
xm	Map region X start position (in tile).
ym	Map region Y start position (in tile).
wm	Map region Width (in tile).
hm	Map region Heigh (in tile).

Load the specified Map region at specified plan position.
See also:VDP_setTileMapDataRect()VDP_setTileMapDataRectEx()


En fait, c'est une fonction très puissante qui permet de faire du TileMapping ... Utile pour l'affichage et gestion de MAP de grande taille (1024x1024 par exemple ! )

Et le truc pour gagner en vitesse, c'est Map *Wind=unpackMap(Windows.map,NULL);

Par contre, il ne faut pas oublier de libérer la mémoire avec MEM_free.
Après, je ne sais pas si à l'issue de la fonction, la mémoire est libéré du fait que c'est une variable locale, mais on ne sait jamais.

Ma fonction est ensuite enrichit de pas mal de petites choses comme l'affichage d'une chaine de caractères, d'avatar animé, etc ... 
Libre à vous de l'embellir.

Par contre, même si c'est rapide, sur des tailles importante, l'affichage n'est pas instantanée !
Sans être lent non plus !
Je pense que là, il faudrait peut être, faire une routine 100% assembleur, à moins que l'on puisse encore optimiser la fonction, je laisse ça aux spécialistes.

Enfin voila, je voulais vous faire partager mes petits travaux du soir ! 

[TotOOntHeMooN]

Mais non, c'est un filtre écran Vectrex ça ! 

[Tryphon]

Code:


        for (i=0;i<Largeur-1;i++)
        {
            for (j=0;j<Longueur-1;j++)
            {
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+j+1, PosY+i, 2, 2, 2, 2);
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+1+j, PosY, 2, 0, 2, 2);
                VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), PosX+j+1, PosY+Largeur, 2, 4, 2, 2);
            }
        }


Tu peux déjà optimiser un peu en :

* ayant des variables x et y que tu fais démarrer à PosX + j et PosY et que tu incrémentes dans ta boucle, pour éviter d'avoir à refaire les calculs à chaque fois (et une troisième pour PosY + Largeur, encore qu'avec un peu de bol le compilo détecte qu'elle est constante dans la boucle et optimise en conséquence)

* en faisant tes boucles "à l'envers" (de Largeur vers 0) : en asm 68000 le compilo utilisera des dbra, plus rapides.

Mais bon, premature optimization is the root of all evil, comme disait quelqu'un que j'aime bien...

Aussi, pour des ressources aussi petites, je ne suis pas sûr que la compression soit vraiment utile (litote). Du coup tu stockes tes datas directement en ROM et tu peux les copier depuis la ROM.

[Invité]

Je pense que si tu affiches ta fenêtre en utilisant la window ça serrait surement plus rapide et simple .

[Invité]

La seule phrase que j'ai cru comprendre, c'est celle de Tot' !! 
Ahah !!
J'ai le cerveau ramollit moi !! 😷

[Tryphon]

Pourtant je me relis et il me semble que c'est clair. Tu préfères du code ? Je suis sur Smartphone et c'est chiant à taper mais si tu veux, quand je récupère l'ordi...

[vingazole]

* en faisant tes boucles "à l'envers" (de Largeur vers 0) : en asm 68000 le compilo utilisera des dbra, plus rapides.

A mon avis le compilateur optimise déjà les boucles, sinon bonjour le compilo tout pourri !

[grostonton]

Je n'ai pas la prétention d'avoir saisi un quart de la discussion lol, il n'empêche c'est super sympa à toi d'expliquer comment tu fais !

[Invité]

Merci copain !!
C'était le but à la base en fait ...

[Tryphon]

* en faisant tes boucles "à l'envers" (de Largeur vers 0) : en asm 68000 le compilo utilisera des dbra, plus rapides.

A mon avis le compilateur optimise déjà les boucles, sinon bonjour le compilo tout pourri !

Je peux te certifier que cette optimisation, il ne la fait pas (primo c'est une astuce assez connue, deuzio c'est pas si évident à optimiser - par exemple si tu utilises la valeur du compteur de boucle dans des calculs, tu ne peux pas la faire ou alors il faut modifier ton calcul, tertio trimo j'ai regardé le code compilé )

Vetea : ce que je te disais c'est ça :

Code:


y = PosY
FinY = PosY + Largeur
for (i=Largeur ; i-- ; )
    {
 x = PosX + 1
 for (j=Longueur ; j-- ; )
 {
 VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), x, y, 2, 2, 2, 2);
 VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), x, PosY, 2, 0, 2, 2);
 VDP_setMapEx(PLAN_A, Wind, TILE_ATTR_FULL(PAL3, TRUE, FALSE, FALSE, ind), x, FinY, 2, 4, 2, 2);
 x++;
 }
 y++;
 }


Le but est d'éviter de faire des calculs trop "compliqués" dans la boucle (un x++ ça se traduira certainement par un addq en assembleur, alors qu'une addition de variables ça fera intervenir des additions de variables en mémoire). Tu peux aussi faire en sorte que x et y soient les variables des for (for (x = PosX ; x < FinX ; x++)) (moins tu utilises de variables, plus tu as de chances que le compilo utilise un registre plutôt qu'une adresse mémoire). Tu as déjà codé en asm, je pense pas te parler de trucs que tu ne connais pas :)

Il est possible que le compilo optimise tes boucles de cette façon mais je n'en suis pas sûr (je suis même sûr que non pour la partie boucle descendante).

De plus, je me souviens pas si la bonne façon d'optimiser la boucle c'est faire i-- ou --i, Stef ou Touko doivent savoir.

[Stef]

@vetea Bravo pour le tuto, tu expliques très bien cette fonction et c'est une bonne chose que d'avoir mis la doc avec.
C'est une fonction primordiale dans SGDK et il est important de bien comprendre son fonctionnement, ça te permet effectivement de charger des parties de Map dans un endroit spécifique de ton plan donc définitivement c'est très utile
Il est également important de bien comprendre le principe des ressources compressées car oui ça peut ralentir terriblement le process
Après ce qui est encore lent ici, c'est le nombre d'appels à la fonction VDP_setMapEx(..) mais dans ton cas vu comment tu l'utilises tu n'as pas trop le choix (il y aurait des alternatives mais elles seraient moins lisibles et perso je préfère un code clair). Tu peux au moins utiliser l'astuce de Tryphon pour gagner un peu de temps

Sinon pour une boucle j'utilise si possible :

Code:

while(i--)
{
  ..
}

Celle-ci est normalement optimisée en dbra par GCC, pour les autres la plupart du temps il n'est pas capable d'optimiser correctement. Ta boucle for est équivalente donc ça doit s'optimiser aussi mais à la lecture je préfère le while(..) qu'un 'for' utilisé ainsi

[Invité]

Merci Stef ! 

[Tryphon]

Ta boucle for est équivalente donc ça doit s'optimiser aussi mais à la lecture je préfère le while(..) qu'un 'for' utilisé ainsi

Je te confirme que ça s'optimise pareil (j'ai vérifié). J'avais même trouvé en farfouillant un article qui expliquait que dans les compilos C les for sont traduits en while avant d'être compilés (comme un préprocesseur quoi). Bon, c'était un vieil article, et je ne sais pas si c'est toujours le cas (je crois qu'il n'y a plus de préprocesseur maintenant).

[Invité]

Bon, c'était un vieil article, et je ne sais pas si c'est toujours le cas (je crois qu'il n'y a plus de préprocesseur maintenant).

Je pense qu'on peut pas généraliser une optimisation pour un CPU ,avec celle pour un autre .
A mon avis l'optimisation va être différente selon l'archi cible .

[Tryphon]

Non, je parle de l'équivalence for/while (pour toutes les boucles), pas de l'optimisation en boucle descendante (qui est en effet spécifique). C'était au niveau du design du compilo, c'était donc général (il est pas impossible que j'ai lu ça dans le K&R, c'est dire ). Mais là on est hs, c'est juste pour dire que préférer le while au for, c'est juste une question de style (comme jouer à la Dreamcast )

[Invité]

Oui dans ce cas tu as raison.

[Invité]

Euh bon ... Au final, j'ai toujours rien compris si ce n'est les propos de Stef qui a saisit un peu le sens de mon post initial sur ce "Tuto".
Je met des " " car je n'ai aucune prétention à apprendre à quiconque, quoique ce soit en matière de codage. 

Juste un partage ... Comme le fait mon ami FL.
D'ailleurs, hormis Michel Louvet ( alias Bfg ) et ses excellents cours de programmation, il n'y a pas grand monde pour proposer des tutoriels, si ce n'est les spécialistes pour corriger ce qu'ils proposent.

[Tryphon]

Qu'est-ce que t'as pas compris ?

[Invité]

- Un while plutot que For - Next ?? En fait ça dépend de la manière dont on l'utilise, du compilateur, etc ... Donc au final euh ... 
- Ton code, merci pour le partage, il y a toujours une double boucle et par rapport à mon code, j'ai pas trop compris la différence. Si ce n'est, peut être que c'était ça l'optimisation, de ne pas faire de calcul dans la routine VDP_setMapEx, !


C'est toujours difficile de comprendre la manière de coder d'un autre, de suivre sa logique .. Enfin me concernant.
Mais j'apprécie le fait de pouvoir guider une personne pour l'amener à s'améliorer.

La solution d'utiliser le Plan WINDOW ( c'est ça Touko ?? ), est aussi intéressante !
Mais je ne me suis pas penché sur le Wiki concernant cette partie là.

Et puis j'aime bien cette idée de mettre des petites fenêtres graphiques un peu partout sur l'écran ... 

[Tryphon]

- Un while plutot que For - Next ?? En fait ça dépend de la manière dont on l'utilise, du compilateur, etc ... Donc au final euh ... 

Ça on s'en fout, c'est de l'enculage de mouches. Le seul truc à retenir c'est qu'une boucle qui va de 0 à 10 est moins rapide qu'une boucle qui va de 10 à 0, que ce soit un for ou un while.

- Ton code, merci pour le partage, il y a toujours une double boucle et par rapport à mon code, j'ai pas trop compris la différence. Si ce n'est, peut être que c'était ça l'optimisation, de ne pas faire de calcul dans la routine VDP_setMapEx, !

C'est ça. Plus précisément, l'idée c'est de ne pas faire de calculs dans le corps de la boucle (ou le moins possible) parce que ce calcul, aussi simple soit-il, sera répété Longueur*Largeur fois.

La double boucle est obligatoire : tu es bien obligé de passer au moins une fois sur chaque tile, et c'est exactement ce que tu fais.

La solution d'utiliser le Plan WINDOW ( c'est ça Touko ?? ), est aussi intéressante !

J'ai pas répondu à Touko mais en fait je pense pas que tu y gagneras. Ni que tu y perdras d'ailleurs. Tu auras surtout la satisfaction de ne pas les voir bouger à l'écran quand ça scrolle.

[Invité]

Cool !!
Merci pour les précision !!

[Invité]

Coucou,

J'ai encore étoffé mon petit court d'entrainement en ajoutant quelques arbres !



Le truc rigolo, c'est que les abres ( coté Gauche et droite ), c'est un bloc de Tile qui utilise la palette du sprite de Papi sur le Plan A !
En fonction de la caméra, je l'affiche tantôt à gauche ou à droite tout comme la gestion du public sur le court central.
La grille du fond, c'est un autre bloc de tile sur le Plan qui utilise la palette du court !
Les sprites et leur priorité sont agencés en fonction de tout le merdier ... 

Bref, tout ça pour ça ! 
Ca ne sert toujours à rien, mais ça m'éclate autant.

J'ai aussi revu le design des fenêtres et optimiser l'affichage ( Merci les amis au passage !! )


De même qu'avec le code, j'ai optimisé ma routine d'affichage de tous mes sprites grâce à vos conseils.

A bientôt !

[Ricco59_59]

C'est tout simplement génial ce que tu fais. Bravo

J'ai vu la dernière vidéo qui est très sympa et pour l'instant j'ai remarqué 2 choses (l'affichage du message est en cours d'optimisation donc je ne compte pas et j'allais dire qu'à gauche, les pseudo-gradins sont un peu tristoune. C'est modifié héhé) :

- Au deuxième lancé du robot, j'ai cru que l'oiseau allait piquer du nez car il a pris la balle en pleine tronche... euh plein bec :)

- Pourquoi l'oiseau fait du 'sur place' quand le message s'affiche ?

Vivement la suite