Re: Collision et Tilemap avec la SGDK

[Tryphon]

Oui, pour les mouvements latéraux. Le compteur de ligne c'est pour gérer l'élévation.

[Infitek]

Ok merci je vois, c'est fou dans Space harrier pour leur plaette swap sur la grille du sol ils ont plusieurs fois la même couleur dans leur palette et j'ai l'impression qu'une "cellule" de la grille qui représente le sol est composé de plusieurs couleurs identiques mais indexées différemment.

[Infitek]

Bon ça marche a peu pres on a une impression de vitesse sur le quadrillage au sol, maintenant j'aimerais représenter les nuages avec la même méthode qui est utilisée dans Mickey Mania lors de la course avec l'élan, j'ai récupéré cette image https://youtu.be/nt-AxAqlrOo?t=78 et j'ai l'impression que je vais devoir changer la palette de chaque ligne selon le motif que je veux dessiner, mais je comprends mal comment c'est possible, déjà je ne vois pas de fonction pour faire ça avec la sgdk et ensuite il me semble que si je modifie la palette d'une ligne toute la palette est modifiée, vous avez une idée de par ou commencer ?

Merci d'avance

[Invité]

C'est simple ce n'est pas possible , deja ça prendrait trop de cycle de faire un Hint sur chaque ligne et le second t'aurais pas mal de glitch (changer la palette en cours de route laisse quelque ligne de pixel "random").

Moi je changerai clairement le tile , c'est rapide et moins contraignant :)

[Infitek]

Ce n'est pas possible ? C'est pourtant ce qu'ils font sur Mickey Mania non ?

Ou alors ce n'est pas possible de base avec la sgdk ?

[Invité]

S'il change la palette, il le change pas sur chaque ligne alors
Je viens de t'expliquer que c'est surtout coûteux en terme de cycle donc rien n'a voir avec le SGDK.

D’ailleurs le SGDK de permet d'avoir le Hint , mais rien ne t’empêche de changer la palette sur chaque ligne.

Et un autre souci que je viens de dire, c'est que je ne vois pas les pixel random du au changement de palette sur le Mickey Mania , si tu le fait sur la vrai MD un changement de palette sur chaque ligne , tu aura énormément de glicth.

Par exemple :

Spoiler:

Certain jeux le cacher avec des sprites (c'est le cas de Sonic entre autre )

[Infitek]

En fait je débute sur le développement megadrive donc évidemment je ne comprends pas tout, j'ai eu l'aide précieuse de plusieurs membres comme Steph et Tryphon mais malgré tout je ne suis pas encore un pro et je n'ai pas du tout l'habitude de travailler dans cet environnement, désolé de ne pas TOUT comprend instantanément.

Je cherche juste a obtenir le même effet, je sais que c'est possible et j'ai écumé le net à la recherche d'un tuto et à part l'explication très basique fournie sur la vidéo que j'ai envoyé plus haut je n'ai rien trouvé.

En fait c'est pas la palette qui change c'est chaque ligne du "tube" qui applique le motif de la ligne précédente j'ai l'impression mais encore une fois je peux me tromper.

J'aimerais pouvoir acheter un bouquin ou lire un tuto sur le net mais c'est vrai que c'est un domaine de niche qui m'intéresse malgré tout, désolé encore une fois si je pose beaucoup de question mais j'ai déjà énormément progressé et je sais que cet aide précieuse je ne pourrais la trouver qu'ici.

[Invité]

J'ai toujours trouvé les bouquins de prog assez inutile , je veux dire tu trouve à boire et à manger sur le net

Faire de la 3D , c'est créer une perspective (donc un point de fuite) , il faut juste faire plusieurs fois le même tile mais avec une perspective différente , il y'a néanmoins probablement un peu d'interruption pour le scrolling Vertical je pense.

Mais je pourrais pas en dire plus , je ne suis ni un expert de la MD , ni du SGDK ! x)

[Tryphon]

À mon avis y'a un truc qui n'est pas dit dans la vidéo. Comme dit Kannagi, tu ne peux changer que quelques couleurs, et si t'en changes plus de 2 (je crois), des points parasites apparaissent (c'est un défaut de conception de la MD, rien à voir avec SGDK ou quoi que ce soit).

Peut-être que dans Mickey, ils arrivent à de demerder pour n'en changer que 2 par lignes, faudrait creuser. Stef en sait certainement plus. Tu pourrais tenter de poser la question sur spritesmind, y'a certainement un cador qui en sait davantage.

