Re: Le x68000 et la supériorité japonaise

[TotOOntHeMooN]

Oui mais bon moi j'ai plus le temps de jouer la

Oui, je sais bien !

C'est bon on a apprit assez de truc la. J'ai plus vraiment de question sur la partie graphique si ce n'est tout ce qui concerne les mode vidéo et les pixels aspect ratio mais j'ai pas trop envie de m'y intéressé car j'ai l'impression que je trouverais pas forcement les réponses sans avoir de X68000 sous la main. J'aurais voulu avoir les différents dot-clock pour mieux me rendre compte.

Je me souviens qu'en 384, c'est inclus dans un écran de 512... Après le tour du sujet a effectivement été fait et on est bien d'accord que c'est un micro-ordinateur avec un circuit qui sert à afficher des sprites.

[TotOOntHeMooN]

Sinon : https://www.youtube.com/watch?v=qmu1QLFwWyM

[upsilandre]

Il y a un truc quand même qui est vraiment cool et qu'on a pas assez dit je trouve c'est d'avoir un vrai scrolling hardware sur tous les layers. Alors oui y a pas vraiment de tile mapping (ou inexploitable sur Cynthia) ou de fonction DMA pour aider les mise a jour des background mais avoir un vrai scrolling hardware (façon console, on indique les coordonnées X,Y du début de l'écran et la machine va automatiquement calculer l'adresse VRAM correspondante et faire warper la VRAM au limite de l'écran) et sur autant de layer ca reste quand même rare pour un micro et ca aide beaucoup quand même pour faire du jeu vidéo.

Le X68000 est peut être pas autant "arcade" ou "console" dans son ADN que je ne le pensais au départ mais qu'on ne s'y trompe pas, les features graphiques proposées reste exceptionnelles pour un micro. Tous ces layers, toutes ces couleurs, tous ces scrolling hardware, tous ces sprites hardware. On est quand même dans quelques choses de hors norme pour un micro au point justement de donner l'illusion d'une machine d'arcade, c'est pas rien.
C'était ma petite conclusion.

[dlfrsilver]

Il y a un truc quand même qui est vraiment cool et qu'on a pas assez dit je trouve c'est d'avoir un vrai scrolling hardware sur tous les layers. Alors oui y a pas vraiment de tile mapping (ou inexploitable sur Cynthia) ou de fonction DMA pour aider les mise a jour des background mais avoir un vrai scrolling hardware (façon console, on indique les coordonnées X,Y du début de l'écran et la machine va automatiquement calculer l'adresse VRAM correspondante et faire warper la VRAM au limite de l'écran) et sur autant de layer ca reste quand même rare pour un micro et ca aide beaucoup quand même pour faire du jeu vidéo.

Le X68000 est peut être pas autant "arcade" ou "console" dans son ADN que je ne le pensais au départ mais qu'on ne s'y trompe pas, les features graphiques proposées reste exceptionnelles pour un micro. Tous ces layers, toutes ces couleurs, tous ces scrolling hardware, tous ces sprites hardware. On est quand même dans quelques choses de hors norme pour un micro au point justement de donner l'illusion d'une machine d'arcade, c'est pas rien.
C'était ma petite conclusion.

Un bouzin à 400.000 yens quand même. 

Est-ce que j'abuserais si je te demandais de regarder Super Street Fighter 2 ? C'est du CPS2, beaucoup plus exigeant qu'une conversion CPS1 style Final Fight ou encore Daimakaimura. 

Tu peux regarder ? Après je t'embête plus :) Merci !

[upsilandre]

Je ne crois pas qu'il y ai beaucoup de différence entre CPS1 et CPS2. C'est surtout la quantité de tile indexable et de ROM adressable qui change. Donc c'est plutot une question de quantité de donné pour le X68000 (Disquettes, RAM)

SF2 en lui meme me parait un défi clairement plus simple a porter sur nos machines que Final Fight par exemple. D'ailleurs ca semble reprendre un peu le meme schéma avec les tileset background stocké directement dans les VRAM. Par contre le HUD de SF2 est géré en sprite (la ou dans Final Fight c'est le Text layer qui sert de HUD car le jeu ne peut pas se permettre de gacher des sprites) et du coup le Texte layer est parfois utilisé comme 3ème plan de background.
La difficulté c'est juste la quantité de donnée, faire rentrer ca dans un minimum de disquette, éviter d'avoir trop de loading, faire tenir au moins le set complet d'animation de 2 personnages dans la RAM.

