Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Coucou,
Bon ben après une petite rechute avec BEX pour mon projet BOBC SE ( bientôt publié par CG  ), je vais me remettre tranquille avec SgdK.
Du coup, pas de mise à jour depuis la SGDK 1.33 (November 2017) ?

Je vais réaliser le même tuto "Metal Slug" que j'avais fait avec BEX pour me remettre sur les rails, et après la publication de BOBC SE, me remettre sur mes "chantiers".
Certainement Papi Commando Reload'ed', avec l'apport d'un nouveau graphiste talentueux qui a aussi collaboré sur BOBC SE concernant la Cover et autres petits trucs ...

A bientôt.

[Invité]

Nouveau projet Sgdk en KS :
https://www.kickstarter.com/projects/835242565/tanzer-a-new-sega-mega-drive-genesis-exclusive-gam/comments

[drludos]

Sympa ce projet, et l'objectif est pas délirant (2000€) du coup il l'ont déjà atteint. On sent le mix entre Hagane et Turrican ou Shadow of the Beast pour l'inspiration !

Bon courage Vétéa pour la reprise de tes projets SGDK, il nous tarde d'en voir plus sur Papi Reloaded !

[Stef]

Merci pour l'info pour le KS Vetea :-) l'auteur du jeu m'en avait parlé mais je ne savais pas qu'il avait finalement lancé le projet (2000e par contre c'est vraiment rien). Sinon pour SGDK, oui ça fait quelques temps qu'il n'y a pas eu de nouvelles versions :-( j'ai quelques corrections à inclure pourtant (déjà dispo sure GitHub) mais il faut que je trouve le temps de faire une vraie nouvelle version...

[Invité]

Oui, et en plus ce n'est pas si une mauvaise idée que ça de mettre l'objectif qu'à 2000 $ ... On voit que son KS explose ( déjà 4300 $ !! Et ce n'est que le début ... ), ça va faire plus que le projet d'Orion en même pas quelques jours ... De quoi faire râler putain.

Sinon, petit interview du bonhomme, qui est un vrai talent :
http://www.retrovideogamer.co.uk/rvg-interviews-mikael-tillander/

[Stef]

Franchement ça ne m'étonne pas trop que son KS marche pas si mal, après il a demandé que 2000$, je ne suis pas sûr que ce soit une bonne stratégie surtout qu'il a déjà une démo très solide. Il aurait pu être bien plus ambitieux je pense (20000$) mais sa page KS n'est pas hyper sexy non plus (et ça je reconnais que c'est la partie la plus difficile dans un KS).. À la différence de Orion il propose un jeu pour une seule plate forme, et il faut admettre que si le principe de son jeu est assez simple, la réalisation est à la hauteur de la MD, et la gameplay a l'air efficace. Ce n'est pas un gros gros jeu non plus mais c'est partie pour être un très bon jeu quand même. Moi en tout cas ça me donne plus envie de Backer que sur les projets multi plateforme de Orion (désolé Orion si tu me lis :-p mais c'est aussi pour pointer du doigt ce qui attire plus ici)

[Invité]

Ben moi je préfère backer à titre privé SgdK et son auteur.  

