Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

dixit Stef plus haut :

Par défaut le sprite engine fait de l'auto allocation pour tout, et il est un peu stupide... si tu ajoutes plusieurs fois le même sprites, lui ne le voit pas et il va allouer de la VRAM pur chacun d'entre eux, il faut utiliser la méthode SPR_addSpriteEx(..) pour définir l'allocation VRAM manuelle (ou tu le fais après coup avec SPR_setVRAMIndex(.) je crois).

[Invité]

Coucou,
A ces propos, j'aurai aussi une question :

- Comment récupérer le Numéro de frame d'animation d'un Sprite ?

Pourquoi ?
Car cela me permettrai de pouvoir correctement corriger les étapes d'animations après la suppression/Création d'une nouvelle liste.
Je pourrai donc, avant la suppression d'une table complète, sauvegarder la bonne frame d'animation de chacun de mes sprites.

J'ai regardé le code source du SpriteEngine ( le .c ), mais je n'ai pas envie de faire une bêtise ... 

Merci !

[Stef]

Hello tartous !!

 Je suis en train de bidouiller avec SGDK et plus particulièrement avec le sprite Engine. Jusqu'à présent comme un gros débile j'utilisais mon propres sprite engine, car je n'avais jamais compris qu'on pouvait découper les images, les anims and co directement à la compilation ... (Oui, je suis nul ...).

Bon, maintenant que j'ai compris, je me pose quelques questions.

 - Peut on freezer/stopper une animation sans changer avec une animation "statique" ?
 - Peut on accélérer l'animation (parce que la vitesse est initialisée dans le .res) ?

Voilou ! Merci d'avance !

Salut,

En fait si, il est possible de bidouiller "un peu" sur l'animation des sprites avec le sprite engine En interne le sprite egine utilise la variable timer (sprite->timer) pour gérer l'animation. Si tu passes cette variable 'timer' à 0 alors tu figes l'animation (auto animation désactivée), d'aileurs tu peux le faire aussi dans la définition de la ressource si tu souhaites gérer l'animation par toi même.

Pour gérer l'animation par toi même tu as 2 fonctions :
SPR_setAnim(..) pour choisir l'animation (ligne de ton sprite sheet) et SPR_setFrame(..) pour choisir la frame d'animation. Avec l'auto animation du Sprite Engine normalement tu utilises seulement SPR_setAnim(.) mais si tu veux gérer l'animation "manuellement" avec tu peux utiliser SPR_setFrame(..) en plus.

@vetea>tu peux récupérer l'indice d'animation et de frame en cours avec :
sprite->animInd  (animation index)
sprite->seqInd  (seq frame index)

Du coup si tu veux restaurer un sprite à un état particulier, tu récupères la valeur de ces variables, éventuellement la valeur de la variable timer aussi et ensuite pour remettre ton sprite dans le même état tu peux faire :

Code:

SPR_setAnim(spr, savedAnimIndex)
SPR_setFrame(spr, savedSeqInd)
spr->timer = savedTimer

J'espère que ça vous aidera dans vos bidouilles

[Invité]

Génial !!
T'es un zamour Stef !!

[fourchette]

salut à tous,

pas une question spécifique sgdk, mais peut être faisable avec : est-il possible de lire quelquepart la position courante du scrolling d'un plan ? j'ai l'impression de ce que j'ai pu lire ça et là que non mais si quelqu'un pouvait me le confirmer...

[Tryphon]

Tu prends le problème à l'envers : c'est à toi d'imposer cette valeur et de la stocker dans une variable !

[fourchette]

donc il n'existe pas de registre où lire cette position ?

[Stef]

En fait c'est possible en lisant dans la VRAM mais effectivement ce n'est pas logique de devoir faire ça.

[fourchette]

Merci pour l'info.

[Fax]

Bonjour tout le monde.

Existe-t-il un moyen de faire du scaling avec SGDK depuis le sprite engine ou en modifiant le tile directement ?
J'ai vu que Vétéa avait réussit en bidouillant les bmp. Une autre solution existe-t-elle ?

Merci !!

[Stef]

Il y a une fonction de scaling dans le mode bitmap mais bien sur rien au niveau des sprites ou background ^^
A voir si tu peux utiliser la méthode pour le mode Bitmap (BMP_scale(..)) et l'adapter pour des sprites.. mais ça demandera une conversion en tiles au moins.

[fourchette]

Salut à tous,

J'ai un soucis avec la function VDP_drawImageEx().

J'ai deux images que je souhaite charger, une sur le plan B, l'autre sur le plan A. Elles représentent à elles deux 1633 tiles en VRAM, mais impossible de les afficher en même temps, celle du plan B est remplie d'artifact dont je ne connais l'origine...

