Discussion :

[Kannagi]

Voila j'ai donc décidé de présenté un peu mon projet , un peu en avance j'aurais préférer avoir mon 'moteur' plus complet avant de faire une présentation, et puis je me suis dit que je ferai un post sur une de mes console favorite la Super Nintendo !
Alors le but de mon projet et de faire un A-rpg a la secret of mana , je vois pas ce projet tout a fait impossible niveau prog (aucun souci niveau algo) mais demande beaucoup de temps et de motivation.
La démo peut vous sembler courte mais il y a eu derrière quelque mois de travail.

Pour la présentation de la console voila ce que dit Wikipédia :

Processeur : 16 bits 65C816 cadencé à 3,58, 2,68, ou 1,79 MHz (réglable)
RAM de travail : 128 Kio
PPU (Picture Processing Unit) 16 bits
RAM vidéo : 64 Kio pour les plans de décor et les sprites

Nombre de couleurs : jusqu'à 256 selon le mode graphique, choisies parmi 32768 (15bit RGB5)
Définition : de 256 × 224 à 512 × 448 pixels selon le mode graphique, et le scan entrelacé ou progressif
jusqu'à 4 plans de scrolling selon le mode graphique
Nombre de sprites : 128 (32 par ligne de balayage maximum, ainsi qu'une largeur cumulée de 35x8 = 280 pixels par ligne), taille de 8 × 8 à 64 × 64 pixels
Effets câblés : scrollings toutes directions, zoom et rotation d'arrière plan (mode 7), plans multiples ; gestion des sprites, compression de tiles, déformation graphique…
Modes graphiques : 8 modes de 0 à 7

Dans la pratique c'est du 2.68 mhz , ( on peut le cadencé niveau programmation a 3.58 mais il se remet par défaut sous certaine condition).
Pour la Ram de travail dans la pratique le programmeur n'a que 8 ko disponible pour le jeu(de adresse $0000 a $2000) le reste est réservé pour la supernes (les registre se trouve en mémoire par exemple).
On a après 64 ko pour les sprites.
Le background et les objet(sprite genre perso ect) sont gérer un peu différemment , pour le background on possède 8 mode (perso je n'utilise que le mode 1 et 7), les tiles peuvent être de 8x8 ou 16x16 pour le BG , chaque tile et configurable (flip ,choix de la palette , priorité ,choix du tileset).
Pour les sprites on ne peut en mettre que 128 maximun , (et un certain nombre par ligne) , les tileset peuvent varié entre 8x8 a 64x64.
Pour la palette 8 pour le BG et 8 pour les sprites.

Le processeur de la SNES mon avis ?
C'est un assembleur assez simple un peu trop simple a mon gout des qu'on veut faire quelque chose d'un poil plus complexe on écrit rapidement pas mal de code , après c'est plus un hybride 8/16 bits , dans le sens ou c'est le programmeur qui choisit de le mettre en 16 bit ou 8 bits , après il n'y qu'un registre qui peut faire les opération (accumulateur) ce qui oblige chaque fois de passer sur ce registre pour faire des opération quelconque.
Bien sur pas de division ou multiplication sur ce processeur disponible.

Niveau puissance étrangement même si il y a écrit 2.68mgz ce qui signifie 2 680 000 cycle par seconde , la SNES ne me laisse pour affichage (quand le NMI est activé) ,que 18000 cycle par frame (qui fait donc 900 000 cycle par seconde),c'est très (très) peu , le reste doit servir pour affichage, d’ailleurs on soit impossible que le jeu ralentisse si vous n'avez pas le temps pour faire les calculs la SNES passera a l'affichage direct , il y a le Vblank (parti du code pendant que la SNES fait affichage qui dure 0.2 ms) , ce qui doit être utile de pouvoir mettre un peu de code dessus.

Alors après avoir appris un peu plus assembleur et compris la bête (parce que faut dire que c'est pas courant comme architecture) , j'ai pu coder une démo.
Le scrolling , j'ai galéré , coder plusieurs fois parce que trop long , la j'ai optimiser comme un bourrin pas de boucle tout hardcoder ,et je pense que il faudra faire comme ça sur chaque point critique , j'ai passé aussi un temps non négligeable sur les outils (éditeur de mode 7 et de map) , de même pour le convertisseur png ->image snes y'a probablement des outils qui traine sur le net pour ça mais sur windows ce qui n'est pas mon cas.
Les collision sont un peu trop harcoder a mon gout vu que je dois penser a faire les collision avec les perso aussi , faudra que je rend le code plus modulable sur ce point (légèrement pour être utilisable sur les perso).

La démo possède donc un perso qui marche, un pnj , un début de menu (avec rotation L ou R) , scrolling / collision , texte et ensuite start / select pour passer du mode normal en mode 7 (pas fini).
La démo qui en plein mode debug est dispo ici : http://www.mediafire.com/download/9t...62fb6/main.smc

Une Vidéo :

Ensuite ben plein de chose , disons que j'en suis en mode réflexion y 'a des contrainte a ne pas ignoré , la première j'ai fait une erreur d'avoir fait du 32x32 par tiles pour les sprites , vu que pour le menu (qui sont des sprites) , ça prend trop de place , en chiffre une texture de 128x32 ne prend que 4 icone en 32x32 et si c'est du 16x16 j'en ai 16 icone ce qui est largement suffisant.
Pour les Sprite même si on a 64 ko on ne peut sélectionner que 16ko de sprite , ce qui en gros représente 2 texture de 128x128 , du coup faudra que je réfléchisse a comment je les sépare pour ma part je le voyais comme ceci (diviser en 128x32) :
1) hero
2) hero 2
3) ennemi/pnj
4) ennemi/pnj
5) ennemi/pnj
6) ennemi/pnj
7) menu
8) autre