[troudki]

 ça fait quelques temps qu'il n'y a pas eu de nouvelles versions :-( j'ai quelques corrections à inclure pourtant (déjà dispo sure GitHub) mais  il faut que je trouve le temps de faire une vraie nouvelle version...

Hello Stef, 
Merci encore pour ce travail d'amélioration continue sur ce framework . En attendant les prochaines features de la 1.4, peut être re-faire une petite explication sur le couple rescomp + sprite engine, les contraintes, les limites, etc.. J'avoue que des fois je ne sais pas pourquoi et comment ça marche

[Stef]

 ça fait quelques temps qu'il n'y a pas eu de nouvelles versions :-( j'ai quelques corrections à inclure pourtant (déjà dispo sure GitHub) mais  il faut que je trouve le temps de faire une vraie nouvelle version...

Hello Stef, 
Merci encore pour ce travail d'amélioration continue sur ce framework . En attendant les prochaines features de la 1.4, peut être re-faire une petite explication sur le couple rescomp + sprite engine, les contraintes, les limites, etc.. J'avoue que des fois je ne sais pas pourquoi et comment ça marche

Salut Trouki,

Oui je sais pour ces fichus tutos, mais c'est vraiment quelques choses qui prend du temps si je veux le faire correctement. En fait à la base il faut connaitre les contraintes de la machine pour comprendre les différentes contraintes sur les ressources. Pour faire simple, tu peux considérer que tes sprites doivent faire 16 couleurs (15 couleurs + 1 transparente qui doit toujours être à l'index 0 de ta palette). Chaque ligne de ton sprite sheet correspond à une animation, et chaque case à une frame d'animation. La taille de chaque case étant forcément aligné sur 8 pixels. Le sample "sprite" inclus dans SGDK te montre un peu tout ça (tu peux regarder comment les ressources sont déclarées dans cet exemple). Mais réellement oui il faudrait un vrai tuto pour expliquer tout ça

[Stef]

Ben moi je préfère backer à titre privé SgdK et son auteur.  

Merci, mais je t'assure que tu as déjà bien largement contribué
A force je vais devoir rajouter un logo "powered by Vetea Studio"

[upsilandre]

Nouveau projet Sgdk en KS :
https://www.kickstarter.com/projects/835242565/tanzer-a-new-sega-mega-drive-genesis-exclusive-gam/comments

Les explosions me font beaucoup penser a Mystic Defender

[TotOOntHeMooN]

Bien plus ambicieux que Xeno Crisis pour un prix dérisoire.

[Invité]

Surtout que le gars fait tout, tout seul, hormis la musique.
Il a déjà réalisé 2 jeux édités sur C64, développé sur Android, Pc ... bref, un gars passionné et compétent. 
On reconnait presque un ton de couleur très C64 sur la MD je trouve.

@Toot' : Xeno quoi ... ?? Connais po. ^^

[IK+]

.

[troudki]

ces fichus tutos, mais c'est vraiment quelques choses qui prend du temps si je veux le faire correctement. En fait à la base il faut connaitre les contraintes de la machine pour comprendre les différentes contraintes sur les ressources.

Les tutos sont bien faits et très bien détaillés ,c'est plutôt ces commandes où des fois on arrive pas trop à bien à saisir les subtilités.. une commande aussi basique SPR_init(u16 maxSprite, u16 cacheSize, u16 unpackBufferSize), déterminer la méthode pour assigner le cacheSize et unpackBufferSize, c'est par une approche assez empirique avec des résultats visibles sur l'écran ou en debug visuel de la VRAM..
C'est souvent dans des projets un peu long et dans les phase d'optimisation à la fin qu'on se pose toute ces questions.

[Stef]

Les tutos sont bien faits et très bien détaillés ,c'est plutôt ces commandes où des fois on arrive pas trop à bien à saisir les subtilités.. une commande aussi basique SPR_init(u16 maxSprite, u16 cacheSize, u16 unpackBufferSize), déterminer la méthode pour assigner le cacheSize et unpackBufferSize, c'est par une approche assez empirique avec des résultats visibles sur l'écran ou en debug visuel de la VRAM..
C'est souvent dans des projets un peu long et dans les phase d'optimisation à la fin qu'on se pose toute ces questions.

Ah ce genre de chose, en fait il y a toujours la documentation qui explique l'utilité de chaque paramètre mais je prévois de rendre ça plus simple avec un SPR_init() sans paramètre et un autre "plus avancé" avec quelques paramètres

[Tryphon]

Un truc qui est dommage en C, c'est que tu peux pas préciser des valeurs par défaut aux paramètres...

[Stef]

Un truc qui est dommage en C, c'est que tu peux pas préciser des valeurs par défaut aux paramètres...

Oui c'est vrai, d'où plusieurs fonctions (mais que tu dois nommer différemment )

[Stef]

Nouveau projet Sgdk en KS :
https://www.kickstarter.com/projects/835242565/tanzer-a-new-sega-mega-drive-genesis-exclusive-gam/comments

Les explosions me font beaucoup penser a Mystic Defender

Tu as vraiment un œil de lynx

[Invité]

Aahh la fonction SPR_Init() ... Elle nous avait causé du fil à retordre lors de l'élaboration de la démo Tectoy de Papi Reload !

[drludos]

Petit déterrage du sujet avec deux petits questions techniques sur SGDK:

- Tout d'abord, avec Rescomp, comment est-il possible de déclarer qu'une ressource "Image" doit être générée avec une tilemap où toutes les tiles sont de priorité "haute" ? Car par défaut elles sont forcément en priorité "basse", est donc affichées derrière les sprites.

- Ensuite, est-ce qu'il possible d'activer / désactiver l'affichage des "planes" de décor à volonté ? Dans mon cas, je voudrais charger un écran "dialogue" assez touffu niveau tiles / tilemap sur le plan A, et faire qu'il ne s'affiche quand mon perso parle à un PNJ, puis qu'il disparaisse une fois le dialogue terminé.
Afin d'éviter d'avoir à effacer / recharger la tilemap à chaque dialogue, est-il possible de la laisser en permanence sur le plan A et de ne faire que "masquer" ou "afficher" ce plan quand j'en ai besoin ?
(je sais que sur SNES c'est possible, mais sur MD je sais pas si le VDP est prévu pour)

Merci pour vos lumières !

Au passage mille bravo Stef pour ce SGDK. Quand on est débute, la mise en route est vraiment très très simple, notamment grâce au sprite engine :)

Même si j'imagine que les projets "costaud" comme Papi Reload ou Xeno Crisis n'utilisent pas le sprite engine mais plutôt les fonctions de bas niveau pour avoir plus de performance, je suis vraiment impressionné du nombre de sprites qu'on peut afficher / déplacer / animer / collissioner en quelques lignes de codes avec ce sprite engine :)

[Hpman]

Je suis pas expert mais il me semble pas qu'on puisse désactiver les plans.

Du coup pour masquer une boite de dialogue que tu ne veux pas recharger:
- scroller le plan hors de la zone visible
- changer l'addresse du tilemap vers une tilemap vide
- masquer le plan A avec le plan window
- placer les dialogue sur la window et faire varier sa taille (possible ca?)

Bon tout ça implique de gaspiller de la VRAM pour afficher du vide, je suis pas convaincu que ça soit mieux que de juste redraw la boite de dialogue.

[Stef]

- Tout d'abord, avec Rescomp, comment est-il possible de déclarer qu'une ressource "Image" doit être générée avec une tilemap où toutes les tiles sont de priorité "haute" ? Car par défaut elles sont forcément en priorité "basse", est donc affichées derrière les sprites.

Le tilemap à partir d'une image est toujours en mode défaut (palette 0, basse priorité), pour modifier ces attributs tu dois utiliser l'argument basetile dans les méthodes qui te permettent de manipuler le tilemap (VDP_setMap / VDP_setMapEx,  VDP_setTileMapDataEx, VDP_setTileMapDataRectEx, ...). Dans basetile tu peux définir la priorité et la palette de base à utiliser pour l'affichage du tilemap :)

- Ensuite, est-ce qu'il possible d'activer / désactiver l'affichage des "planes" de décor à volonté ? Dans mon cas, je voudrais charger un écran "dialogue" assez touffu niveau tiles / tilemap sur le plan A, et faire qu'il ne s'affiche quand mon perso parle à un PNJ, puis qu'il disparaisse une fois le dialogue terminé.
Afin d'éviter d'avoir à effacer / recharger la tilemap à chaque dialogue, est-il possible de la laisser en permanence sur le plan A et de ne faire que "masquer" ou "afficher" ce plan quand j'en ai besoin ?
(je sais que sur SNES c'est possible, mais sur MD je sais pas si le VDP est prévu pour)

Pour confirmer et compléter la réponse de Hpman, il n'y a effectivement pas de fonction pour "désactiver" un plan. Hpman propose différente possibilités pour faire ce que tu veux, mais comme lui je pense que le mieux est encore de redessiner le tilemap quand c'est nécessaire, car normalement ce n'est pas quelque chose de très lourd. Là où ça peut être lourd, c'est si jamais tu dois également recharger les tiles en VRAM pour l'affichage du dialogue mais théoriquement tu devrais toujours les garder en VRAM pour accélérer et simplifier le processus... du coup tu redessines juste le tilemap, et c'est rapide :)

Au passage mille bravo Stef pour ce SGDK. Quand on est débute, la mise en route est vraiment très très simple, notamment grâce au sprite engine :)

