Re: Topic de discussion autour de la Mega Drive

[Invité]

Euh... c'est normal que Grafx2 plante au moment de sauvegarder, après avoir passé 2 heures à bosser sur un sprite ?  

[Invité]

http://fr.openclassrooms.com/informatique/cours/apprenez-a-programmer-en-c

 

Je ne pense pas que ce tutorial s'applique pour les jeux rétro utilisant les outils de programmation pour la Mega Drive.

D'où le  pour indiquer cynisme du post .. car je n'y connais rien en dev  

[Invité]

Bah en fait, dès qu'il y a des termes techniques dans les explications, je ne comprends plus rien.  
D'ailleurs, je pense que la création d'un topic du genre "La programmation pour les nuls" serait très pratique, avec l'explication de chaque terme technique. Une sorte de lexique, quoi.

C'est pas faux du tout ça, et c'est une très bonne idée ..

Euh... c'est normal que Grafx2 plante au moment de sauvegarder, après avoir passé 2 heures à bosser sur un sprite ? 

Euh non, j'ai jamais eu ce genre de problème ...

[maxoojc]

Hey,

Désolé d'avoir déserter ce topic mais depuis jeudi, on etait en organisation du week end pour les startup donc pas trop eu le temps de me balader ici.

@stef: Merci c'est gentil d'être aussi accessible et crois mois je suis un gros fan du taff fait sur les émus, je sais ce que c'est j'en avais fait un pour la neogeo pocket B&W donc merci pour ta disponibilité, du coup je n'hésiterai pas à te solliciter.

@touko: Merci pour toutes ces précisions et conseils, promis je toucherai à la pc engine aussi après :p
De toute façon c'est une console que je trouve techniquement géniale, et je remercies hudson d'avoir voulu aller plus loin ! Et puis je la connais un peu j'avais commencé une interface pour faire un ému ya très longtemps de ça avant de découvrir magicEngine à l'époque :)

[pypen]

Megadrive powaaaa....
voila :)

[Invité]

@touko: Merci pour toutes ces précisions et conseils, promis je toucherai à la pc engine aussi après :p
De toute façon c'est une console que je trouve techniquement géniale, et je remercies hudson d'avoir voulu aller plus loin ! Et puis je la connais un peu j'avais commencé une interface pour faire un ému ya très longtemps de ça avant de découvrir magicEngine à l'époque :)

De rien, et puis un projet homebrew, peut importe la machine, c'est toujours bon a voir émerger . 

[maxoojc]

@pypen: Exactement, tu résumes toutes mes pensées :)

Bon j'accorde aussi beaucoup d'attention aux extensions de cette merveille mais on va pas chippoter !

@touko: C'est sur mais pour le moment c'est pas forcement au stade de projet, j'ai déjà envie de voir de quoi est réellement capable la MD, pour le moment, je suis au hard à fond et je t'avoues que je ne suis pas déçu, on retrouve tout pour faire un champion entre une sorte de DMA et des proc dédiés, c'est plutôt bien concu, je comprends un peu mieux leur volonté et la possibilité d'ajouter autant d'extensions...

Tu vois le top serait de voir le projet PEA l'éditeur multi langage du gars du forum et de gerer un outil générique genre tu fais tes sprites et tout sans penser à la machine, et le truc te converti tout, après t'as juste à retravailler si ya des imperfections, enfin c'est un rêve :)

[Invité]

Stef et TOUKO --> lors de la création d'un décor/zone tenant sur plusieurs écrans, comment procéder ? Faut-il dessiner chaque écran avant de les coller bout-à-bout ? Ou bien peut-on créer l'ensemble d'une seule traite comme si c'était une feuille de papier géante et, ensuite, le programmeur détermine la partie visible à l'écran en fonction des déplacement du joueur ?

[maxoojc]

Le tiling est la methode la plus simple, en gros tu as une matrice qui représente tout ton niveau mais c'est mis sous forme informatique, et chaque case représentent un carré d'une taille spécifique, qui varie en fonction des capacités de la machine.

Voila à quoi ça peut ressemble en mémoire, pour toi en tant que graphiste il faut respecter les différents éléments et après on peut tout découper pour fabriquer cette matrice.

Exemple on dispose de 2 blocs, 1 et 2 de 32 pixel de côté et voici la matrice, pour l'image finale, il faut remplacer chaque case par les blocs adéquat et l'image finale fera 32 * 5 x 32 * 5