Sinon dans Final Fight j'ai remarqué que parfois la charge de sprite dépasse les capacités de Cynthia, et je parle pas d'overflow par scanline (la ca passe plutôt bien) mais un overflow des sprites parce que le jeu a parfois besoin d'afficher plus de 128 sprites. Le problème ici c'est pas tant la quantité de sprite que la taille fixe de 16x16 qui est trop petite.
Cynthia a beau pouvoir afficher plus de sprite par scanline (ce qui est bien utile), la surface que peut couvrir Cynthia avec ses sprites est inferieur a ce que peuvent couvrir les consoles 16bit (mais qui ne sera pas forcement exploité non plus sur console 16bit a cause des contrainte d'overflow par scanline 2x plus forte que sur Cynthia).

[dlfrsilver]

Je ne crois pas qu'il y ai beaucoup de différence entre CPS1 et CPS2. C'est surtout la quantité de tile indexable et de ROM adressable qui change. Donc c'est plutot une question de quantité de donné pour le X68000 (Disquettes, RAM)

SF2 en lui meme me parait un défi clairement plus simple a porter sur nos machines que Final Fight par exemple. D'ailleurs ca semble reprendre un peu le meme schéma avec les tileset background stocké directement dans les VRAM. Par contre le HUD de SF2 est géré en sprite (la ou dans Final Fight c'est le Text layer qui sert de HUD car le jeu ne peut pas se permettre de gacher des sprites) et du coup le Texte layer est parfois utilisé comme 3ème plan de background.
La difficulté c'est juste la quantité de donnée, faire rentrer ca dans un minimum de disquette, éviter d'avoir trop de loading, faire tenir au moins le set complet d'animation de 2 personnages dans la RAM.

Sinon dans Final Fight j'ai remarqué que parfois la charge de sprite dépasse les capacités de Cynthia, et je parle pas d'overflow par scanline (la ca passe plutôt bien) mais un overflow des sprites parce que le jeu a parfois besoin d'afficher plus de 128 sprites. Le problème ici c'est pas tant la quantité de sprite que la taille fixe de 16x16 qui est trop petite.
Cynthia a beau pouvoir afficher plus de sprite par scanline (ce qui est bien utile), la surface que peut couvrir Cynthia avec ses sprites est inferieur a ce que peuvent couvrir les consoles 16bit (mais qui ne sera pas forcement exploité non plus sur console 16bit a cause des contrainte d'overflow par scanline 2x plus forte que sur Cynthia).

Sache qu'un patch non diffusé publiquement restaure le fonction du code de l'arcade (le programme X68000 étant un réassemblage du code source de FF 900613 JAP CPS1) pour la mise à l'écran des ennemis. 
Shaun Thompson m'a dit que ce patch permet d'avoir exactement le même nombre d'ennemis que sur arcade. Pour ça, il faudrait que celui qui l'a fait le diffuse publiquement.

Je sais aussi que les japonais se sont fait des adaptations de jeux d'arcade à titre personnel. Par exemple, on sait que Thunder dragon 2 a un port strictement X68030, non disponible publiquement. 

On espère que Beep sortira des ports des jeux CPS1, plus simplement grâce à la RAM qu'on a maintenant sur les machines. Voir d'autres jeux tirés de machines d'arcade.

[upsilandre]

Tu peux afficher autant d'ennemis qu'en arcade puisque sur X68000 c'est du sprite software, il y a donc pas de limite théorique, par contre au lieu d'avoir le jeu qui tourne a 40-60fps il va peut être tourner a 20-30fps donc 2 a 3 fois plus lentement qu'en arcade. C'est pas forcement mieux (cela dit ils auraient pu se fixer sur un framerate de 30fps plutôt que de viser les 60fps, ca aurait été un compromis raisonnable)

Mais de toute façon la plus grosse différence se trouve plutot sur la représentation graphique du sol (et la aussi on voit bien les contraintes de taille de sprite de Cynthia. La version X68000 se limite a 24 objets graphiques au sol car le LOD 0 et 1 nécessite chacun 9 sprites. Un seul buisson = 9 sprites).

On a d'un coté un jeu d'arcade avec une image qui est construite a base de sprite hardware + scaling et rotation hardware et de l'autre une image construite a base de sprite software injecté dans un bitmap sans scaling ni rotation (tout précalculé).
Les 2 sont radicalement différent, même la résolution est différente (320 en arcade vs 256 sur X68000)

[msx33]

J'ai intercepté et mesurer les routines de mise a jour du scrolling dans Daimakaimura X68000 et qu'elle enfer. C'est comme on pouvait l'imaginer. Le fait de pas pouvoir utiliser les background de Cynthia a cause du manque de VRAM est un gros gâchis de ressource.

Comme prévu le stockage entrelacé des Graphic layer ca implique d'accéder individuellement aux pixels. Sur un X68000 de base rien que la mise a jour du background pour le scrolling vertical sur un seul plan ca prend 45% des ressources CPU de la frame (33% pour le scrolling horizontal d'un seul plan), pour un truc qui sur les BG de Cynthia prendrait aucune ressource ( en tout cas moins de 1%). Ca n'utilise même pas le DMA qui n'a même pas l'air bien calibré pour ca, juste des séries de dizaines voir centaines de Move selon le cas (y a quand meme le MoveM et MoveP du 68000 qui sont bien calibré pour le besoin de ces Graphic layers, heureusement. Pour le tileset de Cynthia ca utilise de simple Move.L plus classique)