Même si j'imagine que les projets "costaud" comme Papi Reload ou Xeno Crisis n'utilisent pas le sprite engine mais plutôt les fonctions de bas niveau pour avoir plus de performance, je suis vraiment impressionné du nombre de sprites qu'on peut afficher / déplacer / animer / collissioner en quelques lignes de codes avec ce sprite engine :)

Merci J'essai d'améliorer et de rendre le sprite engine le plus simple et fonctionnel possible. Je suis plutot satisfait du résultat pour l'instant, en terme de performance "ça tient la route" même si on peut bien sûr faire beaucoup mieux avec un moteur customisé J'ai encore un peu de marge pour améliorer ça en passant les sections critiques en assembleur mais ça viendra plus tard, quand le sprite engine sera "plus mature" et moins sujet à modification.

[drludos]

Merci @HpMan et @Stef pour votre aide! Je pense que je vais opter pour l'effacement / redessin de la tilemap alors, surtout si ce n'est pas le plus gourmand en temps CPU/VDP (les tiles restant effectivement en VRAM).

Pour la priorité "haute", j'ai vu qu'on pouvait la modifier via "basetile" dans chaque fonction "Ex", mais la doc de Rescomp laissait supposer qu'on pouvait aussi le faire directement dans le type "Image" via le paramètre "mapbase"