Est-ce que quelqu'un connaitrait l'origine du problème ?

[edit]
A priori le problème se pose quand je remplis les tiles en dépassant l'offset 0x5FF (ou proche) dans la VRAM

Questions subsidiaires :
- a-t-on la totalité des 64k de VRAM à disposition ?
- pourquoi Gens-KMod ne présente que les tiles jusqu'à l'offset 0x71F au lieu de 0x07FF ?

[Stef]

1633 tiles ?? sans ancun tiles dupliqués ?? Bon ben ça fait plus de 50 ko de VRAM de bouffer, ça ne tiendra pas avec les tilemaps et le reste ! Pour les tiles, SGDK doit te laisser environ 1500 tiles de dispo par défaut, et encore peut etre moins (je me souviens plus exactement).
Sinon oui, Gens KMod a un bug sur l'affichage des tiles je crois, ce n'est pas moi qui ai développé ce module supplémentaire, Kaneda aurait du reprendre le debugger intégré de Gens juste pour cette partie :)

[Stef]

Nouvelle version de SGDK qui passe en 1.30.
La grosse nouveauté c'est le nouveau GCC 6.3 (Encore un gros merci à Gligli qui s'est tapé tout le sale boulot ^^). Cette nouvelle version de GCC en plus d'ajouter de nouvelles fonctionnalités va surtout produire un bien meilleur code que le vieux GCC 3.4.6 que SGDK utilisait auparavant...  et donc théoriquement vous devriez voir un gain significatif des performances (entre 20% et 50% je pense) sur votre code C :)
Comme promis j'ai aussi ajouté le Y sorting (et même un sort générique) pour le Sprite Engine, une fonctionnalité qui manquait cruellement.

Lien download :
https://www.dropbox.com/s/b3rso72uousjk7l/sgdk130.7z?dl=0

Changelog :

DOCUMENTATION
* updated to last version

COMPILER
* Updated to GCC 6.3 (thanks a tons to Gligli for that !)
- many bugs fix and new features compared to old GCC 3.4.6
- much better assembly code generation
- added LTO (Linker Time Optimization) support
* Modified makefile to enable LTO and improve optimization level.
* Rescomp:
- updated to handle structure changes in the Sprite Engine.

LIBRARY
* DMA:
- minor optimization to DMA_queue(..) method (thanks to HpMan)
* Memory:
- default stack size increased to 0x800 bytes (GCC 6.3 requires more stack memory :p)
* Sprite Engine:
- added automatic Y sorting (per sprite)
- added SPR_sort(..) for generic sorting
- added SPR_sortOnY(..) for generic sorting
- by default now sprite visibility is set to always ON (faster than automatic visibility)
- updated 'Collision' structure (hierarchical structure)
- some changes to internal structures to provide better performance
* VDP BG/Tile:
- fixed a minor bug in VDP_setTileMapDataEx(..) and VDP_setTileMapDataRectEx(..) methods (thanks to Alekmaul for reporting it)
* minors fixes...

SAMPLE
* Bench:
- fixed math tests for GCC 6.3

[Invité]

Super, merci bien de cette mise à jour ! Je teste de ce pas avec mon jeu !

[Tryphon]

Merci

[Invité]

Merci Stef !!!!

[vincent2105]

C'est beau de savoir que plusieurs projets vont pouvoir en profiter.
Chapeau pour l'ensemble de ton travail Stef !

[Stef]

Merci à vous  Moi ça me fait plaisir de voir que mon travail sert est utile

[Invité]

Attention, compiles plus pour moi.
Plusieurs soucis :
1) j'utilise un autre msys sur mon poste, ça vient interféré avec les dll qui sont dans le rep bin.
2) j'ai aussi ce pb :

Code:

In file included from f:/mddev/inc/genesis.h:14:0,
                 from bat.c:1:
f:/mddev/inc/font.h:18:20: fatal error: libres.h: No such file or directory

Le fichier n'est plus dans le répertoire res où il était dans la précédente version :)

[Stef]

Attention, compiles plus pour moi.
Plusieurs soucis :
1) j'utilise un autre msys sur mon poste, ça vient interféré avec les dll qui sont dans le rep bin.
2) j'ai aussi ce pb :

Code:

In file included from f:/mddev/inc/genesis.h:14:0,
                 from bat.c:1:
f:/mddev/inc/font.h:18:20: fatal error: libres.h: No such file or directory

Le fichier n'est plus dans le répertoire res où il était dans la précédente version :)

Ah oui j'ai encore fait l'erreur de virer ce fichier... Si tu recompiles la librairie il est regénéré automatiquement mais je viens de mettre à jour l'archive de toute façon :)