Voila a quoi ressemble la subroutine de mise a jour d'une seule tile de background (un truc qui prendrait juste un seul Move 16bit pour maj une tile d'un BG de Cynthia)
https://i.postimg.cc/7w5mLz93/X68000-Move-Tile16x16-Subroutine.png
Sans oublier qu'il faut aussi mettre a jour dynamiquement le set de sprite de Cynthia vu le peu de VRAM qu'il y a.

Mais ca prend pas seulement des ressources. Ca oblige aussi a stocker les tuiles au format 8bpp alors qu'elles sont 4bpp a l'origine donc les tuiles graphiques du background occupe 2 fois plus de place en RAM que sur CPS (alors qu'avec les BG Cynthia les graphisme occuperait pas plus de place que sur CPS).

Ce manque de VRAM sur Cynthia rend la machine bancale. C'est assez décevant au final en terme de cohérence hardware. Faudrait enlever le Text layer et ses 512Ko et que ce soit Cynthia qui ait 512Ko   .
Ca c'est mon point de vu de consoleux. Mais si on fait le deuil des BG de Cynthia alors on peut voir le X68000 comme un chouette micro (mais avec donc du scrolling "micro") auquel on a ajouté des sprites hardware ce qui est toujours sympathique.

Mais en dehors des adaptations arcades qui ont fait le mythe de la machine (mais qu'on préfère jouer sur Mame aujourd'hui) et de Akumajou, les autres jeux sont souvent d'un daubitude incroyable. Vous avez déjà essayé Baruusa no Fukushuu? Rarement vu un jeu aussi mauvais   .

J’avais pas vu tous ces messages en 1 an depuis mon dernier message ici.

Déjà merci pour ton reverse engineering qui permet de démystifier plein de choses erronées du net, y compris de certains développeurs/concepteurs visiblement (Isuke).

Je réagis juste sur les jeux hors arcades que tu qualifies souvent de mauvais. Je trouve cette avis très réducteur.
Déjà si on prend en compte les adaptations des hits des autres micros, on en a beaucoup de très bon, dont certains dans les meilleurs versions : Ys III sans saccades mais aussi Phalanx, Thunder Force 2, Star Cruiser, en rpg Last Armageddon, Emerald Dragon, Zavas, Lagoon, le 1er Ys.
En exclu Aquales, Etoile  Princess, Scorpius, Geograph Seal, Naious, Overtake, War Torn Versnag en rpg exclu, etc.
Sans trop forcer je t’en cite pas mal déjà. Aucun de ces jeux ne sont des daubes ou mauvais.

Même pour Barusa bo Fukushu (rare que j’ai dû payer 200 balles pour l’avoir), je ne dirais pas qu’il est mauvais, au pire moyen : une bonne direction artistique et une B.O qui tabasse. Il se place là en bon rival de Ys III. Tu as passé le bateau au moins ou tu t’es raté au 1er boss sur ému ?
Après je reconnais que ça bouge pas très bien, que les collisions sont pas terribles et qu’il n’est pas très jouable.
Mais ses autres qualités le rattrapent.

[dlfrsilver]

je confirme, j'ai vu Barusa No Fukushu et le jeu est pourri. 

Clairement pas mon préféré. 

YS III est fabuleux, quelle bande son !

[msx33]

Il n’est pas au niveau d’Ys III, mais pourri je trouve ça fort...
Dans tous les cas je maintiens qu’il y a beaucoup de jeux non arcade qui sont bons.

[dlfrsilver]

Il n’est pas au niveau d’Ys III, mais pourri je trouve ça fort...

perso, je supporte pas les jeux moches. Barusa no machin truc, juste non. 

YS 3 je dois le recevoir sous peu, je me demande même si ça je vais pas m'accrocher sur le japonais :)

[msx33]

Je trouve Barusa limite plus beau qu’ Ys III (grand sprite, plein écran), donc ton avis me surprend.

Un jeu moche n’en fais pas un jeu mauvais au passage.
Après c’est ton avis (que je respecte).

Dans l’absolu si tu creuses, le jeu est plus que correct.

[upsilandre]

Je réagis juste sur les jeux hors arcades que tu qualifies souvent de mauvais. Je trouve cette avis très réducteur.
Déjà si on prend en compte les adaptations des hits des autres micros, on en a beaucoup de très bon, dont certains dans les meilleurs versions : Ys III sans saccades mais aussi Phalanx, Thunder Force 2, Star Cruiser, en rpg Last Armageddon, Emerald Dragon, Zavas, Lagoon, le 1er Ys.
En exclu Aquales, Etoile  Princess, Scorpius, Geograph Seal, Naious, Overtake, War Torn Versnag en rpg exclu, etc.
Sans trop forcer je t’en cite pas mal déjà. Aucun de ces jeux ne sont des daubes ou mauvais.

Il fallait rétablir la vérité avec une liste de jeu en bonne et due forme  
mais tu me fera pas changer d'avis sur Barusa qui selon moi est vraiment d'une nullité incroyable    (vraiment aucune notion de gamedesign dans ce jeu, je pense que le gars faisait un jeu vidéo pour la première fois) mais du coup je le conseille, c'est assez culte. Et oui j'ai passé le bateau, j'étais bien obligé pour creuser un peu les choix technique (car le stage du bateau n'a pas vraiment de "scrolling", tous les layers sont intégralement en VRAM) et ca été une souffrance . Quand tu fais un premier stage comme ca c'est vraiment que t'as rien compris au jeu vidéo, je pense malheureusement que tout est dit dans ce stage. Mais c'est toujours intéressant les mauvais jeux ou les jeux raté, ca permet de se questionner justement sur ce qui fait un bon jeu de façon plus évidente qu'a l'habitude. Donc oui il faut testez ce jeu .