[
1 1 1 1 1
1 0 0 0 1
1 0 0 0 1
1 0 0 0 1
2 2 2 2 2
]

Par contre on ne peut pas faire une grosse image sans la découpée et le nombre de bloc sera défini par la taille mémoire des supports sur lesquels ça va.

Seulement pour faire simple, le graphiste peut faire une grande image mais en respectant les contraintes de la matrice que le dev puisse découper facilement en éléments viables.

Après c'est le programme qui n'affiche que les blocs visibles.

[Invité]

Faudrait peut être faire un topic spécial création Megadrive non ?

[Paradis]

Faudrait peut être faire un topic spécial création Megadrive non ?

C'est vraiment passionnant de voir un tel projet prendre forme.
Je n'y entend rien en développements de jeu, mais quel plaisir de lire des fous/passionnés en passe de façonner en partant de zero un jeu, pour la machine que j'affectionne le plus  

Et effectivement un topic dédiée vous aiderez sans doute, et les admirateurs de suivre votre aventure plus facilement.

[maxoojc]

Pour l'instant ça reste autour de la megadrive, c'est ni des projets ni de la programmation encore mais c'est prévu :)

[Invité]

Le tiling est la methode la plus simple, en gros tu as une matrice qui représente tout ton niveau mais c'est mis sous forme informatique, et chaque case représentent un carré d'une taille spécifique, qui varie en fonction des capacités de la machine.

Voila à quoi ça peut ressemble en mémoire, pour toi en tant que graphiste il faut respecter les différents éléments et après on peut tout découper pour fabriquer cette matrice.

Exemple on dispose de 2 blocs, 1 et 2 de 32 pixel de côté et voici la matrice, pour l'image finale, il faut remplacer chaque case par les blocs adéquat et l'image finale fera 32 * 5 x 32 * 5

[
1 1 1 1 1
1 0 0 0 1
1 0 0 0 1
1 0 0 0 1
2 2 2 2 2
]

Par contre on ne peut pas faire une grosse image sans la découpée et le nombre de bloc sera défini par la taille mémoire des supports sur lesquels ça va.

Seulement pour faire simple, le graphiste peut faire une grande image mais en respectant les contraintes de la matrice que le dev puisse découper facilement en éléments viables.

Après c'est le programme qui n'affiche que les blocs visibles.

Bordel, j'ai rein compris. Il va vraiment falloir que je créé le topic "Programmation MD pour les Nuls".  

[maxoojc]

Tiens j'ai trouvé quelques exemples

Les tiles qui sont les blocs:
http://www.ladyada.net/images/fuzebox/SMB-Tiles.gif

Le décors une fois assemblé:
http://www.ladyada.net/images/fuzebox/NES_Super_Mario_Bros.png

Un image qui illustre assez le principe:
http://flashgamedojo.com/wiki/images/a/aa/2DTiles_Flashback.png

Donc il faut un logiciel qui te permette de selectionner les tiles et de les placés pour former le décors.
Comme je disais c'est possible de faire le niveau genre avec photoshop mais il faut respecter ce meme principe de case, du coup c'est peut être vachement contraignant :/

EDIT: Je mettrais en image ce soir je ne sais pas pourquoi l'editeur de texte à encore sauté je n'ai plus de mise en forme....

[Invité]

Stef et TOUKO --> lors de la création d'un décor/zone tenant sur plusieurs écrans, comment procéder ? Faut-il dessiner chaque écran avant de les coller bout-à-bout ? Ou bien peut-on créer l'ensemble d'une seule traite comme si c'était une feuille de papier géante et, ensuite, le programmeur détermine la partie visible à l'écran en fonction des déplacement du joueur ?

Alors évidemment tu peux créer une map (écran si tu préfères) largement plus grand que les 256/320 pixels de ta résolution .
Donc si je me trompe pas, sur Md tu dois pouvoir paramétrer un écran virtuel, explications:
Lorsqu'un écran scrolle l'écran virtuel indique que le proc vidéo arrive à la fin de cet écran qu'il doit repartir sur le début de l'écran, donc si on a un écran virtuel de 256 pixels de large (avec résolution de 256 aussi), et qu'on scrolle d'1 pixel vers la gauche la ligne de pixels qui à disparue de la gauche, apparait directement à droite, on appelle ça le wrapping .
C'est comme si ton écran était un cylindre, il boucle sur lui même, l'écran virtuel défini juste la taille du cylindre .