Ce qui me fait une palette pour chaqu'un ^^
Ensuite faudra que je réfléchisse sur comment je gère la priorité affichage faire des if sur chaque perso affichable pourquoi pas (y en a pas plus que 7 grosso modo et de 3 pour les monstre dans secret of mana) , mais faudra que je décide pour OAM (Object Address Memory qui ne peut prendre que 128 sprite je rappelle) , et la priorité sur les sprites ce fait par rapport a cette adresse , ça peut sembler inutile , mais je venais de remarque que pour le menu il doit être dessiné par dessus du coup faudra que je décide quel adresse correspond a quoi (ce qui est sur c'est que les premiers sera le menu) bref pour dire qu'on doit presque tout prévoir et je préfère éviter les surprisse a un stade avancé dans mon code.

Le BG pour le moment , j'ai une texture pour le texte/fenêtre (de 128x32) et le reste pour la map , pour le moment j'ai fait en sorte de mettre 24ko pour la map ( 3 texture de 128x128) ce qui me semble suffisant.
Et j'ai 7 palettes pour la map (donc 112 couleurs).
Pour le moment je n 'utilise qu'un seul BG pour la map , disons que j'ai encore un doute niveau performance pour mettre le deuxième, quand j'implémenterai le reste ,s'il me reste encore du temps cpu je le ferai.

Il faut que je recode certain petit point , et puis finir au moins la démo (collision perso et menu) , pour un combat j'ai pas d'idée j'ai plus apprécié le gameplay d'un terranigma plus vif que Secret of mana qui sait un mélange des 2 serait plus cool de mon point de vue ^^

Voila , donc je vous rassure j'écris tout ceci sur un fichier texte qui me sert de mémo, bref je cartographie mon architecture et je me base la dessus.
Sur ce projet je pense que je rechercherai un codeur assembleur pour m’épaulai,a deux le travail serait plus faisable , par contre ça doit pas courir a chaque coin de rue je regarderai du coté de la communauté anglophone.
Je suis conscient que le post est plus orienté technique j’espère que cela vous intéressera quand même , et merci d'avoir lu un tel pavé .

[Cirrus Minor]

Wahoo !
C'est un travail de malade, ça ! Bravo
Je ne ferai jamais de ma vie un jeu console rétro, mais je suivrai ton boulot, je trouve ça très intéressant.

pour le background on possède 8 mode (perso je n'utilise que le mode 1 et 7)

Ce sont quoi, les modes de background ?

[Kannagi]

Ah ben c'est cool , surtout si tu trouve cela interessant , je mettrais mes avancement (d'un point de technique toujours).

Pour ta question j'aurais tu laisser la suite de la description sur wikipédia (que je trouve plutôt bien expliqué).

Mode 0: 4 plans, chacun utilisant 8 palettes de 3 couleurs plus une transparente. Les palettes sont indépendantes pour chaque plan.
Mode 1: 3 plans, deux utilisant 8 palettes de 15 couleurs plus une transparente, le dernier utilisant 8 palettes de 3 couleurs plus une transparente. Les palettes sont partagées par les plans.
Mode 2: 2 plans, utilisant tous les deux 8 palettes de 15 couleurs plus une transparente. Le défilement peut être changé tous les 8 pixels horizontaux.
Mode 3: 2 plans, l'un utilisant toute la palette de 256, l'autre utilisant 8 palettes de 15 couleurs plus une transparente. le plan de 256 couleurs peut également spécifier directement les couleurs depuis un espace de 11 bits (RGB443).
Mode 4: 2 plans, l'un utilisant toute la palette de 256, l'autre utilisant 8 palettes de 3 couleurs plus une transparente. Le plan de 256 couleurs peut utiliser l'espace RGB443, et le défilement peut être changé pour les deux plans tous les 8 pixels horizontaux.
Mode 5: 2 plans, l'un utilisant 8 palettes de 15 couleurs plus une transparente, l'autre utilisant 8 palettes de 3 couleurs plus une transparente. Ce mode permet résolution réelle de 512 pixels horizontaux.
Mode 6: 1 plan, utilisant 8 palettes de 16 couleurs. Ce mode permet également une résolution réelle de 512 pixels horizontaux, et le défilement peut être changé tous les 8 pixels horizontaux.
Une image de test démontrant les capacités du Mode 7 de la SNES
Mode 7: 1 plan de 128×128 tuiles (1024x1024 pixels) depuis une banque de 256. Celles-ci peuvent être interprétés comme un plan de 256 couleurs, ou 2 plans liés de 128 couleurs (les sprites pourront être placées devant, entre ou derrière ces deux plans). Le/les plans peuvent effectuer rotations et zoom simultanément. La HDMA (copie de mémoire pendant la synchronisation horizontale) est souvent utilisée pour changer les paramètres de la matrice de transformation et obtenir des effets de perspective sur un plan horizontal (en augmentant le zoom à chaque ligne)

Pour le mode 1 ,j'utilise donc 1 plan et je réfléchi pour le 2eme (a cause des soucis de perf sur le scrolling faut voir si le reste n'est pas trop gourmant) et le plan 3 me sert pour le texte/fenêtre.
Le mode 7 , permet de faire des zoom/rotation plutôt pratique pour faire une worldmap .

