Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Merci de ta réponse.
Pour le mode horizontal, j'avais bien compris comment faire. C'est le vertical qui me pose problème.
Qu'appelle tu "scrolling par 2 tiles" ?
Mon but est que le halo de lumière soit scrollé aussi bien en horizontal qu'en vertical quand Sydney saute.

[Stef]

C'est comme le scrolling par tile en horizontal sauf qu'il fonctionne en vertical et sur une granularité de 2 tiles plutot qu'un seul tile. Réellement tu n'utilises ce mode que dans des cas particuliers...
Pour ton jeu il me semble que tu as juste besoin des scrollings type plan classique (comme sur SNES).
Si je me plante pas le halo de lumière est dans un seul plan ? donc tu dois juste scroller le plan en vertical en mode "plan complet" (et donc utiliser la méthode VDP_setVerticalScroll simplement).

[Invité]

Si je me plante pas le halo de lumière est dans un seul plan ? donc tu dois juste scroller le plan en vertical en mode "plan complet" (et donc utiliser la méthode VDP_setVerticalScroll simplement).

Et non, car il y a les infos de status juste en bas, c'est pour cela qu'en horizontal j'utilise le scrolling par tiles en limitant à 23 tiles max en hauteur ...
Je dois laisser le satus sur la plan A car, dans certain cas, il y a des scrollings sur le plan B, je ne peux donc gérer le halo sur le plan B.
Donc, si il y a 2 tiles en scrolling vertical, je vais voir ce que je peux faire ce mode :)

[Stef]

Le plan A = halo et status, plan B = le reste ?
Si c'est le cas tu peux aussi utiliser la window pour y mettre le status ?

[Invité]

Le plan A = halo et status, plan B = le reste ?
Si c'est le cas tu peux aussi utiliser la window pour y mettre le status ?

Ouais, mais comme indiqué, on perd des tiles et tout ... bref, le bazard je pense non ?
Je vais essayer de dompter VDP_setVerticalScrollTile , sinon, bah, y'aura que l'horizontal

[Invité]

Au pire tu peux utiliser des sprites pour le hud(tu peux couvrir tout l écran),ces sprites auront la priorité la plus haute,au moins si y a clignotement il aura lieu derrière le hud, donc pas visible, en plus t auras même pas a le scroller.

[Templeton]

Au pire tu peux utiliser des spirites pour le hud(tu peux couvrir tout l écran),ces spirites auront la priorité la plus haute,au moins si y a clignotement il aura lieu derrière le hud, donc pas visible, en plus t auras même pas a le scroller.

C'est quoi des spirites ? Une marque de gâteau ?

[vincent2105]

[Invité]

Lol merci a la correction auto de mon tel ..

[Invité]

Coucou,
J'aurai une question :
Quand on a un/des sprites en priorité haute, peut avoir en même temps un plan Window qui soit en 1ere priorité?
Merci !

[fourchette]

Selon le wiki http://md.squee.co/VDP#Priority, le seul cas où un plan peut être devant des sprites en priorité haute, c'est quand le plan Window est en priorité haute, A et B resteront derrière.

[Invité]

Coucou, merci !
Justement, j'ai un sprite en priorité haute qui s'affiche par dessus ma Window.
Et comment definir la priorité de la Window ??
Moi je pensais le faire avec TILE_ATTR_FULL.
Merci !!

[fourchette]

C'est bien ce qu'il faut fairen mettre le bit de priorité des tiles de la Window à 1.

[Invité]

Okiiii !!
Mais malgré ça, ca passe toujours devant ... Bref, je vais bien finir par trouver !!!

[fourchette]

Le wiki est peut être erroné finalement. En lisant le documentation de Charles McDonald, je ne retrouve pas cette information. Il explique plutôt que la Window se comporte comme la plan A au niveau priorité.

https://emudocs.org/Genesis/Graphics/genvdp.txt

Code:

----------------------------------------------------------------------------
 14.) Priority
 ----------------------------------------------------------------------------

 The VDP manages a fairly complex system of priorities between the two
 background layers and sprites. The basic ordering is:


 (back)                                         (front)
        A  >  B  >  C  >  D  >  E' >  F' >  G'

 ' = Denotes high priority
 A = Backdrop color
 B = Low priority plane B
 C = Low priority plane A
 D = Low priority sprites
 E = High priority plane B
 F = High priority plane A
 G = High priority sprites

 The sprite priority bit does not affect inter-sprite priority, only the
 relation between background data. Low priority sprites *can* overlap high
 priority sprites. Games that do this to mask other sprites include
 Castlevania Bloodlines, Raiden Trad, and Alien Soldier.

Code:

Window
 ------

 The window plane operates differently from plane A or B. It can be thought
 of a 'replacement' for plane A which is used under certain conditions.
 That said, plane A cannot be displayed in any area where plane W is
 located, it is impossible for them to overlap.

 Registers 17 and 18 define an area which the window is restricted to.

 In terms of priority and intensity calculation for shadow / hilight mode,
 plane W is treated _exactly_ the same as plane A.

[Invité]

Ahah !!
Euh donc au final ??!!