c'est souvent utilisé dans les shoots qui font reboucler une map de 256 pixels lors d'un scroll horizontal, ça évite de se faire chier .
Ensuite pour dans le cas d'une map plus grande que 256 pixels, on paramètre un écran virtuel au dessus des 256 pixel, sur MD il me semble que comme la PCE c'est 512 pixels .
Donc dés que tu utilises la résolution de 320 pixels de la MD (ce qui sera surement le cas), il faudra un écran virtuel de 512 pixels .
Donc dans ce cas si on scrolle l'écran d'1 pixel sur la gauche la ligne n'apparaitra ni à 256, ni à 320 mais à 511 ..

Bon déjà dis moi si je suis un peu clair lol, stef pourra corriger si je fais des erreurs sur le fonctionnement de la Md .

Ozoran, toi en tant que graphiste, tu n'auras pas à te poser la question de savoir comment sont organisées les tiles/sprites en mémoire, c'est le codeur qui s'en charge.
C'est sur qu'en maitrisant les caractéristiques de la machine, tu pourras organiser tes grafs en fonction, et simplifier la tache du codeur .

[maxoojc]

LoL je crois que tu vas le perdre.

Par contre dans ce genre de méthode, c'est surtout niveau perf que j'aimerai bien voir, mettre un fond qui comme tu dis sur les shoot reboucle et à la limite c'est pas trop visible, mais si tu as plusieurs plan ou si t'as besoin de diversité, faire des écran virtuel de plus en plus gros est peut être très gourmand, faudra tester la vitesse du dma.

[Invité]

Pas de soucis pour ça, tu raffraichis pas un écran complet, mais au max 1 colones de tiles 8*8 tout les scrolls de 8 pixels .
Bien sur tu verras qu'il est possible d'optimiser ça facilement .
Ce raffraichissement a lieu en dehors de l'écran (dans l'overscan), donc non visible pour le joueur.

Et chaque plan a son propre EV,enfin je pense que c'est comme ça sur MD .

[maxoojc]

Ouep ça je comprends mais je n'ai pas encore regarder comment fonctionne la mémoire video

En fait ton écran visible qui se balade sur ton virtuel, il est copié je pense par le dma mais quelle vitesse etc, sur amiga on s'amusait à passer ca dans la vblank, donc on avait une horloge de synchro pour les cas de ralentissements.
A voir certains jeux je pense que sur la MD quand le dma rate une vblank, ca bloque jusqu'a la frame suivante, ya certain jeux qui deviennent bizarres en cas de ralentissements.

Et un des trucs mis en avant avec la md c'etait les paralax mais sont ils fait en mémoire avec multi ecran virtuels ou en soft avant de placer le décors auquel cas le plan le plus en avant risque de faire tout rafraichir derrière quand ton avant plan est assez gros :/

Je vais m'y mettre vite fait histoire de faire mes tests car c'est chiant d'en parler et d'ne avoir envie

[Invité]

En fait ton écran visible qui se balade sur ton virtuel, il est copié je pense par le dma mais quelle vitesse etc, sur amiga on s'amusait à passer ca dans la vblank, donc on avait une horloge de synchro pour les cas de ralentissements.
A voir certains jeux je pense que sur la MD quand le dma rate une vblank, ca bloque jusqu'a la frame suivante, ya certain jeux qui deviennent bizarres en cas de ralentissements.

alors tout d'abord tu as ce qu'on appelle une BAT (Background attribute Table) qui est proportionnelle à la taille de ton écran virtuel, donc plus l'EV est grand plus la BAT serra grande .
La BAT contient les infos sur chaque tiles a afficher,et elle commence à l'adresse $0000 de la vram (sur pce c'est comme ça, sur Md surement aussi).
chaque tile est définie dans la BAT par un mot de 16 bit qui contient sur MD(a confirmer par stef) :
L'adresse de la tile en VRAM (codée sur 10 bits) .
2 bit pour les priorités
2 bit pour le flip H/V 
et 2 bit pour la palette à affecter à la tile (donc 4 palettes possibles).
Donc une résolution de 320x224 pixel contient 40x28 tiles donc une BAT de 560 mots(1120 octets).

Donc tu peux évidemment remplir ton écran virtuel de 512 pixels (ou plus) de toutes les tiles, mais ça va te prendre de la VRAM inutilement ..

