Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Tryphon]

Non.

/ c'est la division entière, ça n'arrondit pas à l'entier le plus proche mais à l'entier inférieur.

2O7/16 = 12.

[Invité]

Ah oui en effet tu as raison, le problème c'est que j'obtiens 208 et non 207 quand je descend en bas. Forcément ça fausse tout. Cela doit être un problème de ma marge

Donc du coup, avec ce calcul, il m'est possible de connaître la position en tile du joueur et donc de la comparer avec une table contenant la position de chaque tile de la carte.

C'est vraiment efficace.

[ichigobankai]

quand je descend en bas

dsl, c'était ma minute con ^^

[Invité]

quand je descend en bas

dsl, c'était ma minute con ^^

Ma nana me fait systématiquement la remarque.

[Invité]

Je pense qu'on l'a tous faite celle là .

[Invité]

Voilà ça marche super bien ! Merci à tous, je vous aurais bien payer un verre, mais personne n'est du coin !

Pour le moment je test uniquement 10 tiles histoire de voir si ça fonctionne.

Il faut aussi que j'ajuste la position du vaisseau pour que se soit plus précis.

Bon, j'ai pas réussi à trouver. Il faut que le vaisseau soit vraiment sur la tile sinon la collision ne se fait pas.




La solution que je vois dans l'immédiat, serait de déterminer la collision en fonction de la position en tile et en coordonnées x y du vaisseau.

Par exemple, si le vaisseau est la tile 256, si aucune collision, est-ce qu'une tile aux alentours est un obstacle, si oui, quelle est la position du joueur en XY et quel type d’obstacle s’agit-il ?

Donc si le joueur est sur la tile 256, je vérifie sa position Y afin de savoir s'il touche la tile 1 et dans le cas positif, boum on le fait exploser !

Mon raisonnement est bon?

[ichigobankai]

pas compliqué

x-1 ou x+1 pour le tile précédent ou suivant,
y-largeur_screen ou y+largeur_screen pour celui au dessous ou en dessous.

[TotOOntHeMooN]

Heureusement que gcc remplace ce genre de multiplications/divisions par des décallages ! 

[Invité]

[Tryphon]

Heureusement que gcc remplace ce genre de multiplications/divisions par des décallages ! 

Perso j'ai pas confiance et je mets directement des décalages

[Invité]

Pareil.

[ichigobankai]

Moi aussi je préfère avec les décalages >> et << mais de toute façon le compilo va optimiser ca à sa sauce derrière (selon ce qu'il y a comme registres de dispo etc).

[TotOOntHeMooN]

A une autre époque (il y a 15/20 ans ? ), quand je faisais des tests de moteurs graphiques sur PC, mette les décallages apportait un gain signifif sur les fps.

[Invité]

Il y a possibilité d'avoir plus de précision lors de la collision sans que cela soit gourmand en ressource ?

Le problème c'est que la vaisseau fait 2 tiles de large et forcément ça tombe jamais pile sur la case.

Forcément, je test en comptant deux tiles vers la droite, la collision se fait quand le vaisseau rentre à moitié, hors je voudrais que la collision survienne un peu avant.





Après je sais pas si c'est important dans un shoot, car de toute façon on a pas vraiment le temps de voir à partir de quel moment le vaisseau a explosé.

D'ailleurs on constate le même problème dans Thunder Force III

[Invité]

Si, réduire ta grille de collision, disons du 8x8 au lieu de 16x16, tu gagneras en précision.

[Tryphon]

De plus, en général, on teste pas le centre du sprite, mais quelques points judicieusement placés (genre devant, derrière, haut et bas) (d'ailleurs souvent on est permissif : on prend les points à l'intérieur du sprite).

[Invité]

Oui, selon la direction du sprite, on définit des Offset exprès ... 
Purée, il faudrait écrire un recueil ou chacun donnerait ses petits tuyaux.

[Invité]

J'ai essayé de mettre en place un offset, mais du coup ça fausse la grille. J'ai pensé à diviser par 8 plutôt que 16. Je vais creuser un peu.

[Invité]

Moi j'utiliserai ce que t'a dit tryphon, 4 points (1 pour chaque direction) ,mais franchement ta première détection est qd même bonne, si c'est trop précis, tu risques de rendre la jouabilité frustrante, car le joueur va être concentré sur l'évitement des tirs et des sprites ennemis,alors si en plus la détection des collisions avec le décors est trop précise, ça risque vite de saouler,surtout si tu prévois des passages étroits .
N'oublies pas que c'est un shoot, pas un plateforme.

[Invité]

Parfaitement d'accord @Touko ! C'est juste que je dois créer plusieurs offset (left, right, top, bottom) et de déterminer si collision il y en a en fonction des tiles justement pour ne pas frustrer le joueur.

[Invité]

Parfaitement d'accord @Touko ! C'est juste que je dois créer plusieurs offset (left, right, top, bottom) et de déterminer si collision il y en a en fonction des tiles justement pour ne pas frustrer le joueur.

Oui et tu n'auras juste à modifier tes points pour fignoler le niveau de détection, plus ou moins précis en fonction de ce que tu veux faire .
Après rien ne vaut des tests fait par des joueurs,et rien qu'ici tu as bon nombre d'amateurs de shoots 

[Tryphon]

N'oublie pas que, comme a dit Vetea, tu n'as besoin de tester que les points dans la direction de déplacement. En particulier si le vaisseau ne bouge pas, tu ne testes rien.

[ichigobankai]

Enfin si t'as un scrolling forcé (cad comme ± tous les shoots) là tu dois tester tout le temps... sauf si ton niveau/zone n'a aucune collision vis-à-vis du décor (genre espace, ciel)

[Tryphon]

Par déplacement, j'entends "en coordonnées carte" (et même, exprimée en tiles). Quand tu te deplaces pas, tu testes toutes les 8 frames (en cas de scroll à 1ppf), c'est pas une super optimisation mais c'est toujours ça (au prix de 2 mots en RAM)

[Invité]

Faudrait que je test ce que ça donne de tester par 8 frames.

[ichigobankai]

ah oui en skippant les frames inutiles, ok je comprends mieux
Avant d'optimiser, laissons déjà Shingo mettre au point son algo.

[Invité]

Oui se serait bien que se soit au point avant d'optimiser, j'ai tout de même essayé en testant à chaque 8 frames, je trouve que c'est mieux, du moins, moins trivial.

Je ne sais pas si cela est utile, mais avant de test chaque possibilité après les 8 frames, j'ai par exemple indiqué que si la dernière position en tile est la même que la précédente testé, bah de rien faire ^^

[Invité]

SGDK c'est pour les vrais hommes qui codent !!!

[Invité]

Les "Vrais" codent en ASM.
Les hommes boivent des bières et aiment les gros seins.
=> Les hommes qui codent en ASM en buvant des bières et qui aiment aussi les gros seins sont vrais.
Après tu as aussi ceux qui font des séries de 100kgs au couché, qui codent en ASM en buvanr des bières tout en aimant les gros seins ET maitrisant le pouvoir obscure de la VBlank, mais ceux là jouent dans les Marvel.

[TotOOntHeMooN]

[Invité]

maitrisant le pouvoir obscure de la VBlank, mais ceux là jouent dans les Marvel.

Nah, le vblank n'a rien de sorcier, je t'assure .
Tu pensais d'ailleurs la même chose pour les pointeurs 

il suffit juste de se sortir de la tête qu'un SDK fait tout,et le fait forcement bien.