[fourchette]

Bah au final, je penses avoir écrit une connerie en premier lieu. La documentation Genesis Technical Overview indique que Window et A se comporte de la même manière niveau priorité. J'aurais tendance à conclure que : non il n'est pas possible d'avoir un plan au dessus des sprites avec le bit de priorité à 1.

[Stef]

Si tu veux la window devant les sprites, il faut avoir la window en HIGH et les sprites en LOW.
Astuce de sioux (comme indiqué plus haut) : tu peux aussi utiliser un sprite en LOW devant un sprite en HIGH (car le priorité des sprites est gérée selon leur ordre dans la table de sprite). Dans ce cas le sprite LOW sera recouvert par la window uniquement là où le sprite LOW a des pixels non transparent (ça peut faire un joli effet de masking).

[Invité]

Coucou Stef !!
Merci pour ta réponse.
Pour ma part, c'est un peu particulier, car j'ai une partie du pont Plan A, les unités passent dessous ET une jeep passe dessus le pont et les autres sprites.
Du coup la jeep s'affiche aussi par dessus ma petite Window HUD.
Après ca peut faire classe aussi.

[Invité]

Et au fait Stef, il y a apparemment des problèmes d'affiche de sprite depuis tes Maj ( celle du Yorder )
Voir les derniers messages sur le jeu de plateforme de Kivutar.
Moi ca ne me gêne pas.

[Stef]

Je regarde tout ca dés que possible  Merci !

[JoanCZ]

Je me permet de squatter le sujet car je commence à programmer sur megadrive avec le SGDK (jusqu'à maintenant je m'amusais avec GBDK, sur Game Boy ) et je me retrouve face à un problème que je n'arrive pas a résoudre avec la partie sonore.
Voila le code :

Code:

#include <genesis.h>
#include "sound.h"

static void joyEvent(u16 joy, u16 changed, u16 state);

int main()
{
    SYS_disableInts();
    
    VDP_setScreenWidth320();
  
    XGM_startPlay(ma_music);
    
    SYS_enableInts();

    //???
    JOY_setEventHandler(joyEvent);
 
 while(TRUE)
    {
        VDP_drawText("TEST MUSIQUE", 10,10);
 VDP_waitVSync();
    }

    return 0;
}

static void joyEvent(u16 joy, u16 changed, u16 state)
{
    SND_startPlayPCM_XGM(64, 1, SOUND_PCM_CH2);
}


Tel quel, ça fonctionne nickel, mais si j’enlève la fonction 
JOY_setEventHandler(qui est une fonction dédiée a la détection des touches...),
ça plante.

quelqu'un pourrait m'en dire plus ? :)


Merci d'avance

[Stef]

Hello :) Est-ce que tu pourrais nous en dire plus ? Ca plante c'est à dire ??
La musique s'arrête ?
ussi faire un affichage de texte dans la boucle while c'est inutile (tu devrais juste y mettre le wait vsync)

[JoanCZ]

Bonjour Stef :)

Pour être plus précis, la musique ne demarre pas, et je n'ai qu'un écran noir :)

[Stef]

Ça c'est étrange en effet, je pense que tu te tapes un pas de bol que les timings d'init et l'écriture du VDP, pour être totalement safe il faudrait que tu protèges ton écriture VDP (le draw texte) avec un disableInts / enableInts. Essai pour voir si ça change quelque chose, sinon je regarderai chez moi !

[Invité]

Coucou,

De retour chez moi, j'ai voulu régler un problème que j'avais depuis l'installation de SgdK avec ce message dans les Logs : 
java n'est pas reconnu en tant que commande interne ou un fichier de commande 
Cependant, cela n'empêchait pas la compilation de se faire.

Du coup, j'ai modifié mes variables d'environnement Windows PATH pour bien configurer Java.
Sur CMD avec Java -version, j'ai bien la dernière version affichée, super !

Avec SgdK configuré avec Code::block, plus ce message non plus ! Super (bis)
Par contre, la compilation dure .. beaucoup plus longtemps :
Process terminated with status 0 (4 minute(s), 42 second(s))


Alors qu'avant, tout se  compilait en moins de 30 secondes ... 


Est ce normal ?? Merci !! :)

[philip]

Ce n'est pas normal, tu va vite perdre patience à mon humble avis, 5 minutes la compilation, c'est un retour aux 70s.

Peut-être as tu mélangé la configuration de deux langages sur un même ide ?

[Tryphon]

Est-ce que quand tu relances la compilation c'est toujours aussi lent ?

[Invité]

Merci pour vos reponses.
En fait, ce qui est lent, ce sont toutes les compressions a faire (gfx surtout ... )
Ca va compresser puis après, ça s'arrête et ca reprend, etc ...
Une fois que c'est fait, la compilation du code est ultra rapide !
C'est juste la compression qui pose problème ... Steffffff !!???

[Tryphon]

Mais ça recompresse à chaque compilation, ou uniquement quand tu modifies les ressources ?

[Invité]

Une fois les ressources modifiées, en général je modifie TRES souvent mes ressources ! Donc, faut être patient ...