Donc tu ne raffraichis pas l'écran, mais la BAT.
Cependant si tu modifies une tile en VRAM (les données graphiques de la tile), tu vas modifier également cette tile partout sur l'écran .

Sur Md ils appellent les EV, des scroll playfields, avec comme params possibles pour chaque plans:
32*32,    32*64,    32*128,
64*32,    64*64,    128*32


En tiles bien sur .

Sur Md, d'après stef, on peut transférer environ 7.5 ko/frame max .

Et un des trucs mis en avant avec la md c'etait les paralax mais sont ils fait en mémoire avec multi ecran virtuels ou en soft avant de placer le décors auquel cas le plan le plus en avant risque de faire tout rafraichir derrière quand ton avant plan est assez gros :/

Chaque plan à mon avis a sa propre bat, et tu choisis de faire scroller individuellement le plan complet ou les lignes du plan que tu souhaites.
Les params de scroll sont comme une sorte de copper list, il sont en VRAM sur MD .


Tu peux trouver de la doc technique ici : http://gendev.spritesmind.net/page-doc.html

[Stef]

alors tout d'abord tu as ce qu'on appelle une BAT (Background attribute Table) qui est proportionnelle à la taille de ton écran virtuel, donc plus l'EV est grand plus la BAT serra grande .
La BAT contient les infos sur chaque tiles a afficher,et elle commence à l'adresse $0000 de la vram (sur pce c'est comme ça, sur Md surement aussi).
chaque tile est définie dans la BAT par un mot de 16 bit qui contient sur MD(a confirmer par stef) :
L'adresse de la tile en VRAM (codée sur 10 bits) .
2 bit pour les priorités
2 bit pour le flip H/V 
et 2 bit pour la palette à affecter à la tile (donc 4 palettes possibles).
Donc une résolution de 320x224 pixel contient 40x28 tiles donc une BAT de 560 mots(1120 octets).

Donc tu peux évidemment remplir ton écran virtuel de 512 pixels (ou plus) de toutes les tiles, mais ça va te prendre de la VRAM inutilement ..

Donc tu ne raffraichis pas l'écran, mais la BAT.
Cependant si tu modifies une tile en VRAM (les données graphiques de la tile), tu vas modifier également cette tile partout sur l'écran .

Sur Md ils appellent les EV, des scroll playfields, avec comme params possibles pour chaque plans:
32*32,    32*64,    32*128,
64*32,    64*64,    128*32


En tiles bien sur .

Sur Md, d'après stef, on peut transférer environ 7.5 ko/frame max .

Et un des trucs mis en avant avec la md c'etait les paralax mais sont ils fait en mémoire avec multi ecran virtuels ou en soft avant de placer le décors auquel cas le plan le plus en avant risque de faire tout rafraichir derrière quand ton avant plan est assez gros :/

Chaque plan à mon avis a sa propre bat, et tu choisis de faire scroller individuellement le plan complet ou les lignes du plan que tu souhaites.
Les params de scroll sont comme une sorte de copper list, il sont en VRAM sur MD .


Tu peux trouver de la doc technique ici : http://gendev.spritesmind.net/page-doc.html

Bravo Touko c'est du tout bon
Sur MD on appelle pas ça BAT mais juste tilemap car comme il y a 2 plans ça pourrait préter à confusion. En gros on considère comme background la couleur de fond et ensuite tu as les 2 plans A et B dont une partie de A peut être fixée (window) et ensuite les sprites.

Et pour le tilemap:
- 1 bit priorité
- 2 bit H/V flip
- 2 bit pour la palette
- 11 bits pour l'index du tile (soit 2048 possible max)

Tu as 64 ko de VRAM sur MD, avec ça tu dois faire tenir les tiles de 8x8 pixels et les tilemaps pour les 2 plans, les infos des sprites et les tables de H scroll.
L'avantage c'est que tout est paramétrable, tu peux mettre tes tilemaps ou tu veux en VRAM, tu peux même mettre les plans A et B sur la même adresse si ça te chante (intérêt limité mais pour gagner un peu de VRAM si nécessaire).

Mais une chose est sûre, il est primordial de bien cerner le fonctionnement de l'affichage sur ces vieille machines avant de vouloir se lancer dans le dev sinon c'est la gamelle assurée.
Sinon pour faire les maps sur MD (ou autres consoles dans le même genre) y'a un soft pas mal :
http://www.mapeditor.org/

[maxoojc]