[Hpman]

Mickey mania n'utilise pas d'IRQ hblank, il à l'air d'attendre manuellement les bonnes positions avec le H/V counter pour changer les couleurs hors écran.

[Tryphon]

C'est ce que je suspectais. Par contre, ça empêche sur les CRAM dots ? Je pense pas, par contre je pense qu'avec un code mieux timé, on doit mieux profiter du HBlank (on économise le temps d'appel à l'interruption).

[Hpman]

Il faut caler les accès hors affichage, comme ça l'écran est propre. Pas de dots sur cette séquence de mickey mania en tout cas.

[Tryphon]

Mais par rapport à une Interruption, tu ne gagnes "que" l'appel et le retour ? Je sais que c'est très lent sur un 68000, mais c'est suffisant pour changer une palette entière sans CRAM dots ?

Parce que si oui, ça peut être une technique intéressante pour des images fixes...

[Invité]

Sur une interruption , il faut sauvegarder tout les registres et faire le code du prochain Hint (et Stef m'avait dit que indiquer le prochain Hint était assez mal foutu sur MD ) , c'est un peu plus complexe qu'un simple return
(je sais que pour push/pop tout les registres ça te prend 72*2 cycle + rte qui fait 20 cycles donc un total de 164 cycles , ensuite il faut calculer le reste ! :p)

[Hpman]

Le problème sur MD c'est qu'on ne peut pas contrôler à quel endroit déclencher l'IRQ, car c'est un compteur de lignes et non de pixels.

Deuxième problème les IRQ sur 68000 (en plus d'être lentes) ont un timing qui varie selon ce que le CPU était en train de faire au moment de l'appel.

[Stef]

En fait Infitek a raison, dans Mickey Mania ils reprogramment une palette complète à chaque ligne    Mais pour faire ça déjà tu n'as pas d'autre choix que de synchroniser en passif (le CPU qui test le H counter en continu) sur toute la zone concernée, et aussi tu dois désactiver le VDP juste à la fin de l'affichage de la ligne pour avoir du full speed sur le transfert de la palette et tu réactives immédiatement l'affichage (avant qu'on arrive à la prochaine ligne). Autant dire que le timing est serré !!
Aussi le fait de désactiver le VDP sur le HBlank fait que tu perds une partie du budget  sprite affichable (il t'en reste 10 sur le 20 affichables par ligne en gros).

Sur une interruption , il faut sauvegarder tout les registres et faire le code du prochain Hint (et Stef m'avait dit que indiquer le prochain Hint était assez mal foutu sur MD ) , c'est un peu plus complexe qu'un simple return
(je sais que pour push/pop tout les registres ça te prend 72*2 cycle + rte qui fait 20 cycles donc un total de 164 cycles , ensuite il faut calculer le reste ! :p)

Heureusement non ^^ tu ne sauvegardes que les registres que tu vas modifier Et donc tu as intérêt à limiter le nombre de registre modifiés dans ton code de h-int.

C'est ce que je suspectais. Par contre, ça empêche sur les CRAM dots ? Je pense pas, par contre je pense qu'avec un code mieux timé, on doit mieux profiter du HBlank (on économise le temps d'appel à l'interruption).

C'est le cas de Mickey Mania, c'est très bien "timé", ce qui leur permet non seulement de reprogrammer une palette complète (16 couleurs) mais en plus de réussir à le faire tenir dans le HBlank (et donc aucun CRAM dots qui ne sont visibles uniquement lorsque tu modifies la CRAM *pendant* l'affichage). Par contre pour accélérer le transfert ils doivent sacrifier la moitié des sprites affichables..

[Tryphon]

Du coup, cette astuce semble tout à fait viable pour un jeu à écran fixe avec quelques sprites dessus, genre un Point'n click à la Day of the Tentacle. Ça permettrait des images à bien plus de 60 couleurs...

[Stef]

Pas besoin de ça pour faire des images de plus de 60 couleurs
En reprogrammant une palette complète tu pourrais aller jusqu'au 512 couleurs mais bon ici ce n'est pas pour augmenter le nombre de couleur que l'effet est utilisé, mais plutot pour scaler une texture (en quelque sorte)

[Tryphon]

Ben des images en plus de 60 couleurs, si j'excepte le S/H (qui me semble pas vraiment fait pour des images fixes), jusqu'à présent je voyais 2 méthodes :

1) Une HInt qui modifie quelques entrées palettes : c'est bien mais c'est limité à 2-3 couleurs par ligne si on veut éviter les CRAM dots

2) le DMA CRAM : beaucoup de limitations (résolution, colonnes doublées). J'avais vu une comparaison entre les deux méthodes (sur spritesmind ? De mémoire y'avait une photo d'une voiture rouge) d'où il ressortait que visuellement, le 1) s'en sort aussi bien voire mieux que le 2.

Éviter la HInt par du code timé me semble un raffinement du 1) qui permet de changer plus de couleurs, même si en effet c'est pas l'objectif de Mickey Mania. C'est extrêmement ingénieux je trouve (même si du coup ça nécessite un jeu au gameplay simpliste).

[Invité]

C'est ce que je suspectais. Par contre, ça empêche sur les CRAM dots ? Je pense pas, par contre je pense qu'avec un code mieux timé, on doit mieux profiter du HBlank (on économise le temps d'appel à l'interruption).

Non ça ne les empêche pas, mais ils sont dans l'overscan si ce que pense HPMAN est juste, donc normalement tu les vois pas .
Car attendre le début du hblank à la mano tu gagnes en précision et tu as une interruption dite stable,par contre tu perds bcp de cycles, mais si c'est pas un problème par rapport à ce que tu veux faire alors ça vaut le coup.

D'ailleurs on voit bien que les CRAM dots ne sont pas évitables, on voit le changement de palettes dans le vblank sur les jeux MD,faut juste éviter de toucher à la CRAM pendant l'affichage .

[Tryphon]

Quand je dis "on évite les CRAM dots", je veux dire "on évite de voir les CRAM dots"

[Invité]

Ah ok, alors oui tu les évites 

[Infitek]

Merci pour toutes ces précisions, je ne suis loin d 'être assez calé pour implémenter ce système pour le moment j'ai donc opté pour du palette cycling pour l'instant, mais je pense qu'il y a encore pas mal de taf pour que ça rende bien : https://www.youtube.com/watch?v=7mUNKhqL51o&feature=youtu.be

[Invité]

L'effet est très sympa, et le cyclage de couleurs fait le job 

[Infitek]

L'effet est très sympa, et le cyclage de couleurs fait le job 

Merci beaucoup, ça a été amélioré depuis je referais une capture du rendu final !

J'ai essayé de rajouter des rochers sur les cotés pour accentuer l'impression de perspective comme dans Mickey Mania (eux ils ont utilisé des arbres https://i.imgur.com/YnzMgmd.gif )
Au debut je pensais qu'ils avaient utilisé des sprites mais en vérifiant avec Gens KMod on dirait qu'il redessinent une image sur le plan.
Quelle serait la la "bonne" approche pour reproduire cet effet ?

[Infitek]

J'ai trouvé, ça marche bien en utilisant SetMapEx() !
(Je me suis inspiré de ce topic https://www.gamopat-forum.com/t87262p600-demo-disponible-papi-commando-tennis-megadrive-sgdk)

Au passage, j'ai récupéré la dernière version de la sgdk, bravo Stef pour ce beau travail.
J'ai l'impression que tous mes glitches graphiques ont disparu et que je peux afficher des sprites bien plus gros sans erreurs, encore bravo a toi

[Infitek]

J'ai d'ailleurs une petite question a propos de l'optimisation avec SetMapEx()
Dans mon cas de figure ( )
Je n'ai besoin d'updater que les tiles en rouge ici, est ce plus optimal d'appeler une fois la fonction SetMapEx pour mettre à jour toute l'image ou bien de l'appeler plusieurs fois pour ne changer que les tiles concernées ?

EDIT : Encore une fois je me répond tout seul, dans mon cas appeler une seule fois la fonction est bien plus optimal au niveau des FPS.

[Stef]

Merci Je suis content que la dernière version de SGDK a pu apporter des améliorations sur ton projet  En fait je pense que c'est l'optimisation de la découpe des sprites qui améliore les résultats. Je ne suis pas toujours sur le forum du coup tu as trouvé la réponse tout seul. Dans certains cas plusieurs appels à setMapEx(..) peut être un peu plus rapide, mais seulement si le nombre d'appels reste assez bas (genre 3 ou 4 appels). Dans ton cas c'est difficile à optimiser efficacement (à cause de la diagonale) du coup un seul appel pour tout rafraichir sera plus rapide.