Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Effectivement, tu sembles créer plusieurs fois les même sprites .
et un truc qui m'interpelle c'est le sprite 0 de coordonnées 0,0 

[Fax]

Je regarde ça dès ce soir.
Et à partir du numéro 31 pourquoi ais je plein de sprite aux coordonnées 0 en 8x8 sans palette ? Ce sont des données pour afficher mon image de fond ?

[Invité]

Je regarde ça dès ce soir.
Et à partir du numéro 31 pourquoi ais je plein de sprite aux coordonnées 0 en 8x8 sans palette ? Ce sont des données pour afficher mon image de fond ?

Non eux sont tout simplement à leurs valeurs à l'init de la console, ou de la table des sprites (via un spr_clear() ).
Le premier sprite de ta liste ne doit pas avoir de coordonnées 0,0 sinon tout les sprites sur la même ligne (ou de priorité inférieure, je sais plus) ne seront pas visibles .

[Tryphon]

Regarde la 5ème colonne : c'est le link. Ça représente le numéro du prochain sprite à afficher. Quand on retourne au 0, ça veut dire qu'on s'arrête là.

Le sprite n° 34 a un link de 0, ça veut dire que les sprites 35 à 79 ne sont pas affichés.

Donc les seuls sprites "vides" que tu as sont le 0 et du 31 au 34.

C'est quand même un peu le bordel

[Invité]

Ouai en fait c'est ça, sa liste n'est pas fermée, elle l'est par pur hasard(le link de tout les sprites sont initialisés à 0), et du coup comme tu l'as noté boucle sur le sprite 0 qui a comme coordonnées 0,0 .

@fax: le link de ton dernier sprite (le 31 je suppose vu ta table) doit reboucler sur ton premier sprite (tjrs vu ta table, c'est le 1)
En plus tu as 2 sprites avec X=400, donc pas visibles puisque dans l'overscan .

[Stef]

Ce qui est bizarre c'est que s'il utilise le Sprite Engine, le link est géré en interne par celui-ci.. Aussi le sprite 0 est réservé (du coup tu es limité à 79 sprites) par le sprite engine (pour faciliter la gestion du link justement) mais à terme je devrais pouvoir supprimer cette contrainte.

[Fax]

Bon.
Comme dit plus haut j'ai contourné le problème.
Au lieu de mettre un sprite à chacun de mes gobelet, j'ai géré ça par ligne.
Du coup je libère 6 sprites et je n'ai plus ce problème de disparition.

Les redondances dans la liste venaient certainement du fait que j'initialisait les sprites sans attribuer d'animation et de positions à ceux-ci. Du coup ils se retrouvaient tous au même endroit.

Avec ma nouvelle version du projet, j'ai bien le bon nombre de sprite et le dernier boucle sur le numéro 0 via le link.

Je vous tient au courant si un truc bizarre arrive.

Merci à tous en tout cas pour votre aide.

[Invité]

L'essentiel est que tu ais trouvé une solution 

[Fax]

Je rencontre de nouveau un problème.

Pourquoi est-ce que ma seconde image bug ainsi ?
Peux-être ne doit-on pas mettre deux images sur le même plan ?
Peux-être dois-je plutôt en faire des sprites au lieu des images ?

Code:

                ind += fond_image.tileset->numTile;
                VDP_drawImageEx(PLAN_A, &table_bleue_image, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, ind), 4, 3, FALSE, TRUE);
                ind += table_bleue_image.tileset->numTile;
                VDP_drawImageEx(PLAN_A, &table_rouge_image, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, ind), 24, 3, FALSE, TRUE);

[Stef]

A tout hasard je pense que tu dépasses la capacité de la VRAM. Tu dois déborder sur l'espace tile réservé au sprite engine.
Si certaines images ne sont plus à l'écran il n'est pas nécessaire de conserver les tiles de ces images en VRAM, en gros tu peux ré initialiser ind à USER_TILE_INDEX quand tu clear ton écran.

[Fax]