Roo super merci à vous 2 !
Je comprends bien mieux et t'as raison stef c'est pour ça que j'analyse vraiment le fonctionnement graphique.

D'ailleurs j'avais omis le proc sonore la derniere fois que j'ai voulu faire ça et trop chiant pour metter des sons du coup j'avais abandonné, donc là je vais après me metre au Z80 et au bgm histoire de tout comprendre !

J'ai trouvé ce site ya plein de doc c'est classe :) http://emu-docs.org/?page=Genesis

[Invité]

Merde, j avais pas tout bon sur les bit du tilemap .. 
Sur pce le tilemap est le fichier en rom qui contient toute la map .

Et stef a raison, d ailleurs pour le moment tu devrais oublier le proc sonore,et te concentrer sur le VDP.

[philip]

VDP pour la MD.
il y a deux écrans virtuels de 512x384. Pour les images des scrollA et B (bmp 16 couleurs 3bits), c' est plutôt 16x16 par soucis d' économie (car vram limité à 64ko).

[Invité]

Donc, si je comprends bien, je peux dessiner une ville entière sur Grafx2 (en gardant en tête que la partie qu'on verra à l'écran avec la Mega Drive sera de 320x244) et ensuite le programmeur fera des petits carrés avec, comme du découpage ?

[Invité]

Donc, si je comprends bien, je peux dessiner une ville entière sur Grafx2 (en gardant en tête que la partie qu'on verra à l'écran avec la Mega Drive sera de 320x244) et ensuite le programmeur fera des petits carrés avec, comme du découpage ?

Tout à fait, toi tu fais juste une image bmp ou autre, et le programmeur ferra le reste .
Par contre si tu prévois 2 plans de scroll, faut faire 2 images,une par plan .

Avec l'habitude, tu sauras comment organiser ton travail plus rapidement et efficacement .

@philip:C'est vrai sur Md c'est le VDP ..

[Stef]

Donc, si je comprends bien, je peux dessiner une ville entière sur Grafx2 (en gardant en tête que la partie qu'on verra à l'écran avec la Mega Drive sera de 320x244) et ensuite le programmeur fera des petits carrés avec, comme du découpage ?

Oui mais il faut que tu gardes en tete comment le fonctionnement du processeur vidéo de la machine car si jamais tu mets trop de détail (en gros que ton image génère trop de tiles différents) ça ne rentrera plus en mémoire vidéo et posera des problèmes pour le développeurs. Pour ça tu as des outils très pratique qui te permettent de construire facilement des images "adaptées". Actuellement je suis en train d'intégrer des outils dans SGDK pour prendre une grosse image en entrée (genre un PNG) et la transformer automatiquement en tiles et tilemap afin de l'afficher facilement (en appelant juste VDP_drawImage(..) par exemple). Pour autant ton image doit respecter des contraintes, comme pas plus de 16 couleurs par tiles, pas plus de 4 palettes utilisées dans l'image etc...
Pour ça encore une fois je te recommande d'utiliser MapEditor (ou Tiled c'est le meme soft) dont j'ai posté le lien plus haut pour construire les cartes. En gros tu dois lui fournir une image en entrée qui contient les différents tiles et ensuite tu utilises ces tiles comme des pinceaux :)

[Invité]

Le truc c'est de commencer par un truc simple histoire de vous familiariser avec les contraintes, et pas partir sur un truc compliqué d'entrée de jeu .

CAD un fond en 16 couleurs (donc 1 seule palette) sans scroll, avec quelques sprites à l'écran .

[Dagnirendae]

Waip, commencez par un Pong Megadrive, MegaPong !

[JBec]

Waip, commencez par un Pong Megadrive, MegaPong !

Nan il a dit qu'il faisait GTA V sur Megadrive.

[Invité]

Merci TOUKO et Stéf.  

J'ai deux autre questions pour vous :
- j'ai lu deux résolutions différentes sur Wikipédia (320x224 et 320x448), comment cela est-il possible ?
- j'y ai également lu que la machine peut lire 80 sprites d'une résolution maximale de 32x32. Cela signifie-t-il que si l'on veut créer un personnage qui dépasse ses limites, celui-ci devra être composé de plusieurs sprites (par exemple le buste fera un sprite et les jambes un autre sprite) ?

[philip]

256x224 --> 60 sprites
320x224 --> 80 sprites

Tu peux mobiliser par exemple 4 sprites de 32x32 pxl comme Mr Nutz, donc un total de 64x64 pxl.