Re: WIP Jeu de plateforme MD

[Tryphon]

Peut-être, mais savent-ils coder ?

(merci pour les liens, y'en a quand même un qui semble avoir fait un Wonderboy porno, c'est assez rigolo )

[fourchette]

Mes maps font 1024 en largeur.

Si tu as l'intention de continuer avec des niveaux rectilignes avec des maps de 1024px de large, pourquoi ne pas utiliser une largeur de plan de 128 tiles ?

Et pour illustrer mon soucis de saut, là j'ai sauté verticalement et à peine poussé vers la droite, le résultat à la réception :

 ?

[Kivutar]

Non seulement le gars qui a fait ces jeux hentai (il en a fait plusieurs) sait coder, mais il sait aussi composer de la musique.

[vincent2105]

C'est super sympa tout ça, très beau boulot déjà  

[TotOOntHeMooN]

Un petit "conseil"... Ne met pas trop de démo à dispo (travail très avancé), car un jour tu verras ton jeu "non terminé" vendu sur AliExpress. C'est déjà arrivé ici même.

[Invité]

Je confirme !!

Sinon excellent boulot surtout pour une première expérience MD.
Keep up the good work !

[Tryphon]

Non seulement le gars qui a fait ces jeux hentai (il en a fait plusieurs) sait coder, mais il sait aussi composer de la musique.

Il utilise Game Maker, c'est pas vraiment coder

Mais il est doué, clairement...

[Kivutar]

Mes maps font 1024 en largeur.

Si tu as l'intention de continuer avec des niveaux rectilignes avec des maps de 1024px de large, pourquoi ne pas utiliser une largeur de plan de 128 tiles ?

Et pour illustrer mon soucis de saut, là j'ai sauté verticalement et à peine poussé vers la droite, le résultat à la réception :

 ?

Je vais aussi faire des maps verticales, des maps qui sont deux fois moins longues que 512, et des maps qui font la taille de l'écran.
En fait idéalement, je devrait avoir que des multiples de 320x224, mais j'ai tenté du 1024 à parce que j'avais besoin d'une puissance de 2 pour scroller rapidement avec mon ancien code. Maintenant que c'est plus nécessaire je pourrais changer.

J'ai enfin capté ce qui allait pas avec le saut. C'est que je met une friction de 0 dans l'air, pour avoir de belles courbes de saut bien étendues horizontalement. Si je met une friction de 0.1, on a un petit saut beaucoup plus précis, par contre le grand saut est moins beau. Il va soit falloir que je trouve un compromis, soit falloir que je scotche des bouts de physique ensemble.

En tout cas merci à tous pour vos conseils et vos encouragement, ça fait plaisir

[Tryphon]