Par contre tu me rappel qu'il faut absolument que je joue a Geograph Seal maintenant que j'ai l'émulateur sous la main. en temps que grand fan de Jumping Flash j'ai toujours voulu tester son "prorotype"

[msx33]

Barusa a dû être sortie à la hâte et c’est un jeu pas fini (des boss manquants dans certains stages, etc). C’est le 3ème opus de Tritorn pour info.

Le premier stage n’est pas fou mais tu en a des suivants plus intéressants.
Le juger sur un seul niveau n’est donc pas très honnête je trouve (je ne parle pas de technique là). C’est pour moi un bon petit jeu, je maintiens, et il n’a pas/n’a jamais eu la réputation de daube.
Petite review qui j’espère te convaincra de lui redonner une chance : https://www.google.fr/amp/www.hardcoregaming101.net/baruusa-no-fukushuu/amp/

Geograph Seal il faut y jouer en 24mhz sur du 30 pour être dans les meilleurs conditions.

[upsilandre]

Petite review qui j’espère te convaincra de lui redonner une chance :

Probablement un jour (dans une autre vie, pas sure d'avoir le temps dans celle ci   )

Geograph Seal il faut y jouer en 24mhz sur du 30 pour être dans les meilleurs conditions.

C'est sur qu'entre un 68000 a 10mhz et un 68030 a 24mhz ca doit faire une grosse différence
Mais j'aime bien les débuts de la 3D, meme dans son jus d'époque. Je devrais pouvoir choper la routine de rasterization (ca devrait pas être dure, elle doit occuper une bonne partie des ressources CPU )

[msx33]

Bon après c’est pas le jeu du siècle non plus on est d’accord et il passe derrière plein d’autres.
Tu peux ajouter dans la liste en exclu X68000 le très bon Die Bahnwelt et le sympathique Knight Arms aussi.

Pour Geograph Seal, j’y joue sur mon 16 en 24mhz (overclocké).
Il est franchement sympa. Si tu peux en faire une analyse technique sur celui là plus tard je suis preneur.

Tu y joues que sur ému ? Si oui, tu comptes prendre un X68K un jour ?

[upsilandre]

Nan c'est pas prévu, les micro ca m'intéresse un peu mais de loin quand même

[dlfrsilver]

Bon après c’est pas le jeu du siècle non plus on est d’accord et il passe derrière plein d’autres.
Tu peux ajouter dans la liste en exclu X68000 le très bon Die Bahnwelt et le sympathique Knight Arms aussi.

Pour Geograph Seal, j’y joue sur mon 16 en 24mhz (overclocké).
Il est franchement sympa. Si tu peux en faire une analyse technique sur celui là plus tard je suis preneur.

Tu y joues que sur ému ? Si oui, tu comptes prendre un X68K un jour ?

die bahnwelt a été traduit en anglais au fait :)