Code:

mapbase         define the base tilemap value, useful to set the priority, default palette and base tile index.

Mais la syntaxe à utiliser n'est pas précisée :).

Du coup, en utilisant l'argument "basetile" de VDP_drawImageEx, est-il possible de modifier uniquement la priorité, sans avoir à toucher les autres paramètres (notamment en gardant le fait que le moteur définisse automatiquement le tileindex de départ, car quand j'ai testé, il faut forcément en définir un manuellement si on indique un "basetile" à la fonction).

[Stef]

Merci @HpMan et @Stef pour votre aide! Je pense que je vais opter pour l'effacement / redessin de la tilemap alors, surtout si ce n'est pas le plus gourmand en temps CPU/VDP (les tiles restant effectivement en VRAM).

Pour la priorité "haute", j'ai vu qu'on pouvait la modifier via "basetile" dans chaque fonction "Ex", mais la doc de Rescomp laissait supposer qu'on pouvait aussi le faire directement dans le type "Image" via le paramètre "mapbase"

Code:

mapbase         define the base tilemap value, useful to set the priority, default palette and base tile index.

Mais la syntaxe à utiliser n'est pas précisée :).

Tiens donc, je ne me souvenais même plus de ce paramètre ^^
Bon en réalité j'ai regardé le code et tu peux effectivement l'utiliser pour mettre une valeur par défaut pour le "base tile" mais je l'ai mal fait puisque je me contente de faire "ou logique" avec l'indice de palette et l'indice du tile récupéré depuis le tilemap...
Du coup je te conseille d'ignorer ce paramètre qui n'a de toute façon pas vraiment d'utilité puisque tu es plutot censé faire ça au runtime.

