SGDK scrolling ... (encore) - (MEGADRIVE/GENESIS)

Bonjour à tous !

D'abord je voudrais tirez mon chapeau à Stef et à ceux qui contribuent à ce fameux SGDK..., c'est génial ! je dirais même que c'est..beau..

J'espère que vous serez indulgent, je crois avoir du coeur mais j'ai une faible capacité cérébrale...
J'essai depuis hier de scroller une map de plus de 64 tiles de large..., j'ai lu pleins de topics sur gendev et ici même mais ça coince...:

Quand j'utilise VDP_setMapEx pour mettre à jour les bords de la map, y me charge bien une région de la map , mais jamais à plus de 64 tiles de large...
J'ai beau faire comme les autres font..., mais nan ça veut pas...""
Quelque chose m'échappe, ou je suis débile je crois, si je bloque déjà là c'est mort non?... )

C'est pas mal ridicule mais je vais demander la chose comme ça pour aider mes frères noobs : 

A partir de l'exemple "sprite" untouched contenu dans la release, si je charge juste une map de 128 tiles de large à la place de "bga_image",
Est-ce que quelqu'un peut avoir la bonté de me dire littéralement, une bonne fois, le minimum vitale pour mettre à jour les bords quand ça scroll ?

Pour "get" ma colonne à mettre à jour c'est bien un truc comme  (( position de la camera + 40) >> 3) & 63    , non ? 
Est-ce qu'un VDP_loadTileSet est nécessaire?


Je promet de prier chaque matin pour ceux qui auraient la charité de m'éclairer...
Après je vous laisse tranquille promis, je ne poserai qu'une question joker par mois...

Dr. Acula a écrit:Pour "get" ma colonne à mettre à jour c'est bien un truc comme  (( position de la camera + 40) >> 3) & 63    , non ? 

Si tu veux calculer le numéro de la colonne de droite, c'est :

Code:

((position_camera_x_en_pixels >> 3) + 40) & 63

(attention aux parenthèses)

Mais peut-être veux-tu avoir l'offset de cette colonne dans la structure Map ? Dans ce cas il faut faire intervenir la position_camera_y et la largeur du plane ?

Pour le reste, peut-être que ton problème est dû au fait qu'un plan MD fait au max 64 tiles de large. Si tu veux mettre à jour la colonne "n° 64", il faut que tu repartes de la n°0. Ce n'est pas un problème dans la mesure où si tu mets ta camera en position 30*8 (par exemple), il va t'afficher les colonnes :
30 31 32 ... 63 0 1 2 3 4 5

Mais ça fait un moment que je n'ai pas touché SGDK.

Dr. Acula a écrit:Bonjour à tous !

D'abord je voudrais tirez mon chapeau à Stef et à ceux qui contribuent à ce fameux SGDK..., c'est génial ! je dirais même que c'est..beau..

Merci   Content que ça serve et que ça te plaise =)

J'espère que vous serez indulgent, je crois avoir du coeur mais j'ai une faible capacité cérébrale...
J'essai depuis hier de scroller une map de plus de 64 tiles de large..., j'ai lu pleins de topics sur gendev et ici même mais ça coince...:

Quand j'utilise VDP_setMapEx pour mettre à jour les bords de la map, y me charge bien une région de la map , mais jamais à plus de 64 tiles de large...
J'ai beau faire comme les autres font..., mais nan ça veut pas...""
Quelque chose m'échappe, ou je suis débile je crois, si je bloque déjà là c'est mort non?... )

C'est pas mal ridicule mais je vais demander la chose comme ça pour aider mes frères noobs : 

A partir de l'exemple "sprite" untouched contenu dans la release, si je charge juste une map de 128 tiles de large à la place de "bga_image",
Est-ce que quelqu'un peut avoir la bonté de me dire littéralement, une bonne fois, le minimum vitale pour mettre à jour les bords quand ça scroll ?

Pour "get" ma colonne à mettre à jour c'est bien un truc comme  (( position de la camera + 40) >> 3) & 63    , non ? 
Est-ce qu'un VDP_loadTileSet est nécessaire?

Je promet de prier chaque matin pour ceux qui auraient la charité de m'éclairer...

En fait pour faire un scrolling l'idée c'est de mettre à jour le plan (qui a une taille fixe de 64x32 tiles par défaut) sur les "bords" selon le sens du scrolling, et ensuite on utilise ce plan fixe comme un "rouleau" (c'est le principe de boucle lorsque tu dépasses la taille du plan, ce qu'explique Tryphon juste au dessus).

Il y a déjà beaucoup de sujets sur la question sur le forum SpritesMind qui est le forum plus ou moins officiel pour SGDK, je t'invite à lire les suivants :