Rassure moi : ta friction, elle est codée en dur (constante avec #define) ou en soft ?

Il faut absolument éviter les multiplications en soft avec un processeur lent.

a = b*10

ça passe, mais :

a = b*c

c'est lent !!!

[Kivutar]

Oula, je savais pas !
Si tu vois mon code tu va prendre peur alors, ya des multiplications avec variables partout.

Par contre ma friction c'est une soustraction.

Code:

    self->x = self->x + self->xspeed;

    // Decelerating
    self->friction = grounded ? self->groundfriction : self->airfriction;

    if ((! (joy1 & BUTTON_RIGHT) && ! (joy1 & BUTTON_LEFT))
        || self->attack != 0 || self->throw != 0 || self->hit != 0)
    {
        if (self->xspeed > FIX32(0))
        {
            self->xspeed = self->xspeed - self->friction;
            if (self->xspeed < FIX32(0))
                self->xspeed = FIX32(0);
        }
        else if (self->xspeed < FIX32(0))
        {
            self->xspeed = self->xspeed + self->friction;
            if (self->xspeed > FIX32(0))
                self->xspeed = FIX32(0);
        }
    }

C'est clair que mon code est pas optimisé pour un processeur lent comme le m68k. A la base mon jeu était en lua et ciblait les PC modernes.

Pour ceux qui ont un compte sur bitbucket, je peux faire un accès au repo privé. Mais je réserve ça aux habitués du forum pour éviter le souci dont vous parliez avec les ventes pirates et tout ça.

[Tryphon]

Ah ok, ce que tu appelles friction c'est ce que j'appelle accélération horizontale (je connais pas les dénominations "standard").

Au départ, je pensais que ça modélisait une force de frottement, et il me semble qu'elles sont (en première approximation) proportionnelles à la vitesse, c'est pour ça que je pensais que tu faisais une multiplication.

Concernant les multiplications et les divisions (et les modulo) en 68000 : le processeur a des instructions pour ça (à la différence de la plupart des processeurs 8 bits, où il faut programmer les algos de multiplication/division, c'est encore pire) mais elles sont trèèèèèès lente.

Ce qui est rapide, ce sont les opérations de décalages, << et >> en C, qui correspondent à des multiplications et divisions par des puissances de 2 (et pour le modulo, tu fais un "et logique").

Par exemple, x << 8 et x * 256 renvoient la même valeur, mais le décalage est beaucoup plus rapide.

Pour te faciliter la tâche, un bon compilateur C est capable de compiler x * 256 sous la forme x << 8 (même si perso je préfère utiliser des décalages). Mieux que ça, si tu lui demande y = x*257, il va le compiler sous la forme :

Code:

y = x << 8 // ça fait y = x*256
y = y + x // ça fait y = x*256 + x = x*257


Mais ça ne marche que si le compilateur sait par quoi tu multiplies. Si tu demandes y = x * z, puisque x et z sont des variables, le compilateur ne peut pas déterminer les valeurs et utilisera donc la trèèèès lente instruction de multiplication du 68000.

[Kivutar]

C'était bien les frottements, mais je les ai implémentés avec une soustraction. Je savais pas que c'était sensé être proportionnel à la vitesse.

Je commence a comprendre ces histoires d'optimisations. Je vais relire un peu tout mon code et essayer de trouver pourquoi c'est si lent.

[Kivutar]

Je ne trouve toujours pas pourquoi mes sprites ne scrollent pas bien synchro avec mes plans.

J'ai fais un cas tout simple, sans collisions, sans entités, juste ma map et 1 sprite.

Quand j'appuie sur droite, j'incrémente la valeur du scroll, qui est un s16 comme dit la doc.

Je positionne mon sprite avec SPR_setPosition, en utilisant exactement la même variable que pour le scroll de mes plans.

Pas de conversion avec fix32ToInt ou quoi que ce soit.

Pas d'appel a VDP_setMapEx ou de DMA du tout.

Le bug est quand même là.

J'ai quasiment commenté tout mon code jusqu'à ce qu'il ne reste que 10 - 20 lignes.

[philip]

Pour ce problème de synchronisation, peut-être que c'est juste un problème d'organisation de la logique de ton jeu. 
1. Tu teste la manette de jeu.
2. Ton personnage joueur bouge en fonction du test manette.
3. Tes plans A&B bougent en fonction du personnage joueur.
4. Tu bouge ton sprite ennemi en fonction du plan A
5. Tu bouge ton sprite ennemi selon son I.A.

[Kivutar]

J'ai pu reproduire le problème sur le "sprite sample" de SGDK, avec presque aucune modification.

J'ai juste viré le cyrcle de déplacement du crabe de gauche à droite. Et j'ai rendu l'animation très lente pour qu'il garde toujours la même pose.

Et quand je scrolle, en utilisant la fonction slow motion de retroarch+genesis_plus_gx, je vois bien ce décalage.

Donc le souci viens soit de mon émulateur, soit de SGDK, soit d'ailleurs.

[Tryphon]

Ça sent le problème d'émulation. Essaie d'autres ému.

[Kivutar]

Je viens de reproduire sur la megadrive.

Avec le sprite sample : [url=static.kivutar.me/bug.bin]static.kivutar.me/bug.bin[/url]

Il faut se déplacer vers la droite, et regarder le crabe, tu verra qu'il y a un décalage avec la fleur qui est sur le PLAN_A.

[Tryphon]

Et t'as le code ?

[Kivutar]

C'est le code du sample officiel de SGDK : https://github.com/Stephane-D/SGDK/tree/master/sample/sprite

Avec ces 3 petites modifs:

Code:

diff --git a/sample/sprite/out/rom.bin b/sample/sprite/out/rom.bin
deleted file mode 100644
index 794a920..0000000
Binary files a/sample/sprite/out/rom.bin and /dev/null differ
diff --git a/sample/sprite/res/sprite.res b/sample/sprite/res/sprite.res
index 8793b94..5c9a9a4 100644
--- a/sample/sprite/res/sprite.res
+++ b/sample/sprite/res/sprite.res
@@ -1,2 +1,2 @@
 SPRITE sonic_sprite "sprite/sonic.png" 6 6 FAST 5
-SPRITE enemies_sprite "sprite/enemies.png" 6 4 FAST 5
\ No newline at end of file
+SPRITE enemies_sprite "sprite/enemies.png" 6 4 FAST 60
diff --git a/sample/sprite/res/sprite/enemies.png b/sample/sprite/res/sprite/enemies.png
index 799ea8e..27abc80 100644
Binary files a/sample/sprite/res/sprite/enemies.png and b/sample/sprite/res/sprite/enemies.png differ
diff --git a/sample/sprite/src/main.c b/sample/sprite/src/main.c
index b2e7bbe..11db411 100644
--- a/sample/sprite/src/main.c
+++ b/sample/sprite/src/main.c
@@ -27,7 +27,7 @@
 #define DE_ACCEL        FIX32(0.15)
 
 #define MIN_POSX        FIX32(10)
-#define MAX_POSX        FIX32(400)
+#define MAX_POSX        FIX32(800)^M
 #define MAX_POSY        FIX32(156)
 
 
@@ -202,10 +202,10 @@ static void updatePhysic()
     }
 
     // enemies physic
-    if (enemyXorder[0] > 0) enemyPosx[0] += FIX32(0.7);
+    /*if (enemyXorder[0] > 0) enemyPosx[0] += FIX32(0.7);^M
     else enemyPosx[0] -= FIX32(0.7);
     if (enemyXorder[1] > 0) enemyPosx[1] += FIX32(1.5);
-    else enemyPosx[1] -= FIX32(1.5);
+    else enemyPosx[1] -= FIX32(1.5);*/^M
     for(i = 0; i < 2; i++)
     {
         if ((enemyPosx[i] >= MAX_POSX) || (enemyPosx[i] <= MIN_POSX))

[Tryphon]

J'y jetterai un œil dès que possible (je pense, demain matin).

[Kivutar]

Merci !

Je continue le level design.

[NassimO]

C'est vraiment très chouette graphiquement ! Je testerais ça ce w-e 

[Tryphon]

Tu as raison, il y a effectivement une frame de décalage entre la mise à jour de la position d'un sprite et son effet à l'écran (t'arrives à voir ça sur vrai HW, sérieux ?), peut-être même que c'est quelque chose de pire (j'ai l'impression que les sprites oscillent autour de leur position finale). Faudrait essayer sans utiliser le sprite engine pour voir si ça vient de lui (j'ai codé des trucs en ce sens, mais j'ai changé de pc depuis, faut que je retrouve ça).

Au passage, j'ai essayé avec une rom du vrai Sonic, et y'a pas de décalage.

Edit : je viens de vérifier avec une vieille version mal optimisée de mon Shinobi, qui n'utilise pas le Sprite Engine, pas de décalage malgré des VBlank ratées. Ça vient donc vraisemblablement du Sprite Engine. On va avoir besoin d'un Stef

Si je devais parier sur un truc, je dirais que SPR_update() doit triggerer un truc qui doit être effectué pendant la VInt et que, pour une raison quelconque, ce truc ne l'est pas avant au moins la VInt suivante. Peut-être est-ce volontaire ?

Steeeeef ???

[philip]

Je n'utilise pas le sprite engine, donc seul stef, ou vetea partis à la montagne je crois lèveront le mystère.
Mais je trouve curieux que tu utilise du 1.5 et du 0.7 comme valeur pour tes sprites ennemis... J'imagine que tu obtient un entier relatif avec fix32, une arrondis à 1, ou 2 ?

https://c.developpez.com/faq/?page=Les-nombres-flottants#FLOAT_comparaison

[Tryphon]

Concernant la courbe de tes sauts, tu devrais faire en sorte que la friction soit nulle si aucune direction n'est appuyée (je pense que c'est ça qui fait qu'une simple pression envoie le personnage à 16 pixels), +0.1 si droite est appuyé, -0.1 si gauche (c'est ce que fait Shinobi, le jeu d'arcade) (sauf que c'est +/- 1/8)

Ou alors pas de friction, mais une vitesse négative, nulle ou positive suivant la direction pressée (ça fait des sauts plus flottants, mais plus faciles à gérer pour le joueur, genre James Pond 2 Robocod).

[Invité]

Coucou,
Je ne constate pas ce problème et à vrai dire, j'ai rien compris sur ce qu'il se passe ! 

Sur Papi Commando Reload, aucun soucis constaté, tout est fluide malgré le nombre élevé de calculs à faire.
Que ce soit sur émulateur Fusion ( Exodus rame à mort ), et sur le Hard (ma Nomad) tout est parfait !

Après, chacun à sa manière de faire.

Personnellement, le SPR_update() je le met à la fin de ma boucle principale avant le VB().

Code:

        // Affichage Scene
        UpdateScene();

        SPR_update();

        VDP_waitVSync();

UpdateScene(), c'est la boucle de gestion de tous mes sprites ( Affichage, calcul divers, test hitbox, etc ... )
Bref, placer au bon endroit le SPR_update(), compiler et tester !
Le SpriteEngine de Stef est parfait.

Bon courage !

[Tryphon]

Faut passer en ralenti pour le voir...

[philip]

Voilà, c'est son positionnement du SPR_update()

[Invité]

Spoiler:

Spoiler:

[Tryphon]

Voilà, c'est son positionnement du SPR_update()

Je pense pas, ça le fait sur le sample sprite de Stef et le update() est bien placé.

(mais l'OP a posté son code quelque part ? Je le vois pas...)

[Invité]

Ah c'est ce truc là Kaot  ?!
Même pas remarqué !

Moi ça ne me gène pas du tout.
Après, ça n'a rien à voir avec SPR_update() effectivement, mais les dernières mises à jour du SgdK de Stef avec la gestion Yorder.
Faire une compilation avec une version antécédente, la 1.2 par exemple et voir ce que cela donne.
Si c'est OK, faire un report à STEF et attendre !