Re: Sgdk - Sega Megadrive / Genesis Development Kit

[troudki]

Hello
Avec la nouvelle version SGDK 1.34 sortie récemment  (merci stef), est ce que vous voyez bien les sprites affichés dans le sample sprite ?
++

[Stef]

Dis moi pas que j'ai laissé une (grosse) coquille de ce genre ? ^^

Edit: ah ben si, j'ai oublié d'ajouter une ressource dans le repository, c'est corrigé
Si tu télécharges l'archive depuis la section "release" il n'y avait pas de soucis heureusement :)

[troudki]

j'ai téléchargé l'archi..ca compile bien mais c'est en testant sur divers émulateur que je ne vois aucun sprite du sample sprite..

[Stef]

J'ai essayé ici et je n'ai aucun problème (tout les sprites bien visibles).
Essais de recompiler la lib (avec le fichier build_lib.bat), et ensuite rebuild le sample sprite pour voir si ça change quelque chose.

[Invité]

Je n'étais pas au courant pour la mise à jour.

Quoi de neuf sous le capot?

[TotOOntHeMooN]

C'est ça que je trouve cool dans les libs de jeux... Tu as une base commune à plein de projets, et il suffit que des optimisations soient faites, pour qu'avec un simple rebuild, tous les projets en profitent. 

J'aimais beaucoup Allegro sur PC pour cela. (qui a vu le jour sur ST, je sais)

[Invité]

Je n'étais pas au courant pour la mise à jour.

Quoi de neuf sous le capot?

LIBRARY
* DMA
 - added DMA queue support for all (or almost all) methods supporting DMA operation
* SPRITE
 - fixed timing issue when changing FRAME or ANIMATION manually.
 - fixed sprite sorting when multiple depth were modified in a single SPR_update(..).
 - safer sprite allocation / release.
* MEMORY
 - added MEM_getLargestFreeBlock() to get the largest available block of memory.
* improved LZ4W compression (better compression rate, faster compression...)
* minors changes on method updating tilemap through X,Y position (safer)
* some cleanup

SAMPLE
* reworked benchmark sample to avoid out of memory error (^^)

[Stef]

Oui voilà, petite mise à jour ^^
Quand je fais une grosse MAJ je communique un peu plus dessus.

Il y a la compression LZ4W que j'ai amélioré mais ça se remarque uniquement pour des gros blocs de données. A l'avenir je vais aussi améliorer rescomp (le compilateur de ressource) pour qu'il en tire un peu plus partie aussi.

[Invité]

Vous êtes sûr que la carte n'a pas de taille max ? J'ai fais une carte de 512 tiles et ça me donne un écran noir

[Igor]

Hy Stef, im New to sgdk but im making a good progress with, i came here to speak with you about How i can handle colision with sgdk ? I see many people discuss It in spritesmind but cant understand How to make It

[Invité]

C'est bon j'ai compris le problème, il fallait ne pas utiliser de compression !

Par contre Stef, j'aimerais savoir un truc. Tu conseilles plutôt d'utiliser de grandes images comme je le fais 1024 tiles ou bien de faire un tileset et de générer la map dans le code ? C'est quoi le plus rapide / performant ?

[Invité]

Salut, j'essaie de faire du scrolling par line et le rendu est pas terrible, c'est même affreux

Code:

VDP_setHorizontalScrollLine(PLAN_B, 200, +scroll, 24, FALSE);

Le scrolling est beaucoup trop rapide et quand j'utilise getTick() pour limiter le temps, le scrolling n'est pas du tout fluide.

Un peu d'aide serait la bienvenue!

edit : ok, j'ai compris, le mieux c'est le scrolling par tiles !

[Stef]

Hy Stef, im New to sgdk but im making a good progress with, i came here to speak with you about How i can handle colision with sgdk ? I see many people discuss It in spritesmind but cant understand How to make It

hi Igor,

I think it's better to keep the discussion on SpritesMind as Gamopat is a french board
Still collision is a tricky subject which is not limited / restricted to SGDK in general, it depends if you speak about object vs object colission or object vs background collision etc... any game engine has its own way to handle collisions

Le scrolling est beaucoup trop rapide et quand j'utilise getTick() pour limiter le temps, le scrolling n'est pas du tout fluide.

Un peu d'aide serait la bienvenue!

edit : ok, j'ai compris, le mieux c'est le scrolling par tiles !

Heuu... ta conclusion me fait peur
Depuis peu SGDK embarque un sample qui s'appelle XGM Player (c'est le fameux player de musique que j'utilise pour faire des compilations ^^) : https://github.com/Stephane-D/SGDK/blob/master/sample/xgmplayer