Si vous avez d'autre question n'hésitez surtout pas.

[MoDDiB]

Sympa ! Si tu as de petits exemples de code n'hésites pas !

[Vetea]

Excellent boulot !!
Je connais quelques personnes développant sur des consoles rétro ( PC engine, Megadrive, Coleco, etc .. ) mais trouver un codeur assembleur bon courage !
Moi ça me fait penser que je vais bientôt m'y mettre mais sur une autre console, la Megadrive pour porter le projet au 61 pages ( ... )
Très bonne initiative en tout cas et merci du partage !

[Kannagi]

@ MoDDiB
J'ai pas de petit exemple de code en particulier et si je commence a l'expliquer je pense que j'en ferais un tuto ^^, mais on tout cas si le projet d'une section retro voit le jour il est évident qu'il y aura des ressources de ma part ( un hello world pour la snes ect).
Je peux filer le main.asm si certain veulent voir a quoi ça ressemble (je rassure pour faire un truc plus basic on a beaucoup moins de ligne).

@Vetea
Merci , je note (ça serait plus agréable de coder avec un frenchi ).
Bon courage pour la megadrive si tu fait ton jeu en assembleur tu peux compter sur moi pour te filer un coup de main le 68000 je l'ai étudié (mais plus pour coder sur la NEO GEO).