http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=1908
http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=2145
http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=2771
http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=2762

Il y a aussi ce fichier source qui donne un exemple (un peu trop bas niveau cependant, il y a moyen de faire plus facile en utilisant les méthodes de SGDK) :
https://github.com/kcowolf/GenScrollingMapDemo/blob/master/src/ScrollingMap.c

J'espère que ça va t'aider, en attendant que je fasse un sample complet dans SGDK pour ça.

Haaaa mais oui mais oui, c'est bon je comprend maintenant!
Je savais plus où j' habitais ce matin c'était le bordel dans ma tête, mais là je vois clair avec vos explications!

Je comprenais pas que ce qu'on appelle le "plan" c'était les 64 tuiles, je croyais que c'était toute la map en tuile..., donc en effet ça repart à 0...""

Donc y'a le screen, le plan, et la tiles map complète..
ok je viens de test et tout redevient logique, je suis sur le bonne voie...

Merci les gars! C'est vraiment sympa !

J'aime la megadrive pour le son très typé du YM2612, et je compte allez le plus loin possible...
Gloire à vous les amis ! 

Bravo et bonne continuation

Moi j'avance bien là... , un frisson venu tout droit de 1990 me parcourt à chaque fois que je test la rom...

C'est vrai que ça va vite avec sgdk , j'ai passé le scrolling multidirection, j'ai passé les collisions avec les tiles du décor, et j'ai une physique plateforme bien dynamique, sans bug et tout à fait acceptable... , c'est impressionnant...

C'est une vraie petite passion qui s'empare de moi , parceque je me suis pris tout le delire megadrive/programmateur eprom/ et un "Homebrew player" de chez "retroelectronik" ..etc..

J'ai prétendu ne poser qu'une question joker par mois mais... je ne peux pas respecter ce que j'ai dit..., l'attrait est trop fort..., faut me pardonner... , y faut que je sache un truc pour avancer ou alors c'est un genre d'impatience...

Voilà, cette petite question quand vous aurez le temps:


Pour plusieurs raisons je charge mes palettes comme ça:   

Code:

VDP_setPalette(PAL0, MON_BG);  // ça c'est des const u16
VDP_setPalette(PAL1, MON_FG);  // ça c'est des const u16
VDP_setPalette(PAL2, sonic_sprite.palette->data);
VDP_setPalette(PAL3, enemies_sprite.palette->data);

et puis mes sprites avec SPR_addSprite comme dans l'exemple"sprite"..., bon ok..
J'ai envie d'utiliser le sprite engine alors je fais manger un nouveau sprite à rescomp..
Ce dernier sprite de 4 couleurs utilise certaines des 15 couleurs de mon décor "MON_FG" , donc je le met à PAL1..., ok tout marche bien...

Code:

sprites[11] = SPR_addSprite(&platformemouvante1, fix32ToInt(platfm1_posx[10] - camposx), fix32ToInt(platfm1_posy[10] - camposy), TILE_ATTR(PAL1, TRUE, FALSE, FALSE));

Mais en fait j'arrive pas bien à conceptualiser comment dire à SGDK qu'il faut que ce sprite prenne TELLEs couleurs de ma PAL1 , parceque là il s'affiche à partir de la couleur 1 de la palette... , mais les 4 premières c'est pas les bonnes...

Dois-je utiliser TILE_ATTR_FULL ? mais de quelle façon ? Je lui indique le bon zigouigoui rgb à atteindre dans ma palette ? mais où ou comment dans la syntaxe?  je sais pas comment vous dites...     
(Pourquoi je comprends pas ? C'est parceque je n'ai pas de base en code, je ne maîtrise pas bien des concepts de base et des termes de base, je ne suis pas vraiment au fait de tout ça.., j'avance par empirisme souvent..., désolé... )
  ,)

Content d'entendre que ton projet avance bien, ça donne envie d'en voir un peu plus

Sinon pour ton problème de sprite, il faut que ton sprite utilise les couleurs avec les mêmes indexes que ton image MON_FR. En gros quand tu dessines ton sprite il doit utiliser la même palette que MON_FG et il faut t'assurer que la palette soit bien préservée (avec les couleurs dans le bon ordre) lorsque tu sauvegardes ton image (en PNG ou BMP). Gimp permet de faire ce genre de choses, le contrôle des palettes est très important que tu fais du pixel art

Haaa d'accord! Mais oui biensûr! 
Merci encore Stef ! C'est Gen-ial! je vous ferais voir bientôt...

De rien ! Et n'hésite pas à partager donc un peu tes progrès, je pense que ça fera plaisir à tout le monde