Dedans je fais un petit scrolling type starfield dans le fond qui utilise le scrolling par line de la MD :
Je te met les fonctions qui t'interessent ici :

Code:

#define SCROLLV_LEN    224

// BG starfield scrolling
static s16 scrollB[SCROLLV_LEN];
static fix16 scrollBF[SCROLLV_LEN];
static fix16 scrollSpeed[SCROLLV_LEN];


static void initBGScroll()
{
    s16 i, ns, s;
    fix16* sf = scrollBF;
    fix16* ss = scrollSpeed;

    // create the scrolling offset table
    s = 1;
    i = SCROLLV_LEN;
    while(i--)
    {
         *sf++ = FIX16(0);
         do
         {
             ns = -((random() & 0x3F) + 10);
         } while(ns == s);
         *ss++ = ns;
         s = ns;
    }
}

static void updateBGScroll()
{
    s16 i;
    fix16* sf = scrollBF;
    s16* s = scrollB;
    fix16* ss = scrollSpeed;

    i = SCROLLV_LEN;
    while(i--)
    {
        *sf += *ss++;
        *s++ = fix16ToInt(*sf++);
    }
}

En gros j'ai 3 tables :
- la valeur de scrolling pour chaque ligne au format fixed point (fix16 : ça permet qui d'avoir un chiffre à virgule).
- la vitesse de scrolling pour chaque ligne au format fixed point (fix16 toujours)
- la valeur de scrolling pour chaque ligne au format entier (c'est la partie entière de la valeur fix16, celle qu'on va envoyer au VDP)

Ensuite tu envoie la table contenant les valeurs entières en VRAM en utilisant la méthode que tu as utilisé plus haut, ou tu fais comme un bourrin comme moi direct avec DMA si tu sais ce que tu fais ^^ :

Code:

DMA_queueDma(DMA_VRAM, (u32) scrollB, VDP_HSCROLL_TABLE + 2, SCROLLV_LEN, 4);

[upsilandre]

Je pense que ce que shingosama appelle un scrolling a la ligne c'est juste un scrolling hardware vertical de l'ecran au pixel, un vrai scrolling quoi (pas software a la tuile). La t'es en train de lui présenter des methodes de scrolling avancé alors qu'il a pas encore assimiler la base je pense :)

[Invité]

Je vais regarder ce soir l'exemple.

En fait, j'ai un BG avec des étoiles et j'aimerais scroller plusieurs lignes afin de donner de la profondeur comme c'est le cas dans la plupart de shmup sur Mega Drive.

Par exemple dans Thunder Force 3, on y voit les étoiles se déplacer à différentes vitesses, ce qui donne une profondeur de champ.

[upsilandre]

ok dans ce cas c'est bien ce dont te parle Stef

[Invité]

Oui, du coup je vais étudier ce petit bout de code :)

La track d'ActRaiser est juste magnifique, merci Stef :)

[Invité]

J'ai profité de ma pause déjeuner pour reprendre ton code simplement. Cela fonctionne très bien, mais pas correctement avec le starfield que le graphiste m'a donné. Va falloir que je lui demande de retravailler le BG.

Je vous tiens au courant les poulets :)

[Invité]

Voilà ce que donne le scrolling par ligne. Je trouve que c'est assez impressionnant cette profondeur possible avec un seul plan.

Par contre, je n'ai pas compris à quoi servait la fonction initBGScroll().

[Tryphon]

Excellent !

[GliX]

Salut les gens,

Je me suis mis au dev avec SGDK depuis quelques jours, et c'est un vrai bonheur, bravo et mille mercis Stef.
Je viens de remarquer quelque chose de troublant, lorsque j'utilise la méthode SPR_addSprite plusieurs fois, je retrouve la ressource chargée autant de fois dans la VRAM. Je me serai attendu à ne la retrouver qu'une seule fois (exemple pour une projectile instancié moult fois).
Je précise que je fais cet appel uniquement à l'init.

J'aurai une dernière question, quel est le moyen le plus efficace pour "tinter" un Sprite?
Je m'explique, pendant quelques frames je souhaite rendre un Sprite d'une couleur unie tout en conservant sa transparence, sans altérer sa palette qui sera sans doute partagée et avec la possibilité de pouvoir évidemment rendre plus tard à ce Sprite ses couleurs originales.

Merci merci !   :)

[uran]

Voilà ce que donne le scrolling par ligne. Je trouve que c'est assez impressionnant cette profondeur possible avec un seul plan.

Par contre, je n'ai pas compris à quoi servait la fonction initBGScroll().

Sympa, t'as combien de plan différent qui scroll du coup ?
Cela t'embêterait de poster la partie du code qui fait ce scrolling?

