Hardcore Retrogaming

[pippoletsu]

Jeu dispo sur Steam aussi je crois et article dans l'avant dernier Pix'n'Love.

[upsilandre]

C'est quand meme en mode bourrin  :vice:
a l'epoque quand tu faisais un decor tu pensais tout en "tile", c'est a dire que tu construit des elements graphiques qui peuvent se répéter pour réutiliser tes tiles un max de fois. Mais la pour un level ils se font un background unique, une image enorme de la taille de 400 ecrans et donc sans contrainte de tile comme a l'epoque, ca simplifie le boulot et la programmation mais du coup ca fait 100 000 tiles juste pour un level
D'ou la cartouche de 1609Mb. D'ailleurs j'ai pas bien compris pourquoi ils disent que c'est la limite maximum (sous entendu sans bank switching) alors que pour attendre ce chiffre faut deja utiliser une forme de bank switching (sans cela la limite c'est 1025Mb de tileset et 256Mb de sample audio et 8Mb de programme) et dans ce cas la y a plus de limite.

Cela dit ils ont raison d'avoir cette approche qui peut sembler bourrin si on se replonge 20 ans en arriere mais a partir du moment ou t'as plus les meme contrainte d'espace tu fais forcement les choses differement, c'est un jeu Neogeo de 2014 pas de 1994.

[upsilandre]

Les cartouches de jeu NeoGeo sont assez uniques et du coup les ROM d'emulation aussi avec tous ces fichiers.
Chaque fichier correspond a une ROM sur la cartouche, ca permet de rappeler a quelle point une cartouche NeoGeo est chargé en ROM aux fonctions differentes (je parle meme pas de quantité) et du coup ca donne des informations assez direct sur le jeu.

Sur des cartouches SNES ou Megadrive en général t'as une seul ROM a destination du CPU de la console.
Sur une cartouche NeoGeo y a plein de ROM differentes (et meme 2 PCB au lieu d'une seul) chacune destiné a un processeur different. Dans le fichier ROM pour l'emulation chaque fichier a un nom qui respect en général un standard, ouvrez en un ,je vais vous revelez le grand mystere sur ces fichiers  :vice:

--- Les fichiers c1,c2,c3,c4... ce sont les ROM reliés au GPU et qui contiennent les tiles 16x16 utilisés par les sprites (et donc aussi par le decor). C'est le tileset principale et c'est evidement le plus gros morceau de la cartouche, les plus gros jeux officiels en ont jusqu'a 64Mo au total (50% du max). Ca ne fonctionne que par pair car le GPU en utilise 2 en meme temps (pour avoir un flux 32bit) donc c'est minimum c1 et c2.
--- Les fichiers v1,v2,v3... ce sont les ROM reliés au sound chip Yamaha qui contiennent tous les samples audio du jeu en ADPCM. C'est l'autre gros morceau de la cartouche, en général c'est l'equivalent d'un quart du tilset soit 16Mo dans les plus gros jeux (50% du max). ici le nombre de ROM peut etre impair.
--- Les fichiers p1,p2... ce sont les ROM relié au CPU principale de la console, le 68000, c'est la qu'est le programme, c'est le coeur du jeu. Normalement limité a 1Mo les plus gros jeux en utilisent jusqu'a 8Mo  (800% du max) grace au bank switching
--- Le fichier s1 c'est une autre ROM relié au GPU mais sur un bus different. Celle ci contient les tiles 8x8 déstinés a l'ecran fixe qu'on peut ajouter par dessus le jeu principalement pour le HUD. C'est un tout petit tileset (comparé au tileset des sprites) qui fait toujours 128Ko (256Ko avec une bidouille de bank switching) et qui contient principalement des polices de caractere.
--- Le fichier m1 c'est la ROM relié au second CPU de la console, le vieux Z80 qui sert a piloter le sound chip Yamaha. Cette ROM contient le driver audio et des partitions. en général le fichier fait tout le temps 128Ko mais en vrai y a seulement 64Ko d'utilisable qui est le max adressable par le Z80. Certaine cartouche dépasse un peu cette limite avec du bank switching.


Voila vous savez tout sur ces obscures fichiers, quand meme un sacré bordel une cartouche NeoGeo.
A cela on peut aussi ajouter une expliquation sur les ROM qui sont dans la console et qu'on est aussi obligé d'ajouter quand on fait de l'emulation. La aussi la NeoGeo a ses petites particularités car y a pas juste la ROM du Bios, y a aussi 2 autres ROM dans la console nommé "sfix" et "lo" dans les fichiers d'emulation.
"sfix" est simplement l'equivalent du s1 des cartouches, c'est a dire un petit tileset de 128Ko qui contient principalement des polices de caracteres (japonaises et latines) pour l'ecran fixe (HUD) que le jeu peut utiliser en remplacement de celui de la cartouche.
"lo" est une ROM de 64Ko qui contient une table de valeur précalculé destiné a la fonction de shrinking (rétrécissement) des sprites, je reviendrais peut etre sur cette fonction (d'ailleurs je suis en train de me dire que ca pourrait etre marrant de modifier les valeurs de ce fichier)

[upsilandre]

Y a tres peu de difference entre les cartouches NeoGeo AES (console) et MVS (arcade).
La seul difference c'est que l'un des composant qui en Arcade se trouve normalement sur la carte mère est déplacé dans la cartouche car c'est une sorte de multiplexeur qui transforme le flux 32bit qui sort des ROM c (les sprites qui est le flux principale de la cartouche) et qui contient les 4 bitplan d'une ligne de 8 pixels, transformé en un flux plus rapide mais structuré en double pixel 4bpp (soit 8bit) du cout dans la cartouche console c'est ce flux 8bit qui sort de la cartouche alors que dans la cartouche arcade c'est le flux natif 32bit qui sort et qui est multiplexé plus tard sur la carte mère.

Du coup sur la cartouche console y a une économie de pins et c'est ce qui permet aux cartouches consoles d'avoir se format de PCB plus compact de 50 pins au lieu de 60 pins pour l'arcade.

[upsilandre]

Le GPU de la NeoGeo est composé de plusieurs petits composants qui semble assez rudimentaire, tout est fait de facon a faire circuler le flux rapidement pour avoir de la force brute mais ca semble tres basique (et ingenieux a la fois)

D'ailleurs je me suis arreté sur la fonction "shrinking" des sprites qui permet de les rétrecir en sautant des lignes qui semble a priori une fonction basique mais malgres ca elle n'est meme pas vraiment cablé en hard, cette fonction est obligé de faire appel a une table externe de valeurs précalculées. une ROM de 64Ko dans la console qui contient en fait 256 fois 256 valeurs.

Cette table est utilisé pour le shrinking vertical qui peut prendre 256 nuances differentes (le shrinking horizontal lui est vraiment cablé de facon logic dans le GPU car il n'a que 16 valeurs differente, je rappel les sprites sont au format 16x512 donc des bandes vertical avant tout)
Du coup la table contient 256 valeurs pour chacune des configuration du shrinking vertical, ces 256 valeurs indiquent pour chaque ligne d'affichage du sprite quelle ligne réel de la pattern du sprite il faut afficher (et donc lesquelles sauter, la table est utilisé 2 fois pour obtenir les 512 lignes si nécessaire). C'est vraiment basique et bourrin mais efficace.

Les choses a savoir c'est que meme lorsque tu rétrecis le sprite, le rétrecissement est juste visuel mais concretement le sprite garde toujours sa taille maximum du point de vue du GPU (donc sa taille zoomé), l'espace du sprite est juste comblé par de la transparence donc faut en tenir compte pour ce qui est des limites d'affichage par scanline, ca reste de gros sprites meme une fois rétrecis.

Et puis faut ajuster les coordonnés des sprites apres le shrinking, notamment pour le shrinking horizontal y a pas mal de boulot a faire a la main si tu veux un rétrecissement fluide et propre car ton perso est un assemblage horizontal de plusieurs sprites dont il va falloir déterminer la repartition du shrinking (a l'aide d'une table probablement a moins de se limiter a un shrinking en 16 etapes qui doit suffir dans la plupart des cas) et ajuster les coordonnées de chaques sprites a chaque fois pour que les sprites reste assemblés.

Donc quand meme pas mal de contrainte sur le shrinking mais ca marche bien quand meme, il est d'ailleurs tout le temps activé (mais dans sa valeur max par defaut), il fait partie intégrante du pipeline graphique.

Du coup je me suis amusé a modifier la ROM qui contient la table de shrinking (d'ailleurs en l'ouvrant on comprend tres vite les valeurs qu'elle contient), et ca marche, ca permet de glitcher tous les jeux facilement car cette table est utilisé pour tout ce qui est affiché a l'ecran.

Je me suis amusé a faire une version de cette ROM qui force le shrinking vertical a 50% donc tous les sprites sont affiché en version compressé (50% de leur taille) et dans un jeu comme Metal Slug 3 qui est un assemblage de plein de petits sprites independants et non lié ca donne un sacré bordel de glitch.
Je me suis aussi fait une version de cette ROM qui empeche tout shrinking vertical. Sur Art of fighting par exemple les combatants (et le decor) deviennent tout mince quand ils s'eloignent l'un de l'autre car ils ne subissent qu'un shrinkink horizontal.
voila c'est rigolo

[JiHaisse]

Merci pour tes posts, je vais les lire ce soir pour me bercer. True story.

[Coca_Impact]

Le ray-casting marche sur TI83+ et plutôt bien   
C'est quand même plus digeste en vrai !

[upsilandre]

Y a pas de raison d'autant que ce genre de machine j'imagine que c'est un affichage bitmap, pour les rendering software c'est toujours mieux qu'un affichage par tile.
La pire de toutes les machines pour les rendering software (3D, raycasting, sprites software...) c'est la NeoGeo qui non seulement passe par un tileset mais un tileset inalterable car uniquement en ROM.

[upsilandre]

Je jetais un oeil sur la Gameboy... Niveau sprite elle avait quand meme un taux d'affichage de 50% par scanline contre 25% pour la NES et Master System, du coup moins de chance a priori d'avoir du clignotement de sprite dans les jeux Gameboy.

Alors c'est sur que la resolution horizontal plus faible (160 comme les jeux C64 ou Intellivision au lieu de 256) aide a obtenir ce taux d'affichage elevé mais meme en faisant abstraction de la resolution la Gameboy peut afficher quand meme 80 pixels sprite par ligne contre 64 pour la NES/MS donc ca reste au dessus meme dans l'absolu.

[Hobes]

En parlant de Game Boy, y aura peut-être un jeu inconnu et/ou intéressant dans le lot de cette vidéo avec toutes les intros GB :

[upsilandre]

3h de "start bouton" j'aime bien le concept lol

aujourd'hui sur Youtube t'as vraiment de super catalogue. Entre les longplay de chaque jeu, les video catalogue de tous les jeux d'une machine, de toutes les musiques, de toutes les jaquettes de boites, les comparatif de jeu sur toutes les machines ect...
le patrimoine est deja bien archivé et c'est que le debut mais c'est vrai que youtube c'est une invention bien pratique quand meme.

[Yo Riso]

Personne n'a connu l'AMIGA 500 ?

[upsilandre]

une chouette photo que j'avais jamais vu.
Le premier prototype de la Famicom.


A gauche le CPU et ses customisations (Audio, I/O) et a droite le GPU.


J'avais jamais vu aussi comment etait cablé les pad a l'interieur d'une famicom et ca va c'est bien safe, on peut tirer dessus comme on veut ca risque rien.



N'hesitez pas a transporter votre Famicom sur le dos en tenant les 2 cables des pads, ca risque rien.

[pippoletsu]

J'avoue [emoji14]tdr:

[upsilandre]

Cette photo du proto illustre tres bien un fait que je trouve frappant.
La Famicom qui est la premiere console de Nintendo (non je ne considère pas les pong chip comme des consoles) sort le meme jour que la premiere console de Sega (SG1000). On a deja la tout une symbolique quand meme.
Et c'est aussi la confrontation de 2 approches tres differente. D'un coté on a la vieille entreprise Nintendo qui pourtant sur ce projet va représenter plutot le Japon moderne a la pointe de la technologie, qui innove et fait de la R&D, et en face on a Sega une entreprise a priori plus moderne mais qui la dessus va représenté plutot le Japon du passé, le japon qui se contente d'etre une usine et qui copie les produit occidentaux.
Ici Sega se contente en gros de faire une contrefacon de la Colecovision. Ils ont ouvert une colecovision, pris la référence de tous les composants et commander les memes, jusqu'a reprendre plus ou moins le type de controlleur (pour ensuite s'inspirer de celui de la Famicom).
Comme a l'epoque les consoles occidentales n'existait quasiment pas sur le marché Japonais Sega a joué les opportunistes en se disant que les gens n'y verrait que du feu et qu'il y aurait peut etre moyen de refourguer quelques conversion d'arcade (l'Arcade etant le veritable marché du jeu video au Japon a cette epoque).
Aucun effort d'innovation, de R&D, d'integration. Mais du coup la SG1000 coutait certainement plus chere a produire que la Famicom et pour sortir ca au meilleur de sa forme:



(d'ailleurs c'est a cause de cette étron que les versions MarkIII/SMS jap ont du etre rennomé Super Wonderboy? vu que la version SG1000 tourne aussi sur ces machines. Et a jouer c'est encore plus horrible qu'a regarder)


Dès le depart ca démarre mal pour Sega et quand tu te foire a l'allumage c'est pas bon signe. Je me dis peut etre que peut tout etait ecrit dès le premier jour.