[morukutsu]

Je n'ai pas reçu ton mail, bizarre.
C'est quoi que tu veux savoir sur mon moteur ? Je peux l'expliquer ici, ça ne me pose pas de problèmes

[morukutsu]

Pour commencer, la base de mon moteur est gérée par un gestionnaire d'états (http://www.games-creators.org/wiki/Gestion_des_Game_States_en_C_plus_plus) qui me permet de passer de scènes comme l'écran le pause, le menu principal ou l'intro sans problèmes.
Ensuite, j'ai créé un état nommé WorldState qui va contenir une instance du moteur de jeu nommé WorldManager.

Ce WorldManager gère beaucoup de choses : les différentes maps, le score, les entités, etc...

Pour créer les maps et les listes d'entités, j'ai simplement utilisé GBA Graphics.
Pour les maps, il y a en fait 3 maps : La première couche, la 2ème couche et la map de collision qui n'est pas affichée et qui reste en RAM. La map de collision est très simple : un pixel noir pour collision totale, un pixel blanc pour aucune collision, un pixel bleu pour une collision avec une pente.
La gestion des pentes est un mécanisme qui m'a donné du fil à retordre mais finalement j'ai pu trouver une solution qui marche parfaitement :
- Chargement :
On donne a la fonction une liste de tiles pentues. La fonction va parcourir chaque tile et noter la hauteur de chaque pixel bleu. On se retrouve ensuite avec une fonction a qui on donne la position x du personnage dans le tile et qui nous retourne son y.
- Collisions :
On récupère l'id du tile sur lequel on est. On vérifie si le pixel de la map de collisions est bleu. On fait une soustraction pour avoir la position dans le tile. On change la hauteur du perso (en fait, ce test est répété 3 fois pour les pixels contigus).

Au niveau des entités, j'ai créé un moteur basé sur la STL et une classe abstraite d'entités. Celle ci contiens des fonctions virtuelles pures qui seront définies dans les autres classes grâce a l'héritage. Ceci me permet de faire ce que je veux : des Ennemis, des Boss, des entités logiques (qui créent un évènement lors d'une collision), etc...