[Invité]

@Tryphon merci :)

@uran le code utilisé est celui de @Stef qui l'a partagé un plus haut. Il provient du sample XGMPlayer. Sinon c'est un plan avec un scrolling par ligne. Une technique utiliser dans de nombreux jeux sur Mega Drive afin de donner de la profondeur au plan. Arrow Flash utilise beaucoup le scrolling par ligne.

@Glix je viens de vérifier et pareil pour moi, dans la VRAM j'ai plusieurs fois le même sprite ! Je dis peut-être une bêtise, mais la fonction SPR_addSprite() ajoute automatiquement le sprite dans la VRAM, il faut utiliser SPR_setVRAMTileIndex() pour choisir l'index. Enfin c'est ce que j'ai compris pour le moment.

edit : je confirme, la fonction SPR_setVRAMTileIndex() permet d'utiliser un seul sprite dans la VRAM ! Je viens d'essayer et je n'ai plus de doublon dans la tile ! Par contre, cela améliore les performances du coup ?

[GliX]

Oh yeah, merci @shingosama. 
Je ne sais pas pour les perfs, mais au moins ça laisse logiquement plus de place dans la VRAM.   :)

[Invité]

Je ne sais pas si c'est possible de demander à SGDK de réutiliser un sprite dans la VRAM plutôt que de le faire manuellement, à voir avec @Stef.

[Stef]

@shingo> Bien joué, ça rend super bien dans ton petit shump

@Glix> Merci pour le commentaire sur SGDK ^^ Content de voir autant de gens tenter l'aventure sur MD
Comme l'a expliqué shingosama par défaut la fonction SPR_addSprite(..) utilise une allocation VRAM automatique et SGDK n'a pas vraiment moyen de savoir qu'il doit partager la VRAM sur plusieurs sprites (enfin disons que ça serait compliqué selon les cas de figure et trop pénalisant pour les performances).
Pour passer en mode allocation VRAM manuel tu dois effectivement utiliser la méthode SPR_setVRAMTileIndex(..) ou alors tu utiliser SPR_addSpriteEx(..) qui te permet de spécifier plus de paramètres que SPR_addSprite(..)

Sinon non hélas tu n'as pas moyen de faire ce genre d'effet (flasher un sprite) sans allouer une palette (ou au moins une partie de la palette) juste pour ce sprite. Ou alors tu dois dupliquer les images pour les faire en version 1 couleur mais bon là ça te coûte cher en Rom (tu dois dupliquer les sprites où tu les génères en soft avec le CPU s'ils ne sont pas trop grands)

[Invité]

Salut quelqu'un pourrait me dire combien de sprites peut afficher SGDK ?

Je suis en train de faire des essais et lorsque j'affiche plus de 10 sprites ça déconne pas mal et lorsque j'ai mis 64, boum plantage

[Invité]

Le moteur peut en afficher 128 je crois !
Et je confirme, c'est suffisamment véloce pour en mettre plein la gueule de la MD :



Ici avec 60 sprites avec Algorithmes divers, avant la MaJ du SgdK qui a introduit la gestion Yorder.

[Invité]

Merci Vetea, ça me rassure, je vais donc vérifier ce qui coince dans mon code source :)

Impressionnant le nombre de sprites !

[Tryphon]

La limite du nombre de sprites hard, c'est 80 en mode 320 et 64 en mode 256, si je dis pas de bêtises...

[Invité]

Merci @Tryphon pour la précision.

En fait c'était une définition qui bloquait chez moi, elle était à 8, je l'ai passé à 32, plus de soucis.

Le seul problème que j'ai, c'est qu'il semble y avoir un problème de priorité. Lorsqu'un sprite quitte l'écran, je le désactive avec SPR_releaseSprite(sprite) afin de libérer la mémoire. Par exemple lorsque je tire en continu, pas de soucis, mais si je tire lorsque la vague d'ennemis se pointe, les bullets ne sont pas affichées. Puis quand les bullets s'affichent, des ennemis disparaissent...

J'ai regardé dans le VDP_SPRITE de DGENS et le sprite bullet veut toujours se positionner à la place des sprites ennemies au-lieu d'allouer une place à la suite.

Je ne sais pas si c'est bien de décharger un sprite puis de le charger à la voler ou de le garder de côté.

Y a t-il un moyen de modifier la priorité ?

Code:

player.sprite = SPR_addSprite(&player_ship, player.posx, player.posy, TILE_ATTR_FULL(PAL1, TRUE, FALSE, FALSE, 1));

Serait-ce un comportement normal étant donné que j'ai lu que la Mega Drive ne pouvait pas afficher plus de 20 sprites par ligne ?