[Vetea]

Merci c'est très sympa de ta part !

[Hors Sujet]
La Megadrive a un Hardware un peu bizarre aussi car elle possède 2 CPU dédié ( un 68000 et un Z80 pour la musique et sons ) donc, 2 assembleurs à apprivoiser ...
Soit autant d'OPCode à apprendre, des allocations mémoires à respecter, etc ...
De toute manière, je compte utiliser un "Basic - Assembleur" pour le développement ( le BasicEgaXorz ), et oui encore du "Basic" !
Je connais des personnes qui ont développé de très bon jeu avec cette techno ( F.L, Bonaf, etc ... ) pour la Megadrive et le résultat est bluffant.
Tout comme toi, il faudra refondre mes sprites pour limiter les couleurs avec les palettes disponibles et surtout, la taille des Tiles.
[/Hors Sujet]

Par contre, petite question technique :
Est ce que tu gères le Z-Ordering car ça doit un peu couter en cycle ... ?
Merci pour le code source !

... et surtout bon courage !!

[Nico65]

Bien sur pas de division ou multiplication sur ce processeur disponible

ça parait fou et pourtant... il me semble que certains CPU genre ARM/Cortex n'ont toujours pas de FPU et font tourner Android
en tout cas félicitations, ça a l'air amusant
j'avoue que perso j'aurais pas la patience vu les limitations, mais il me semble que le dernier jeu Mégadrive/MégaCD (Pier Solar machin truc) est assez récent, comme quoi

[Kannagi]

@Vetea
Cela dépend , pour le moment pas vraiment (mais tu as pu remarquer qu'il y a par exemple le toit des murs qui sont devant le perso), la SNES permet que chaque tuile a un ordre de priorité (pour ça que j'ai fait mon propre éditeur en partie) et cela consomme rien du tout en terme de CPU.
Non dans le sens entre perso/pnj il n'y a pas encore cela , je pense le coder mais ça couterais un peu en CPU mais si je me base sur ce qui est affiché ça serra rapide je pense.
J’espère avoir répondu correctement a la question .

Sinon La Super Nes possède elle aussi un deuxième processeur le SPC700 pour le son que je devrais regardé.

@Nico65
Ah tu m'apprend un truc , oui j'ai entendu parler de Pier Solar ,c'est sur qu'il faudrait connaitre la machine (en tant que joueur) pour avoir un attrait a coder la dessus par contre je trouve toujours Secret of Mana et autre A-RPG de ce style sympa a jouer (et mieux que pas mal de jeux récent =X ).

[Vetea]

Réponse très claire ! Merci !!

Pour ton éditeur, tu utilises des "balises" comprenant le N° de TILE, leur coordonnées ( et éventuellement leur type ) et après tu les intègres en ASM ?
Pour ma part, j'utilise ce genre de "balisage" ( N° Tile, Coordonnées X - Y ) pour la version PC; mais sur ces consoles rétros, il est vrai que l'on a un nombre limité de RAM ... ( et de VRAM aussi ! )
C'est fou quand on y pense avec nos machines à paquet de Go de RAM et de paquet de GhZ on perd parfois la quintessence de ces jeux vidéos de jadis, comme de véritables "oeuvres" à part entière.