[Invité]

Au fait, j'aurai une question concernant la routine
Est ce qu'elle gère les MetaSprite ( genre des sprites crées de 48x48 par exemple avec le SE. ) ?
Merci !

Et de rien pour le don, c'est naturel et normal ! 
C'est grâce à des personnes comme toi que des quidams comme moi, réalisent leur rêve. :)

[Stef]

Au fait, j'aurai une question concernant la routine <Yorder>
Est ce qu'elle gère les MetaSprite ( genre des sprites crées de 48x48 par exemple avec le SE. ) ?
Merci !

Bien sur, à la base dans le sprite engine un sprite est un meta sprite, donc la priorité s'applique dessus directement

[Invité]

Ralala !!! C'est encore plus génial !!
Merci copain !!

[fourchette]

Merci pour cette nouvelle version du SGDK, je l'essaierai dès que possible.

[Invité]

J'aurai une autre question sur le Ysort !! 
Est il possible ( ou non  de pouvoir faire un traitement sur des ID précis d'une liste ?
Exemple :
J'ai 10 unités qui se baladent.
Chaque unité peut tirer 3 balles.
Moi, ça ne m'intéresse pas de faire un Ysort sur les balles, elles auront une priorité basse, donc crée en dernier lieu.
Je voudrais juste faire un Ysort sur les 10 premiers unités.

Est ce que c'est possible donc ?

[Stef]

J'aurai une autre question sur le Ysort !! 
Est il possible ( ou non  de pouvoir faire un traitement sur des ID précis d'une liste ?
Exemple :
J'ai 10 unités qui se baladent.
Chaque unité peut tirer 3 balles.
Moi, ça ne m'intéresse pas de faire un Ysort sur les balles, elles auront une priorité basse, donc crée en dernier lieu.
Je voudrais juste faire un Ysort sur les 10 premiers unités.

Est ce que c'est possible donc ?

Comment tu fais le Y sort actuellement ? J'imagine que tu utilises la méthode SPR_sortOnYPos() ?
En fait tu as une autre méthode, tu peux demander à SGDK de faire le Y sort sur un sprite en particulier.
Quand tu déclares ton sprite, soit tu utilises SPR_addSpriteEx(...) avec SPR_FLAG_AUTO_YSORTING d'activé, sinon plus simple tu ajoutes ton sprite avec SPR_addSprite(..) et ensuite tu utilises SPR_setYSorting(sprite, TRUE) pour activer le Y sorting pour ce sprite en particulier.
De cette manière tu peux choisir quels sprites doivent être triés ou pas... donc ici tes persos, mais les balles pas la peine :)
Et quand tu utilises cette option tu n'as plus besoin d'appeler SPR_sortOnYPos() bien sur

[Invité]

Génial !
Sur la démo, je déclare juste la routine comme un bourrin ! 
Je ne savais pas toutes ces subtilités, pas encore lu en détail la mise à jour de la doc' ...
Merci Stef !!

[Stef]

:)
J'ai oublié d'en parler mais il y a aussi une différence qui accélère bien les performances du sprite engine : avant par défaut celui-ci calculait automatiquement la visibilité des sprites (pour économiser la limite de sprites par ligne) alors que maintenant il considère les sprites toujours visible par défaut (ce qui est souvent le cas). Ca contribue à la différence de performance observé sur le SE (et il y a aussi d'autres optimisations).

[philip]

Merci stef pour ce travail que j'imagine monstrueux. 
Et bonne nouvelle pour le sprite engine sur lequel je me pencherais prochainement.

[Invité]

Oui c'est clair que ça doit être un travail monstrueux.

Pour moi, l'une des manières d'encourager des personnes comme Stef, qui prennent beaucoup de leur temps, pour créer des outils permettant à des passionnés comme nous de créer des jeux sur des consoles rétros, c'est, en plus des remerciements qui sont important, le soutien par un Don ( https://stephane-d.github.io/SGDK/ ) !

C'est très motivant, ça encourage l'auteur à mettre à jour et améliorer son devkit et en plus, c'est aussi un des nerfs de la guerre ( sinon le seul !  )

En plus, Stef est vraiment l'une des personnes que j'aimerai rencontrer le plus à la prochaine RGC. Il est doué, humble, simple et toujours disponible pour aider, donner des conseils avec cette pédagogie si rare chez les "nymformaticiens".
Je le serrerai volontiers dans mes gros bras !

Le Graal, sera le prochain jeu crée avec SgdK qui sera édité en physique, la meilleure des publicités !!
Papi Commando Tennis fera partie de ces prochains jeux, ainsi que de nombreux d'autres, surtout COD d'AlekMaul.

Encore merci Stef !