Sydney Hunter and the Caverns of Death Megadrive - SGDK

Même dans un jeu à scrolling, le personnage principal n'est pas forcément au milieu, quand il se trouve aux extrémités du tableau.

Tryphon a écrit:Même dans un jeu à scrolling, le personnage principal n'est pas forcément au milieu, quand il se trouve aux extrémités du tableau.

Sauf si les sorties de ton tableau se trouvent en milieu d'écran et le reste sert juste de décor. (donc inaccessible)
Une alternative étant que le perso se déplace automatiquement du centre vers la sortie. (après avoir vainci un boss)

La window empiète sur la plan A, sa mise en œuvre me semble compliqué, et rassembler toute les informations en un seul bloc, ce n'est pas toujours très lisible pour le joueur(à mon humble avis).

http://gendev.spritesmind.net/forum/viewtopic.php?f=19&t=1983&sid=75c215404c61266c484769833de1cd72

http://gendev.spritesmind.net/forum/viewtopic.php?p=16147&highlight=#16147

Il y a des jeux qui n'utilisent pas la window, mais des sprites, cela donne plus de liberté, avec par exemple le score placé traditionnellement en haut de l'écran.

Non mais si tu regardes le format du jeu la window se prête parfaitement à ce format avec un tableau de bord en bas.
Après vu le nombre de sprites utilisés ça semble jouable de les utiliser en surimpression

Alors d'abord il faut trouver un jeu qui l'utilise, ensuite avec le debug de kmod 0_7_3 je ne vois même pas cette window dans le Plane Explorer. 

Y'en a plein, tiens quelques exemples parmi mes préférés Gaiares, castelvania, alisia dragon, contra ...

fanoplusplus64K a écrit:Y'en a plein,  tiens quelques  exemples parmi mes préférés Gaiares,  castelvania, alisia dragon, contra ...

Oui je viens de regarder, mais définitivement non pour moi, cette window masque les décors derrière elle... pas glop.

Suis pas fan mais dans le cadre de ce jeu ça serait adapté comme je disais plus haut

La window, ce n'est pas un problème. Elle s'oublie vite si le jeu est bon. (surtout à deux joueurs)
En plus de gagner des sprites pour le in-game, l'aspect 16/9 du playfield donne une impression d'espace.

Ce qui est déplorable, c'est que la window n'ait pas sa couleur 0 transparente pour faire ce que l'on veut.

La window peut être transparente(plan B ,sprites), mais bouffe qd même le plan A qui n'est plus visible .
Via interruptions, même problème, si vous voulez de la vraie transparence il faut utiliser des sprites .

Puis bon, sur SNES ils ont deux windows de chaque coté et ils ne peuvent rien mettre dedans. 

C'est vrai, mais tu peux faire des effets sympas facilement avec,comme avec la SGX .
La windows de la Md ,c'est plus pour éviter d'utiliser les interruptions pour faire la même chose.

Alekmaul>
Pour le halo utilise un plan bien sur, si tu en as un de dispo ça sera bien plus simple ainsi !
Pour le GUI en bas, vu le type du jeu, la window est parfaitement adaptée à ça !

Dans SGDK tu peux utiliser ces méthodes pour configurer la position de la window :

VDP_setWindowHPos(..)
VDP_setWindowVPos(..)

Ensuite tu as un tilemap juste pour la window... Par contre avoir une window en bas de l'écran, c'est un peu du gachi de VRAM car du coup tu dois avoir un tilemap 32x32 alloué juste pour la window :-/
Tu dois re paramétrer l'adresse de la tilemap dans SGDK car de base je ne lui alloues pas assez de VRAM pour ça je pense...

ok, merci des infos Stef, je vais regarder tout cela ...
Mais je pense que je vais laisser la window en bas, comme dans la version SNES.

La version coleco/MSx fait le halo de façon intéressante :

alekmaul a écrit:ok, merci des infos Stef, je vais regarder tout cela ...
Mais je pense que je vais laisser la window en bas, comme dans la version SNES.

Oui il vaut mieux respecter le jeu d'origine bien sur c'est juste que tu devras repositionner le tilemap de la window (voire réorganiser tout les tilemaps en VRAM pour optimiser celle-ci)
Tu peux utiliser les méthodes VDP_setWindowAddress(..), VDP_setAPlanAddress(..), VDP_setBPlanAddress(..), ... pour relocaliser les tilemaps/tables en VRAM.
L'aide affirme que le plan window doit être le premier en VRAM mais ce n'est plus vrai maintenant, par contre il faut toujours placer des maps et tables en haut de la VRAM car SGDK va automatiquement déterminer la VRAM dispo pour les tiles en fonction de l'adresse de la première map / table trouvée (et aussi charger la font juste en dessous).
En gros :
0x0000     ---->                  0xFFFF
TILE data - FONT - MAPS & TABLES

OK, merci de toutes ces infos, je vais tenter de l'appliquer :)
@touko, oui je connais cette version et c'est effectivement une alternative.

Mais sinon, avec VDP_setHorizontalScrollLine, je peux pas juste modifier le scrolling des X premières lignes et laisser le bas sans scrolling. Ce qui évite d'avoir à gérer une Window ?

Ah mon avis tu vas plus te compliquer la vie comme ça .

J'en suis pas certain, je tente ce soir :)

Oui c'est possible aussi, mais ça signifie que le tilemap de ton plan doit toujours contenir la status bar en bas. Et si la status bar est sur un multiple de 8 pixels alors tu peux même utiliser le scrolling par tile (pour éviter de remplir chaque ligne de la table)

Ça va être une technique sport pour les scrolling verticaux 

Haha c'est vrai y'a des scrolling verticaux dans le jeu... bon soit tu passes par l'hint pour reprogrammer le scroll vertical ou soit tu utilises la window qui est quand même fait pour ça :p

Je trouve que ça rend pas si mal avec la technique utilisée dans Mickey et ça prend pas trop de tiles :)

En effet ça rend plutot pas mal :) Il ne te reste plus qu'à le centrer sur le personnage.

---

Yep, sinon VDP_setVerticalScrollTile fonctionne comment, je comprends bien pour le horizontal, mais là, le premier tile, c'est quoi et la longueur aussi ?
Et le horizontal a pas l'air de fonctionner, il scroll tout l'écran ...
Voici le code, j'ai fait quoi de mal ?

Code:

// manage halo
 if (haloBG==1) {
 for (i=0;i<NUM_LINES_HALO;i++) {
 scrhalo[i]=i>23 ? 0 : -BG2XCENTER+sydneyix;
 }
 VDP_setHorizontalScrollTile(PLAN_A, 0, scrhalo, NUM_LINES_HALO, 1);
  }


avec comme déclaration :

Code:

#define BG2XCENTER 124
#define BG2YCENTER 100
#define NUM_LINES_HALO 28
s16 scrhalo[NUM_LINES_HALO];

Ca rend bien en effet, il faudrait juste à mon avis le réduire un peu.

Quel couillon, j'avais oublié l'init <_<
Donc, ça rend cela :

Ah ouais ça rend carrément pas mal :)

Ah ouai, c'est carrément classe là !
Par contre c'est voulu de voir les sprites malgré qu'ils soient supposés être dans le noir ??
Question de gameplay peut être ??

Même remarque que TOUKO... Les sprites devraient avoir une priorité inférieur.
Le halo étant suffisamment large pour ne pas affecter le gameplay.