D'ici quelques mois, on sera deux ( et peut être plus qui sait ... ? ) à diffuser des projets sur Consoles Rétros et je trouve que c'est une bonne chose pour DvP et pourquoi pas, un forum dédié pour ce type de développement ( en tout cas moi j'avais voté pour ! )

A bientôt !

[Kannagi]

Pour mon éditeur j'utilise en gros une lecture directement lisible par la snes , grosso modo (tiens je vais prendre le conseil de moddib un petit code exemple).
Mais il y a une zone (qu'on peut choisir l'adresse) qui contient les donné de chaque tiles , la Doc officiel (oui on peut la trouver sur le net) est assez clair sur 2 octet il faut mettre ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
d15 d14 d13 d12 d11 d10 d9 d8 d7 d6 d5 d4 d3 d2 d1 d0
X   Y   Pri  2   1  0                NAME
Flip         color

Voila donc en a le flip X et Y (et ça sert pour économiser des tileset ) , le Priorité du tile, le color c'est la palette et pour ce qui connaisse bien leur leçon sur 3 bit y 'a 8 valeur différente ( de 0 a 7 ) donc 8 palette sectionnable et le NAME (sur 10 bit) c'est grosso modo le tileset (0 le premier 1 le second ainsi de suite).

Mon Éditeur fourni ce genre de code pour un assembleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    .dw $1106,$1104,$1106,$1104,$1102,$1104,$110a,$110c,$112a,$0802,$0802,$0802,$0802,$0802,$0802,$0802
    .dw $0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$080e,$0802,$0802,$0802,$0802,$0802,$0802
    .dw $0802,$0802,$0802,$0802,$0802,$0802,$0802,$1146,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802
    .dw $0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802,$0802

Donc le premier par exemple c'est la palette 4 et le tileset 0x106.

Sur la SNES ça donnerai ceci si on veut l’écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
lda #$6800 ;cette valeur est complétement arbitraire c'est le programmeur qui décide ou sont stocké les tileset , cette instruction met dans l'accumulateur la valeur en hexa 6800
sta VMADDL ; envoie la valeur de accumulateur ($6800) dans adresse de VMADD (c'est un registre pour la SNES qui se trouve a adresse $2116).
 
lda #$1106 ; met la valeur en hexa 1106 dans accumulateur
sta VMDATAL ;envoie dans la VMDATAL donc on gros on il va dessiner le tileset qu'on vient de mettre.
 
;ainsi de suite
lda #$1104
sta VMDATAL
 
;ce code marche seulement si lda est en 16bits

Et donc en a les tileset , j'ai fait exprès de écrire en dur pour bien que vous puisez comprendre , sinon il y a les label et une instruction pour lire ou se trouve ce label et l'incrémenté (je que je fais) , mais comme pas tout le monde connais assembleur j'ai réduit au minimum.

ah , ben disons que en a la pack complet assembleur + contrainte matériel qui dit mieux ?
J’espère que cette section naitra et qu'on sera plus que 2

[MoDDiB]

mais on tout cas si le projet d'une section retro voit le jour il est évident qu'il y aura des ressources de ma part ( un hello world pour la snes ect).

Je ne vois pas pourquoi il faut absolument une section spécifiquement retro : un tutoriel de développement SNES aurait totalement sa place dans la rubrique jeux vidéo classique

[jean_kevin_musclor]

OMG

JE ME PROSTERNE DEVANT KANNAGI

c'est un français mutant avec un gros cerveau de japonais

[Kannagi]

@Moddib tu as raison , mais c'est plus pour ce qui liront ce genre de tuto et qui auront des questions , il y'aura pas vraiment endroit pour répondre a ce genre de réponse , et puis surtout que le mieux serait une section ou il y aurait de entraide (mais c'est mon avis).
Mais pour le tuto c'est clair que j'en ferais un section ou pas ^^

@jean_kevin_musclor
Ah ah , le secret en faite... c'est juste du travail et de la passion

[jean_kevin_musclor]

ce compliment m'aura coûté cher

j'ai mangé une infraction pour l'avoir écrit en caractères trop gros...

[Kannagi]

J'apprécie le compliment
Mais je voulais dire , que je pense que tout le monde peut le faire mais cela demande un investissement personnel que chaqu'un décide de consacré ou pas.

Je pourrais pas avancé le code trop cette semaine , mais normalement la semaine prochain y'aura quelque nouvelle maj sur la démo.

[LittleWhite]

Bonjour,

Joli travail, vraiment joli.
Les consoles américaines étaient en 60 FPS ? Du coup, il y avait encore moins de cycle pour les trucs autre que l'image ?
Quelle est la contrainte la plus forte ? La mémoire ou le CPU (nombre de cycles) ?

C'est bien d'avoir fait un post technique

[Nico65]

j'ai lu un truc comme ça sur un forum Megadrive, en 50Hz tu as plus de temps par cycle. Sauf que les développeurs doivent faire un jeu vendu beaucoup en 60Hz (Japon et US) et un peu en 50Hz (Europe), donc souvent juste ralentis d'autant sans profiter du gain en 50Hz. Sauf quelques-uns comme Sonic 3 qui est mieux en PAL qu'en NTSC

[Kannagi]

@LittleWhite
Excellente question ,je croyais l'avoir testé mais enfaite non alors mauvaise nouvelle pour moi , j'ai beaucoup moins de cycle en 60 fps la moitié pour être exact
Je crois que je vais me pencher a activé le CPU en 3.68 mgz sinon ça risque d’être chaud niveau code.
Sinon oui les version US et JAP sont en 60 fps , c'est nous européen qui somme en 50 fps.
Niveau contrainte celle qui m’embête le plus c'est clairement le CPU , en plus niveau optimisation c'est souvent au dépend de l'autre , quand on veut optimiser les calcul en les precalcul donc on consommera plus de mémoire et inversement si on veut économisé de la mémoire on ferra que le cpu le calculera , sauf que sur Super Nes le CPU il est a la ramasse j'ai envie dire XD.

D'ailleurs ça me demande a me poser une autre question l'exactitude de émulateur , il y a 3 principaux émulateur Super Nes , Snes9x , ZSNES et bsnes.
J'utilise Snes9x pas parce que j'ai mon préfère (quand je joue sur émulateur je préfère ZSNES) , juste que SNES9X est très rapide (surtout au démarrage il est instantané) ,ZSNES est beaucoup plus lourd donc un peu moins agréable pour développer.
Pour bsnes il est considéré comme le meilleur émulateur de la Super Nes ,émulant au cycle pré , donc ça sera lui qui déterminera si j'ai effectivement la moitié ,bon comme je suis sur Linux et que j'ai jamais réussi a le faire marcher sur linux je test bsnes que très rarement , faudra que je test tout de même pour confirmé le nombre de cycle que j'ai par frame.

@Nico65
tu as raison , je crois que je vais suivre ce conseil est privilégié la version NTSC.

[LittleWhite]

Hum, pour les émulateurs SNES, je ne sais pas du tout. Je m'y connais un peu plus en Atari ST (sans trop de détails) et je sais qu'il arrive de voir des démo Atari ST qui ne passe que sur la machine physique et jamais sur les émulateurs. Souvent, c'est que le demoscener utilise une spécificité électronique de la puce, qui est ultra border case sur la spécification (limite pas prévu).
L'émulateur Wii a un récent soucis de précision des float et du timing du lecteur CD pour l'émulation exacte de la console, ce qui est assez délirant (voir les dev report de dolphin).
J'espère que c'est mieux pour la SNES.
Je vous conseillerai, mais il ne dev que sous Windows, l'émulateur : http://problemkaputt.de/sns.htm . Le développeur cherche à offrir généralement la meilleure émulation avec les meilleurs options de débogage, ce qui peux devenir très pratique. Ça tourne bien (enfin l'émulateur GBA) sur Wine, car le gars, il est un peu extrème est code ultra bien/optimisé et strict.

Une technique aussi, mais dont vous ne semblait pas avoir besoin, c'est d'afficher/colorier une partie de l'écran (ou dessiner une ligne) suivant le nombre de cycle vous restant. Pas sur que ce soit efficacement réalisable sur la SNES.
La ligne se situe à un endroit de l'écran, dépendant de combien de cycle il reste de libre dans la frame. Au final, ça fait une sorte de visualiseur d'utilisation CPU dynamique.