Du coup, en utilisant l'argument "basetile" de VDP_drawImageEx, est-il possible de modifier uniquement la priorité, sans avoir à toucher les autres paramètres (notamment en gardant le fait que le moteur définisse automatiquement le tileindex de départ, car quand j'ai testé, il faut forcément en définir un manuellement si on indique un "basetile" à la fonction).

Attention dans le cas de VDP_drawImageEx(..) tu vas non seulement modifier la tilemap mais également envoyer les tiles en VRAM ! C'est beaucoup plus lent (surtout si l'image est compressée) ! Du coup ci en effet le basetile prend également l'index en VRAM pour savoir où uploader les tiles.
Dans ton cas tu es censé uploader les tiles en amont et ensuite uniquement jouer avec la map.

C'est un truc qui revient toujours sur le forum SpritesMinds, je te copie une réponse que j'avais faite il y a longtemps pour expliquer un peu la chose (je parlais de gestion de grande image mais ça revient au même) :

To handle large image like that you need to first upload the tiles to VRAM :

Code:

ind_tileset = TILE_USERINDEX;
// load image tileset with DMA
VDP_loadTileSet(bgb_image.tileset, ind_tileset, TRUE);

Then load sub part of your image map in the background plan depending the current camera / scrolling position :

Code:

VDP_setMapEx(BPLAN, bgb_image.map, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind_tileset), X, Y, mapX, mapY, mapW, mapH);


Be careful with bgb_image.map, if the map is compressed then the VDP_setMapEx(..) method will unpack it each time so it's better to unpack it first if needed with :

Code:

Map *map = unpackMap(bgb_image.map, NULL);

and use the map variable then

En gros il faut décomposer ton image en Tileset et en Map, tu charges une seule fois le Tileset au départ et ensuite tu utilise la Map pour mettre à jour le tilemap.

[drludos]

Merci beaucoup Stef pour les explications et ton aide!

Je comprends mieux l'utilité ainsi du "tileindex" dans le param baseTile :).

[Invité]

Salut, je voulais savoir si quelqu'un pourrait partager documents pour apprendre à faire des calculs, car je galère totalement pour en faire avec le SGDK.

Je suis habitué à avoir des fonctions intégré pour effectuer des calculs courants et j'avoue que j'ai pas du tout le niveau pour tout faire moi-même.

Merci

[Stef]

As tu déjà regardé cette page qui peut t'aider ?
https://github.com/Stephane-D/SGDK/wiki/Tuto-Maths

Après pour les maths en général, tu as google qui peut t'aider ;p

[Tryphon]

J'avais pas vu ton mail Shingo. Tu peux être plus précis ?

[Invité]

Super j'avais pas connaissance de ce tutoriel, ça va déjà m'aider !

@Tryphon mon problème c'est que je suis pas habitué à coder mes propres algo. Par exemple, je suis incapable de diriger un sprite vers un autre. J'avais bossé avant sur la lib SFML2 et cette dernière implémente déjà beaucoup d'algo et c'est assez simple de faire ce genre d'opération :

sprite.move(- target * speed);

[Tryphon]

Il est déjà important que tu saches précisément ce que tu veux :

* est-ce que tu veux que sprite aille jusqu'à target à vitesse constante ?

* est-ce que tu veux qu'il y aille en un nombre d'étapes prédéterminé ? (auquel cas sa vitesse sera d'autant plus grande que les deux sont éloignés)

* si target bouge pendant que sprite se déplace vers lui, est-ce que sprite doit ajuster sa direction ?

Ensuite faut traduire tout ça sur les coordonnées. C'est pas des maths bien compliquées.