Je suis d'accord avec le diagnostique. Toutefois je n'affiche "que" 1 fond, 2 images que l'on vois sur mon screen et mes 9 sprites.
Est-ce que ça peux suffire à faire bloquer le tout ?

[Tryphon]

Normalement non, à moins que tu envoies 20 fois les mêmes tiles en VRAM.

Regarde la VRAM dans Gens, tu verras bien si elle est saturée.

À signaler : "image" dans la terminologie MD ça n'existe pas, il n'y a que des backgrounds (ou planes : il y en a 2) et des sprites. Quand SGDK dit "image" ou "bitmap", je pense (pas sûr, je ne m'en sers pas) que c'est des fonctions pour aider à manipuler des bouts de backgrounds. Donc 1 bg + 2 images, c'est difficile de voir ce que ça représente vraiment...

[Fax]

Le fait est que j'ai essayé en utilisant uniquement un fond et tout le reste en sprites. Le résultat n'a pas été concluant non plus. Ma VRAM contient encore pas mal de parties rose (transparent chez moi).
Il semble que j'envoie plusieurs fois le même tile en VRAM en initialisation mes sprites. Comment faire pour que cela n'arrive pas ?
En gros j'ai 12 objets identiques niveau graphique mais avec des coordonnées différentes. Un peu comme les anneaux de sonic. Je les ai initialisé en ajoutant à chaque fois au sprite engine.

[Invité]

Surtout qu'on voit bien que les tiles corrompues sont des patterns de tes sprites .
Si tu peux choisir l'emplacement VRAM de tes sprites,c'est peut être eux qui mordent sur la partie réservée aux tiles non ??

[Fax]

J'avais laissé le sprite engine faire le boulot pour l'allocation mémoire. Je me pencherai sur ce point.
Rappel : En gros j'ai 12 objets identiques niveau graphique mais avec des coordonnées différentes. Un peu comme les anneaux de sonic. Je les ai initialisé en ajoutant à chaque fois au sprite engine. Chacun étant géré dans une structure. Une autre méthode ?

[Invité]

Et si tu testes avec juste ton image en VRAM (tu enlèves les sprites), l'image est entière ou pas ??

[Fax]

Oui entière sans soucis.
La j'ai un peu modifié. J'ai mes deux tables images correctes. Sur les 13 sprites j'en ai 6 de bons les 7 autres sont buggé. Ça viens forcément de l'allocation mémoire. Mes sprites reecrivent sur les tîles images. Ou inversement suivant comment je les affiche dans mon code.

[Invité]

Ouai donc les 2 mordent l'un sur l'autre,mais comme le suggère stef, c'est probable que ce soit les tiles qui dépassent,ce qui est étrange vu le peu de VRAM que ton image doit prendre .

[Fax]

Je pense que c'est ça. Une solution ?

[Invité]

Pk ça ?? :

ind += fond_image.tileset->numTile;

Si c'est la première chose que tu mets en VRAM, tu devrais pas avoir juste un = ??

Ensuite pk faire 2 images alors qu'une suffit ??

[Fax]

C'est pas la première chose. La première est le fond _ image.  Par contre c'est sur ça vient de ça. 
J'avais pas capté l'idée de l'index en VRAM...
Je vais essayer de voit ça et je vous redis prochainement.

Merci infiniment.

[Stef]

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).

[Fax]

Ok je viens de comprendre de nouveau pas mal de trucs.
La VRAM est comme une maxi image de tout les tiles 8*8 de notre jeu.
Quand on commence notre init en chargeant une image (un fond), la MD décompose l'image en petits bouts de 8*8 et les ordonnent dans la VRAM de haut en bas.
Ensuite quand on ajoute un sprite, c'est pareil, il va prendre un peu de place dans la VRAM.
J'ai solutionné pas mal de choses en comprenant ça.
Grâce à Gens KMOD, j'ai pu voir que mes sprites commencaient à la ligne "0x0410". En comptant depuis cette valeur et en ajoutant 1 à chaque tile 8*8, j'ai déterminé que je devais "forcer" le VRAM index de mes autres sprites à la valeur "0x0417".