[upsilandre]

Comme promis j'ai quand meme jeter un oeil rapide sur Geograph Seal



Effectivement on retrouve bien le gameplay de Jumping Flash  
Si ce n'est que sur Jumping Flash ils se sont plus focus sur le coté plateforme que shooting ce qui est plutot cool, et puis il y avait surtout bien plus de ressource 3D sur Playstation.
Mais on voit bien le dilemme de Sony a l'époque, c'était quasi impossible de trouver des programmeurs Japonais qui faisait de la 3D donc il a fallu ratisser large et même aller chercher sur X68000 :)

Le rendu 3D tourne en 240x160 (224x192 pour Starfox par exemple) avec un framerate du même ordre que Starfox, autour de 10 fps a peine sur le X68000 de base.
Pour le rendu on trouve évidemment des routines optimisé pour le tracé de ligne (14 routines pour s'adapter a n'importe quelle longueur de ligne) mais le truc qui m'a intéressé c'est leur façon d'effacer l'image car l'une des étapes les plus lourdes c'est effectivement l'effacement de l'image entre chaque rendu et encore une fois on peut constater que le X68000 n'a vraisemblablement aucune fonction DMA pour aider a déplacer des data en RAM ou faire du Fill...

Bref donc encore une fois faut tout faire au CPU avec des MoveM mais ils ont été astucieux. Déjà ils n'ont utilisé que la moitié de la palette 256, l'autre partie est en noir 0. Et ainsi grâce a un swaping de la palette ils peuvent faire 2 fois le rendu dans le même frame buffer sans l'effacer mais en plus ils utilisent 4 frame buffers 256x256 répartie dans les 2 layers 8 bpp du X68000. Ainsi ça permet de pouvoir passer par le layer 16 bpp (qui contient les autres) pour l'effacement en utilisant donc des accès 16 bit complets mais qui efface 2 buffer 8 bpp a la fois (d'ou la nécessité d'en utiliser 4 pour pas effacer celui utiliser actuellement a l'écran).
Tout cela permet de n'avoir qu'à effacer un quart d'écran (40 lignes) après chaque rendu. Sans cela la routine d'effacement prendrait 22 ms, avec ces optimisations ca prend moins de 6 ms et ca permet d'économiser a peu prêt une frame complète a chaque rendu. Une belle optimisation!  




Sinon rien a voir avec Geograph Seal mais je me suis amusé aussi a comparer a quelle vitesse on peut mettre a jour le tileset des sprites Cynthia car on dit parfois que la limite de 32 Ko de Cynthia disponible pour les sprites (si on fait le deuil des BG) c'est pas très grave car on peut mettre a jour le tileset de façon dynamique entre chaque frame. Mais cette usage dynamique de la VRAM de Cynthia c'est déjà ce qu'on fait aussi sur les consoles 16 bit et encore une fois comme il n'y a pas de fonction DMA pour ca et bien au final la Megadrive fait ca 2.5 fois plus rapidement que le X68000 de base pendant le Vblank. Par contre le X68000 sera 3x plus rapide hors du Vblank. C'est la que ce situe la différence. Le X68000 est plus lent pour cette tache mais il n'est pas obligé de le faire pendant le Vblank alors que sur console tu fais ca uniquement pendant le court instant du Vblank.
Donc encore une fois le X68000 s'en sort bien et arrive a faire comme sur console ou arcade mais c'est toujours en utilisant sensiblement plus de ressource CPU (d'ou parfois les recommandations de CPU plus puissant). C'est en ca qu'on est pas vraiment dans une philosophie console ou arcade qui consiste justement a ce que l'affichage consomme le moins de ressource CPU.

[upsilandre]

Et je me suis planté sur le framerate de Afterburner. Je me suis fait avoir par le frame advance bizarre de l'émulateur, il avance de 2 frames en 2 frames ce salaud.
Effectivement ca me paraissait bizarre que Afterburner puisse tenir en 1 vbl avec des sprites software (et visuellement ca ressemblait pas a du 60 fps) donc en vrai il tourne a 30 fps. Ce qui est toujours pas mal pour du sprite software (mais la version PCE tourne a 60 fps)

[darksun66]

Un jour je l'aurai !! :)