Pour gérer les collisions entités-héros, j'ai créé une structure hitbox qui définit un rectangle de collision pour chaque entité. Toutes les entités du jeu (donc même le héros) contiennent une fonction nommée CheckInteractions() qui est appelée à chaque frame. Pour optimiser le tout, ce n'est pas le héros qui teste les collisions avec les autres entités mais les entités qui testent les collisions avec le héros. Pour l'instant, il n'y a pas de collisions ennemis-ennemis mais je suis en train de bosser la dessus (c'est très facile à ajouter).

Voila en gros comment est mon moteur, si tu as d'autres questions n'hésite pas

PS : En fait j'ai bien reçu ton mail, mais je ne sais pas pourquoi il est parti dans courrier indésirable. Vive Windows Mail ...

[PypeBros]

Pour les maps, il y a en fait 3 maps : La première couche, la 2ème couche et la map de collision qui n'est pas affichée et qui reste en RAM. La map de collision est très simple : un pixel noir pour collision totale, un pixel blanc pour aucune collision, un pixel bleu pour une collision avec une pente.
La gestion des pentes est un mécanisme qui m'a donné du fil à retordre mais finalement j'ai pu trouver une solution qui marche parfaitement :
- Chargement :
On donne a la fonction une liste de tiles pentues. La fonction va parcourir chaque tile et noter la hauteur de chaque pixel bleu. On se retrouve ensuite avec une fonction a qui on donne la position x du personnage dans le tile et qui nous retourne son y.
- Collisions :
On récupère l'id du tile sur lequel on est. On vérifie si le pixel de la map de collisions est bleu. On fait une soustraction pour avoir la position dans le tile. On change la hauteur du perso (en fait, ce test est répété 3 fois pour les pixels contigus).

Ouaip. C'était le coup des tiles pentus qui m'intéressait. je vois bien l'idée des "pixels bleus", mais redis-moi juste ... tu as un pixel bleu par tile pentu ou un pixel bleu par pixel sur un tile pentu ? Ou bien une look-up table avec une description de chaque tile au niveau collision (fait de pixels blancs, noirs et bleus ?)

L'autre cas qui m'intéresse, c'est le passage d'un sol horizontal à une pente, puis retour à un sol horizontal. Pour reprendre le cas présenté dans cet article sur la programmation du jeu M.C. Kids sur NES ...

descendre cette pente ira tout seul: on commence avec le "hotspot" (le test-point principal, H, qui indique si le personnage est sur du sol ou pas, pour ceux qui n'aurait jamais lu l'article) est sur un des pixels "de bordure" du tile 2 (donc noir : collision normale) et va passer sur le premier pixel "bleu" de la pente (tile 3). là, vu la vitesse horizontale, on sait qu'on doit ajuster le déplacement vertical de manière à suivre la pente (+1,+1 quoi). Si on fait demi-tour, pendant qu'on est sur la pente, aucun soucis non plus : on est toujours sur un pixel bleu et on peut effectuer le déplacement (-0.5,-0.5) plutôt que (-1,0).
En allant à droite au dernier pixel du tile 6, le (+1,+1) nous amène bien au premier pixel du tile 9 et donc on retrouve un bord "noir" et un déplacement horizontal. Ca, c'est ok.

Mais mettons qu'une fois en bas, le joueur décide de faire demi-tour. du pixel le plus à gauche, le joueur va arriver non-pas sur le pixel "bleu" du tile 6, mais bien sur un pixel 'noir' du tile 8, et donc continuer horizontalement jusqu'à arriver avec un des test-points B ou D dans un mur... Pour y remédier, ils ont du ajouter un type de tile "bord de colline" en 9 avec un pixel bleu au coin supérieur-gauche (et un autre, miroir, avec un pixel bleu au coin supérieur droit pour les "montées vers la droite". C'est une solution correcte, mais elle m'ennuie ... d'abord parce qu'elle rajoute de nouveaux types de tiles, et ensuite parce que ça risque de devenir l'horreur avec plusieurs degrés d'inclinaison, comme on en trouve dans les jeux de plate-forme:


On a un autre soucis (mais moins grave) une fois que le perso arrive en haut du tile 3 (il va toujours vers la gauche) : le dernier pixel "bleu" le fait monter sur le tile 0 plutôt que d'aller sur le tile 2 comme il se doit. Résultat, il va nous faire une "mini-chute" à la fin de son "escalade".

Ceci dit, il y aurait une solution: doubler les tests

• tester en plus de (x,y) (x,y-1) quand on est sur du noir pour détecter un "début de colline montante"
• tester en plus de (x,y) (x,y+1) quand on est sur du bleu pour détecter une "fin de colline montante"

du temps de la NES, c'était considéré comme une hérésie ... j'imagine qu'avec la DS, ça ne devrait pas tuer notre bande passante vers la mémoire...

edit ah oui, il y a une autre méthode, que je prévois d'essayer dans mon jeu: utiliser les test-points B et D pour détecter l'approche d'une colline et bidouiller (p.ex. vitesse verticale = -1/8) pour qu'à la fin du tile, le sprite se retrouve avec son 'hotspot' sur le premier pixel bleu, comme il se doit.

[morukutsu]

Ouaip. C'était le coup des tiles pentus qui m'intéressait. je vois bien l'idée des "pixels bleus", mais redis-moi juste ... tu as un pixel bleu par tile pentu ou un pixel bleu par pixel sur un tile pentu ? Ou bien une look-up table avec une description de chaque tile au niveau collision (fait de pixels blancs, noirs et bleus ?)

Un pixel bleu par pixel sur un tile pentu, regarde la correspondance entre mon chipset et celui de collision :


Pour détecter les collisions avec un sol "normal", j'ai un test point en dessous du test point des pentes :
- Quand on monte une pente, on va tomber obligatoirement sur un pixel bleu grace au test point des pentes juste au dessus de celui du sol normal
- Quand on descend une pente, la pente est considérée comme un sol normal, donc aucun problèmes.

Ceci me permet de passer d'un sol normal à une pente sans problèmes.

Par contre, pour passer d'une pente a une pente j'ai du trouver d'autres astuces :


J'ai tout simplement multiplié les test points par une série de if-elseif-...
Si on rencontre un pixel bleu sur le testpoint 1, on modifie la hauteur du personnage.
Si on ne rencontre pas de pixel bleu sur le testpoint1, on teste le testpoint3, si on rencontre un pixel bleu sur le testpoint3, on modifie la hauteur du personnage
Si on ne rencontre pas du pixel bleu sur le testpoint1 et sur le 3, on teste le testpoint2, et si on rencontre un pixel bleu sur le testpoint2, on change la hauteur du personnage. (on fait ce test car la vitesse du personnage varie de 1 à 2 pixels frame, donc, il faut tester 2 pixels devant le personnage)
Si aucun de ces tests s'est révélé concluant, on passe a la détection des collisions sur les pixels noirs (sans pentes).

Je me suis retrouvé confronté aux même problèmes que tu expliques ici, mon personnage faisait des mini-chutes dans un tile, il traversait les pentes, etc ...
Je me suis permit de multiplier les tests car ça ne posait pas de problèmes de vitesse, l'accès a la mémoire se fait le plus simplement possible, sans DMA.

edit  ah oui, il y a une autre méthode, que je prévois d'essayer dans mon jeu: utiliser les test-points B et D pour détecter l'approche d'une colline et bidouiller (p.ex. vitesse verticale = -1/8) pour qu'à la fin du tile, le sprite se retrouve avec son 'hotspot' sur le premier pixel bleu, comme il se doit.

J'ai essayé et ça n'a pas marché correctement.

Ce lien m'a beaucoup inspiré sur la méthode à suivre : http://jnrdev.72dpiarmy.com/en/jnrdev2/

[PypeBros]

merci pour les infos. je suis passé lire le lien, c'est une bonne pioche... de mon côté, j'avais jeté un coup d'oeil au tile game tutorial, mais leur moteur souffre de défauts assez visibles dans le jeu, illustrés d'ailleurs sur le jnrdev:


Ce n'est peut-être pas notable avec des tiles de 8 pixels, évidemment ... mais avec leur résolution, on voit clairement des "déplacement brusques" en fin de saut... je verrai si je peux faire mieux quand j'implémenterai ça ...

[morukutsu]

Dans mon moteur, on ne voit pas ces déplacements brusques grâce a une détection pixel perfect. Ce type de détection doit certainement être plus coûteux mais il ne mets pas a genoux le processeur de la DS. La preuve, mon programme utilise en gros 7% du CPU, avec le hardware 3D en plus.

[morukutsu]

Voila, la version Alpha est arrivée, et ça n'aura pas été sans soucis ! Des tas de nouveaux bugs sont survenus, et je suis sûr qu'il en reste encore 

Alpha Test :
Cette version alpha comprends le premier niveau du jeu et le premier boss. La difficulté n'est pas très corsée car c'est un niveau qui est là en guise de "tutoriel". Les touches sont simples, elle vous seront expliquées dans le jeu. Ce premier niveau vous montre ce que gère le moteur : maps et collisions, particules, ennemis, eau, etc...
Il me reste encore différentes choses a ajouter pour rendre cette démo plus belle comme par exemple un moteur d'eau plus poussé, mais bon, ce sera pour la prochaine fois, et avec des niveaux en plus !
Amusez-vous bien !

Télécharger

Si vous voyez des bugs, ou si vous avez des remarques à donner, n'hésitez pas
(si vous voulez tester sous no$gba, utilisez la version .sc.nds. Mais je vous conseille de tester sur DS, c'est plus beau )

[Vloz]

Bien sympa, le jeu est agréable à joué, jolie, les musiques aussi, et le bosse de fin assez marrant.

Tres joli demo. 

[unkwar]

cool ça
je teste dès que je rentre chez moi

[Mony]

Ah, super

Je télécharge ça, et je test

EDIT :

C'est bon, j'ai testé, alors, déjà :
Il faut y jouer sur DS, le jeu est beaucoup plus beau et plus maniable je trouve

Ensuite, la musique est super, les graphismes aussi, et le gameplay vraiment sympa
Après, si tu pouvais rajouter quelques checkpoints, ça serai cool, je suis mort quelques fois avant de passer un obstacle... Ah, aussi, le saut du personnage (chien-lapin ?) qui est assez bizarre, il se met à la verticale...

Ben, sinon voilà, pour une version de démo, il est vraiment cool, continue comme ça

REDIT : C'est un lapin-chat, pas un lapin-chien

[morukutsu]

Merci d'avoir joué
Pour les checkpoint, j'en ai juste mis un quand on perd au boss. J'en rajouterai plus alors

Ah, aussi, le saut du personnage (chien-lapin ?) qui est assez bizarre, il se met à la verticale...

En effet c'est assez bizarre . Mais quand j'observais mon chat sauter, il sautait comme ça !
 Si l'animation dérange j'essaierai d'en refaire une autre quand j'aurai le temps^^

[Mony]

Tu peux t'inspirer de sauts de lapin alors :

http://video.google.fr/videoplay?docid=-3602329692408711766&q=saut+lapin&ei=IMB9SKmsMI-i2wLWvP3YDg&hl=fr

Ou alors, de quelques acrobaties de chats :

http://video.google.fr/videoplay?docid=8024660198127455989&q=funny+cat&ei=6cB9SL7fLZ-a2wKv1bTUBg&hl=fr

[morukutsu]

J'ai regardé tout ça. Le saut du lapin à l'air pas mal, je vais voir si je peux faire ça

[Kram]

Ah ? marche pas sur R4DS ? C'est dommage...
Il me met 2 écrans noir : en bas : Loading.... Done (c'est normal en fait) et en haut : ecran tout noir, pas de musique mais le texte s'affiche (Start a new advanture / Continue your adventure in the machine). Si je fais A : écran du haut tout blanc....

Par contre il passe sans problèmes sur ma supercard miniSD

Voilà, sinon à part ça, le jeu est SUPER !!! J'ai trouvé quelques trucs un peu bizarres (sans compter le saut ) : 1 fois sur 2 je traverse un ennemi sans me faire toucher, quand je me fais toucher, je suis transparent (OK) mais je ne peux plus bouger... Le transparent c'est pas pour être "invincible" un très court instant ? si oui, alors il faut pouvoir donner un coup, sinon l'invincibilité ne sert à rien... et enfin, c'est normal que quand on va à gauche après être monté au premier geyser il y a des "vies" mais pas de sol ? 



C'est du SUPER travail  j'ai hâte de voir la suite !

[morukutsu]

Bizarre le coup du R4DS, j'ai un R4 et ça marche parfaitement !

Les ennemis oranges te touchent uniquement quand ils sont rouges, donc c'est possible de les traverser sans se faire toucher. Sinon, pour l'invincibilité je vois ce que tu veux dire, je vais corriger ça, merci

Là où il y a des vies mais pas de sol en fait si tu saute tu te rendra compte qu'il y a bien un sol, mais invisible
C'est une voie que j'utiliserai pour dissimuler une partie secrète

C'est du SUPER travail j'ai hâte de voir la suite !

Merci