Voir l'image de ma VRAM, en jaune la partie avec mes sprites:

Le code permettant de forcer les positions de mes sprites:

De même pour mon problème de table qui avait un bug graphique, c'est parce que la seconde table débordait sur l'espace des sprites. La fin de ma table était donc remplacée par les tiles de mes sprites. Pour feinter le tout, et dans la mesure où je n'aurai jamais besoin d'afficher les deux tables en même temps et qu'elles font exactement la même taille, je remplace l'image de la première table par celle de la seconde en utilisant le même index :

Code:

   VDP_clearPlan(PLAN_A, TRUE);
    VDP_drawImageEx(PLAN_A, &table_rouge_image, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, idTable), 24, 3, FALSE, TRUE);

De cette façon, la seconde table se dessine sur la VRAM exactement au même endroit que la première, et comme elles font la même taille, elle ne débordera jamais sur les tiles de mes sprites.

J'espère avoir été clair pour ceux que ça intéressent. Quoi qu'il en soit, je pense avoir compris pas mal de nouvelles choses grâce à vous.

Désormais j'essaye de gérer la priorité d'affichage de mes gobelets. J'ai essayé de jouer avec la fonction SPR_setSpriteTableIndex mais celle-ci semble uniquement modifier le link des sprites (le numéro du prochain sprite à afficher). Existe-t-il un moyen pour que je puisse dire : "objet1 devant objet2 lui-même devant objet3" ?
Si aucune fonction n'existe, j'ai déjà trouvé une solution un peu plus longue à mettre en place mais jouable quand même.

[Fax]

Hello.
La plupart de mes problèmes est résolu. 
Dans l'exemple sprite, il y avait cette ligne

Code:

  // init sprites engine
 SPR_init(16, 256, 256);

Qui initialise le sprite engine à maximum 16 sprites. D'où la plupart de mes soucis d'affichage. En modifiant la valeur je n'ai plus de soucis.

[Invité]

Bravo Fax pour la résolution de tes problèmes.

Concernant ta gestion de priorité d'affichage entre sprite, vu que SgdK ne possède pas encore de fonction pour traiter cela, je te conseille de consulter mon post traitant du sujet :
https://www.gamopat-forum.com/t93274-sgdk-megadrive-demo-d-une-gestion-de-yorder

Ce n'est pas la solution la plus rapide ( quoique ! ) et la plus parfaite, mais en tout cas, elle fonctionne !!
Avec un nombre de sprite pas trop important à traiter et une tempo de traitement pas trop réduite, tu pourras avoir un rendu convenable.

[bfg]

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 !

[Invité]

Si je ne me gourre pas, tu ne peux pas faire ça avec le Sprite Engine.
La vitesse sera toujours celle du .res et ce, même si tu tentes de le changer.
Quant à stopper une animation, pareil. Il faut passer par une frame fixe.

Par contre, en utilisant les routines "bas niveaux", tu peux TOUT te permettre.

[bfg]

Arg ...

 Donc tu ne peux pas faire une anim qui ne boucle pas, et savoir quand cette dernière est terminée je suppose  

[Invité]

Hélas non.
Il faut en fonction de la vitesse d'animation deduire le temps total d"une séquence complète. 
C'est ce que je fais pour Papi Tennis.

Sinon passer par les routines bas niveau assez faciles a utiliser et expliquées dans le wiki.
Bon courage copain.

[bfg]

Dernière question ...

J'ai un 

extern const SpriteDefinition sonic_sprite;

J'arrive à l'afficher, à l'animé etc etc ...

Mais JAMAIS, je n'ai fait une commande pour injecter les tiles des sprites explicitement en VRAM ...
Comment ça marche ?? Parce que si je comprenais ça, je pourrais ensuite utiliser mon propre spriteEngine et utiliser la compilation des .res au lieu de passer par un programme externe.


EDIT : Ok, ça à l'air d'être fait automatiquement quand on crée un sprite ... puissant, mais j'aime pas le manque de contrôle :) :)

[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).