Re: Le x68000 et la supériorité japonaise

[upsilandre]

J'ai réussi a trouver la confirmation qu'il y a bien 512 pixel-sprite par scanline


C'est la dernière confirmation que je cherchais dans la doc car malheureusement sur le site le plus sérieux du X68000 qui se base justement sur la doc officielle on trouve une page de specs ou ils indiquent "16 sprite par lignes" ce qui du coup était en contradiction avec les autres sources (et meme avec d'autre page du meme site) ce qui m'a mis le doute
https://gamesx.com/wiki/doku.php?id=x68000&s[]=sprite

[TotOOntHeMooN]

Il semblerait que Cynthia dispose des lignes PA0-PA12 pour adresser sa mémoire RAM et PD0-PD31 pour les données. Ce qui correspond à 32x8192 soit effectivement 32K de mémoire vidéo... En 32bit!!!

On peut imaginer que sur des versions plus récentes de carte mères, les 32 circuits de DRAM soient avantageusement remplacés par 4x8K de SRAM... Si Cynthia dispose de PA13-PA14 non connecté, il serait possible d'avoir 4x32K de SRAM (même package) soit 128K en 32bit... Mais ça reste une hypothèse.

[upsilandre]

Et y a 4 chip 8bit je crois.
C'est pas déconnant quand on sait que la PCE c'est du 16bit et y a 2 fois moins de BG et de sprite.
En plus le Cynthia supporte au moins du 512x512 en affichage sur 2 BG (c'est peut être de la d'ailleurs que vient le 512 pixel-sprite par scanline).
La SupergrafX c'est en quelque sorte du 32bit sur la VRAM (2 x 16bit)

[upsilandre]

On peut imaginer que sur des versions plus récentes de carte mères, les 32 circuits de DRAM soient avantageusement remplacés par 4x8K de SRAM... Si Cynthia dispose de PA13-PA14 non connecté, il serait possible d'avoir 4x32K de SRAM (même package) soit 128K en 32bit... Mais ça reste une hypothèse.

Le problème c'est que Cynthia semble vraiment calibré pour du 32Ko.
Par exemple le pointeur de tile des sprites est bridé a 8 bit (256 tiles 16x16 = 32Ko) la ou sur PCE par exemple c'est 11bit. Pareille pour le pointeur de tile BG sur 8bit aussi (12bit sur PCE).
Il a l'aire d'avoir été designé pour cette configuration.

[TotOOntHeMooN]

Oui, tu as raison. Se sont bien les 4 circuits CMS en dessous à gauche les 4x 8K de SRAM.
Du coup, les 32x ZIF sur la droite c'est une autre mémoire...

J'ai trouvé le schéma avec Cynthia et les numéros de pins confirment que c'est limité à 32K.

[upsilandre]

Bon je pense qu'on a fait le tour. J'ai enfin eu mes réponses. Je vais pouvoir retourner sur ma NES, j'ai des one life a faire

[TotOOntHeMooN]

OK. J'ai juste rajouté le schéma au dessus pour la forme !

[upsilandre]

C'est beau les shematics
Effectivement PA0-PA12

[ArchieForEver]

C'est beau les shematics
Effectivement PA0-PA12

Ca manque cruellement d'intégration, tout ça

[dlfrsilver]

J'ai réussi a trouver la confirmation qu'il y a bien 512 pixel-sprite par scanline


C'est la dernière confirmation que je cherchais dans la doc car malheureusement sur le site le plus sérieux du X68000 qui se base justement sur la doc officielle on trouve une page de specs ou ils indiquent "16 sprite par lignes" ce qui du coup était en contradiction avec les autres sources (et meme avec d'autre page du meme site) ce qui m'a mis le doute
https://gamesx.com/wiki/doku.php?id=x68000&s[]=sprite

Oui c'est exact. En fait, l'X68000 est similaire graphiquement au System16 et 18 de Sega, mais avec pas autant de sprites affichables. 

La layer Text est planar, par contre les layers 0 et 1 pour les sprites et backgrounds sont en bitmap chunky. 

D'ou les ports hyper facile comme super hang on ou Thunderblade, qui utilisent le même système d'affichage.

(Super Hangon x68000 utilise le code source de l'arcade, avec le code 68000 principal fusionné avec celui du slave qui gère la route).

Le x68000 mixant à l'écran les deux types d'affichages, tranquille. Seul After Burner est un peu décevant, car le programmeur a bridé le jeu pour les machines avec 2 mo de ram. Avec plus de ram, il y aurait eu la possibilité de mettre plus d'objets à l'écran.

[dlfrsilver]

Concernant les jeux CPS, voici la page de configuration hardware de Daimakaimura (que j'ai traduit en anglais du japonais) : 

[upsilandre]

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   .

[TotOOntHeMooN]

Pas très étonnant qu'ils recommandent un 68030...

[upsilandre]

Ce qui est marrant c'est de voir comment ils se sont bien cassé la tete sur la scène de la tempête car en vrai cette scène la sur CPS c'est beaucoup de mise a jour de la tilemap, des mise a jour fullscreen sur les 2 plans.
La ils ont utilisé toutes les ruses possible pour pas mettre a genoux le X68000
- Les mouvements de l'herbes et de l'eau se font avec des sprites pour eviter les maj du background
- L'animation du second plan se fait avec une astuce de cycling de palette (75 slots de la palettes utilisé pour une douzaine de couleurs) donc la aussi ils evitent les maj du background, juste un changement de palette pour switcher entre les 2 frames qui sont toutes les 2 deja contenu dans le BG (au moins ca permet d'exploiter astucieusement le format 8bpp).
- L'animation des arbres du premier plan sont bien fait par une maj du background et ca se fait dans la douleur. Tu peux avoir 2 arbres a l'ecran mais le jeu peine a mettre a jour un demi arbre a la fois (donc avec un tearing vertical)
- La pluie est géré comme sur CPS, avec le layer du HUD, donc juste un switch de scrolling (qui ici nécessite quand meme de changer la palette puisque le Text layer n'a qu'une seule palette)

Ils n'ont pas manqué d'ingéniosité. L'adaptation semble avoir été fait sérieusement quand même (car clairement ca demande de l'adaptation contrairement a ce qu'on pourrait croire).
On peut noter que le second plan utilise aussi des tuiles 16x16 et pas des tuiles 32x32 comme sur CPS malgré qu’ici les tilemap sont software (et aurait donc pu émuler le format CPS) mais il s’agit d'utiliser la même routine de chargement de tile pour les 2 plans (et des tuiles 32x32 c'est trop lourd a manipuler).

En tout cas d'un point de vue hardware y a définitivement aucun rapport entre le X68000 et le CPS (a part le CPU), c'est 2 hardwares radicalement différent.

[TotOOntHeMooN]

Je penses qu'ils ont voulu faire au mieux avec les moyens qu'ils avaient. Que c'était impensable de faire une version au rabais pour un titre aussi emblématique. Et finalement, peut-être que certains ont opté pour la version 68030 de la machine afin d'y jouer... ^^

Quand on voit "l'émulateur" sur STe de Daimakaimura, je me demande s'il n'y aurait pas un moyen d'avoir une meilleur version avec un 68000 de nos jours en reposant sur un principe similaire pour l'affichage des tiles.

[upsilandre]

Le jeu tourne quand meme assez bien et de facon très fidèle. C'est juste que ca consomme beaucoup trop de ressource par rapport a ce que c'est et ce que ca aurait du etre tel que je l'imaginais au départ en passant par Cynthia (sur CPS je pense que le 68000 se tourne largement les pouces)

Quand je dis 45% de ressource CPU pour le scrolling vertical c'est pour la mise a jour d'une bande horizontal complète d'un background (24 tiles 16x16) car les maj des background se font d'un seul tenant sur une bande complète et donc pas a chaque frame.
Mais t'as en gros 4 types possibles de maj de ce type (bande vertical, bande horizontal, plan A, plan B) qui se répartissent sur différente frames + la gestion dynamique du tileset de Cynthia (a peu prêt 2 fois plus rapide par tile) + parfois certain FX.

[TotOOntHeMooN]

Je tique juste par rapport au besoin d'un 68030 pour que se soit parfaitement fluide. 
Comme tu dis, sur CPS le 68000 doit probablement se tourner les pouces... 

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)

Il y a quand même un soucis dans la façon de faire le scrolling du background comparé à d'autres jeux ?

[upsilandre]

Apparemment l'instruction MOVEP est assez bien calibré pour ce cas particulier.
MOVEP va découper un registre 32bit en 4 octets et va envoyer successivement chaque octets a d'adresse N puis N+2, N+4 et N+6 donc dans l'octet LSB de chaque world. C'est parfait pour le cas présent (puisque les adresse N+1, N+3, N+5, N+7 contiennent les pixels du second plan)
Donc avec un MOVEP (27 cycles dans ce contexte) t'as chargé 4 pixels.

Et MOVEM sert a charger les registres 32bit. Ici il est utilisé pour charger successivement 4 registre 32bit (donc 16 pixels) en une seule instruction suivie de 4 MOVEP et donc avec ce petit bloc de 5 instructions tu charges une ligne de tile complète
MOVEM.L (A3)+,D3-D5/D7   (44 cycles)
MOVEP.L D3,+$0000(A2)      (27 cycles)
MOVEP.L D4,+$0008(A2)      (27 cycles)
MOVEP.L D5,+$0010(A2)      (27 cycles)
MOVEP.L D7,+$0018(A2)      (27 cycles)

Et donc la routine copie-colle ce bloc 16 fois pour charger une tile complète en une seule boucle (+ quelques instructions de préparations évidemment). Je ne pense pas qu'ils pouvait faire plus rapide (c'est jute étonnant que le DMA n'ait rien a proposé d'intéressant de ce coté la a priori)
Et j'imagine que même en utilisant les Graphic layers en 4bpp ils passeraient toujours pas cette même routine avec donc les même contrainte (la même lenteur et la même place occupé par les tiles) car il n’y a pas d'équivalent 4bit à l'instruction MOVEP. Ce qui rend ce format 4 layers 4bpp encore plus inutile qu'il ne l'était déjà avec son unique palette pour 4 layers.

Pour le tileset de Cynthia ils utilisent des MOVE.L classique puisque la c'est du chunky classique donc il déplace un mot de 32bit (qui contient donc 8 pixels 4bpp successif) de la RAM a la VRAM de Cynthia en une seul instruction.
Et la aussi il font ca en force brute sans boucle en alignant 256 Move successif (de quoi déplacer 32 tiles 8x8 ou 8 tiles 16x16 d'un coup si tu prend la routine du début) donc j'imagine qu'il serait difficile de faire plus rapide.

[dlfrsilver]

Apparemment l'instruction MOVEP est assez bien calibré pour ce cas particulier.
MOVEP va découper un registre 32bit en 4 octets et va envoyer successivement chaque octets a d'adresse N puis N+2, N+4 et N+6 donc dans l'octet LSB de chaque world. C'est parfait pour le cas présent (puisque les adresse N+1, N+3, N+5, N+7 contiennent les pixels du second plan)
Donc avec un MOVEP (27 cycles dans ce contexte) t'as chargé 4 pixels.

Et MOVEM sert a charger les registres 32bit. Ici il est utilisé pour charger successivement 4 registre 32bit (donc 16 pixels) en une seule instruction suivie de 4 MOVEP et donc avec ce petit bloc de 5 instructions tu charges une ligne de tile complète
MOVEM.L (A3)+,D3-D5/D7   (44 cycles)
MOVEP.L D3,+$0000(A2)      (27 cycles)
MOVEP.L D4,+$0008(A2)      (27 cycles)
MOVEP.L D5,+$0010(A2)      (27 cycles)
MOVEP.L D7,+$0018(A2)      (27 cycles)

Et donc la routine copie-colle ce bloc 16 fois pour charger une tile complète en une seule boucle (+ quelques instructions de préparations évidemment). Je ne pense pas qu'ils pouvait faire plus rapide (c'est jute étonnant que le DMA n'ait rien a proposé d'intéressant de ce coté la a priori)
Et j'imagine que même en utilisant les Graphic layers en 4bpp ils passeraient toujours pas cette même routine avec donc les même contrainte (la même lenteur et la même place occupé par les tiles) car il n’y a pas d'équivalent 4bit à l'instruction MOVEP. Ce qui rend ce format 4 layers 4bpp encore plus inutile qu'il ne l'était déjà avec son unique palette pour 4 layers.

Pour le tileset de Cynthia ils utilisent des MOVE.L classique puisque la c'est du chunky classique donc il déplace un mot de 32bit (qui contient donc 8 pixels 4bpp successif) de la RAM a la VRAM de Cynthia en une seul instruction.
Et la aussi il font ca en force brute sans boucle en alignant 256 Move successif (de quoi déplacer 32 tiles 8x8 ou 8 tiles 16x16 d'un coup si tu prend la routine du début) donc j'imagine qu'il serait difficile de faire plus rapide.

En gros, tu confirmes donc pour les sprites que la VRAM de Cynthia est rechargée en permanence ?

En tout cas, ça a beau être de l'assembleur, purée, la taille de la routine pour juste 1 tuile, mais c'est immonde ! ça veut dire même qu'avec un affichage planar, y a sérieusement moyen de simplifier le bordel....
on a au final un très gros programme, à cause des routines pour afficher de la tuile en bitmap chunky quoi...

[dlfrsilver]

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'ai trouvé 2 jeux sur X68000, qui m'ont fait péter des barres de rires : 

- Sazae (mort de rire, le mec se branle dans l'intro (censurée), y a un chien qui encule un chat dans le jeu (c'est un shoot), la p'tite soeur qui chiale pour empêcher les parents de tirer un coup et j'en passe. A hurler de rire 

-Ohimesama Ahh!! my Princess! un Doujin très marrant dans lequel on incarne une princesse qui balance tout un tas d'objet sur la tronche de singes marrons et blancs (style x68000, le logo konami, un canapé, une pierre, une commode, etc). quand elle gagne, une scenette ultra drole apparait. 

Typiquement des jeux qui seraient délire à adapter sur nos machine occidentales 

[upsilandre]

En gros, tu confirmes donc pour les sprites que la VRAM de Cynthia est rechargée en permanence ?

Oui ca t'es un peu obligé mais c'est déjà plus ou moins le cas sur les consoles 16bit. Il faut avoir une gestion dynamique de la VRAM si tu veux un niveau minimum d'animation des sprites.
Au final quand Cynthia est utilisé uniquement pour les sprites (donc la majorité des cas) ca donne une situation assez proche des consoles 16bit en terme d'espace disponible et donc de gestion de la VRAM.
Par contre l'accès a la VRAM de Cynthia a l'aire d'ajouter pas mal de cycle de pénalité. De ce que j'ai vu le MOVE utilisé consommait 44 cycles (selon l'émulateur) alors que cette instruction doit prendre 20 cycles en théorie (et c'est d'ailleurs le cas un peu plus dans le code du jeu quand c'est exécuté sur la RAM). Je connais pas assez bien le 68000 pour savoir si c'est normale ce type de variabilité selon la mémoire pointé mais j'imagine que le 68000 doit avoir ce type de flexibilité vis a vis des mémoires.  

En tout cas, ça a beau être de l'assembleur, purée, la taille de la routine pour juste 1 tuile, mais c'est immonde !

Ca c'est plutôt un choix d'optimisation justement. Il est facile effectivement de réduire la routine mais ca implique d'ajouter une boucle avec branchement conditionnel qui coute des cycles supplémentaire pour chaque lignes de tuile.
Ce choix de sacrifier le coté compact du code pour économiser au maximum les cycles est assez classique dans ce genre de situation surtout quand t'es pas sur 8bit avec des contraintes forte sur l'espace ROM ou RAM. Mais tu réserve ca a des routine vraiment sensible qui consomme beaucoup de ressource et qui sont central dans les performances et la c'est le cas. Les quelques dizaines d'octets de RAM perdu sont largement rentabilisé.

ça veut dire même qu'avec un affichage planar, y a sérieusement moyen de simplifier le bordel....

Planar c'est chiant pour les accès individuels au pixel mais pour charger une tuile c'est très bien, y a pas de problème, au contraire dans ce cas c'est mieux que la configuration des Graphic Layer qui n'est pas planar mais pas vraiment chunky non plus (contrairement aux tuiles de Cynthia) a cause de l'entrelacement des plans qui fout un peu le bazar (heureusement qu'il y a le MOVEP).
Sur le X68000 comme tu sais y a que le Text layer qui est planar (4bpp) et ca doit etre au moins 3 fois plus rapide de charger une tile sur ce Text layer que sur les Graphic layers (même en mode 4bpp). C'est sans doute pour ca que R-Type utilise le Text layer pour son second plan plutot que d'utiliser le second Graphic layer qui n'est pas utilisé.

[TotOOntHeMooN]

Il est vrai que les arrières plans de GNG sont pauvres en couleurs et utiliser le "text layer" aurait été plus judicieux... Quitte à gérer l'overlay des scores en bitmap.

[dlfrsilver]

En gros, tu confirmes donc pour les sprites que la VRAM de Cynthia est rechargée en permanence ?

Oui ca t'es un peu obligé mais c'est déjà plus ou moins le cas sur les consoles 16bit. Il faut avoir une gestion dynamique de la VRAM si tu veux un niveau minimum d'animation des sprites.
Au final quand Cynthia est utilisé uniquement pour les sprites (donc la majorité des cas) ca donne une situation assez proche des consoles 16bit en terme d'espace disponible et donc de gestion de la VRAM.
Par contre l'accès a la VRAM de Cynthia a l'aire d'ajouter pas mal de cycle de pénalité. De ce que j'ai vu le MOVE utilisé consommait 44 cycles (selon l'émulateur) alors que cette instruction doit prendre 20 cycles en théorie (et c'est d'ailleurs le cas un peu plus dans le code du jeu quand c'est exécuté sur la RAM). Je connais pas assez bien le 68000 pour savoir si c'est normale ce type de variabilité selon la mémoire pointé mais j'imagine que le 68000 doit avoir ce type de flexibilité vis a vis des mémoires.  

En tout cas, ça a beau être de l'assembleur, purée, la taille de la routine pour juste 1 tuile, mais c'est immonde !

Ca c'est plutôt un choix d'optimisation justement. Il est facile effectivement de réduire la routine mais ca implique d'ajouter une boucle avec branchement conditionnel qui coute des cycles supplémentaire pour chaque lignes de tuile.
Ce choix de sacrifier le coté compact du code pour économiser au maximum les cycles est assez classique dans ce genre de situation surtout quand t'es pas sur 8bit avec des contraintes forte sur l'espace ROM ou RAM. Mais tu réserve ca a des routine vraiment sensible qui consomme beaucoup de ressource et qui sont central dans les performances et la c'est le cas. Les quelques dizaines d'octets de RAM perdu sont largement rentabilisé.

ça veut dire même qu'avec un affichage planar, y a sérieusement moyen de simplifier le bordel....

Planar c'est chiant pour les accès individuels au pixel mais pour charger une tuile c'est très bien, y a pas de problème, au contraire dans ce cas c'est mieux que la configuration des Graphic Layer qui n'est pas planar mais pas vraiment chunky non plus (contrairement aux tuiles de Cynthia) a cause de l'entrelacement des plans qui fout un peu le bazar (heureusement qu'il y a le MOVEP).
Sur le X68000 comme tu sais y a que le Text layer qui est planar (4bpp) et ca doit etre au moins 3 fois plus rapide de charger une tile sur ce Text layer que sur les Graphic layers (même en mode 4bpp). C'est sans doute pour ca que R-Type utilise le Text layer pour son second plan plutot que d'utiliser le second Graphic layer qui n'est pas utilisé.

Tu pourrais regarder le cas de Final Fight et nous dire de quoi il en retourne ? 

je suis sur qu'il y a des trucs intéressants dedans :)

[upsilandre]

Je continu de scruter quelques jeux tant que j'ai l'émulateur bien en main, je commence a bien le maitriser et a bien connaitre le mapping mémoire (mais le bordel que c'est quand j'ouvre toutes les fenêtre qui m'intéresse, ca me fait 20 fenêtres, heureusement que j'ai 2 écrans)

Je remarque que la VRAM du Text layer est souvent utilisé pour y stocker les tiles des autres layers. Ce qui est un peu logique, on va pas gacher les 512Ko de VRAM du Text layer.
Par exemple Castlevania stocke les tiles des background ainsi que ceux des sprite dans la VRAM du Text layer. Afterburner aussi. Par contre ca peut ajouter quelque cycle de wait mémoire.
Final Fight lui stock les tiles de chaque plan de background dans la VRAM du Graphic layer en question puisque les plans 512x256 n'utilisent que la moitié de la VRAM, l'autre moitié est donc utilisé pour les tiles. Comme ca tout est au meme endroit (le background et son tileset).

J'ai continué quand meme de cherché si y avait pas des fonction DMA calibré pour les bloc d'image, ou encore mieux avec des petites fonction de type blitter mais y a vraiment rien a priori.
After Burner qui utilise un layer complet de sprite software (dans un Graphic layer) pour quasiment tous les sprites du jeu, construit ce layer de la façon la plus basique et fastidieuse qui soi, y a vraiment rien dans le hardware pour aider apparemment a faire du sprite software.
Afterburner se contente donc d'effacer un par un chaque sprite, pixel par pixel et ligne par ligne simplement avec des MOVE pour ensuite réécrire chaque sprite pixel par pixel et ligne par ligne avec des MOVE (du sprite le plus loin au plus proche évidement, et avec un double buffering). Mais il le fait quand meme avec une bonne efficacité. Ca a l'aire très bien codé. D'ailleurs ca tourne quasiment a 60fps sur le X68000 de base (disons entre 40 et 60fps), malgré tous les sprite software (les avions, bullet, explosion) et les FX comme la fumée. La rotation de la ligne d'horizon est une astuce de palette qui utilise 64 slots, encore une bonne façon ingénieuse d'utiliser le format 8bpp.


Mais surtout je me suis intéressé aux cycles de pénalités des différentes VRAM car les MOVE n'ont pas la même vélocité selon la RAM qui peut ajouter des cycles de wait.
Clairement l'acces a la VRAM de Cynthia ne se fait pas dans les même condition que les autres VRAM. Ca ajoute beaucoup de cycle d'attente et avec une distinction entre les accès pendant le Vblank et ceux hors Vblank (contrairement aux autres VRAM). Encore une fois on sent que Cynthia c'est vraiment la partie "console".
Un MOVE.L c'est normalement 20 cycles. Lorsque c'est a destination de la VRAM de Cynthia c'est 12 cycles de pénalité pour un acces pendant le Vblank (donc 32 cycles) et encore 12 cycles de plus hors Vblank (44 cycles). C'est quand meme dommage. Pour les autres VRAM ca va être plutôt 2 ou 3 cycles (pendant ou hors Vblank), parfois 0.

Chaque layer a au final ses atouts et inconvénient. Je me suis alors amusé a tenter de comparer les meilleurs vitesses de chargement des tiles possible selon les layers.
Donc la meilleur routine de chargement de tile dans le Graphic layer (MOVEM.L sur la totalité des 8 registre data + 8 MOVEP.L) ca donne 9.125 cycle/pixel et ca fonctionne pour n’importe quelle format de tile. C'est assez efficace comme combinaison. C'est la meme que Daimakaimura (9.5 cycle/pixel) mais en utilisant tous les registres du 68000 (utilisé dans Final Fight).
Pour les tiles de Cynthia qui ont l’avantage d'être en vrai 4bpp chunky et avec un agencement nativement en tile (donc pas besoin d’offset sur les Move, les lignes de tile se suivent) on va plutot utiliser du MOVE.L et ca donne 5.5 cycle/pixel pendant l’affichage et 4 cycle/pixel pendant le Vblank et ca marche même sur du 8x8 (mais si y avait pas de cycle de pénalité mémoire au moins pendant le Vblank ca donnerait seulement 2.5 cycle/pixel, dommage).
Pour le Text layer c'est pas si bien que ca finalement. Il a l’avantage d’etre en 4bpp effectif mais le planar fait que chaque accès couvre beaucoup de pixel (un bit par pixel), ce qui déjà implique des MOVE avec offset car chaque ligne de tile est a une adresse très différente (contrairement a Cynthia) et nécessite aussi idéalement de grosse tiles 32x32 si on utilise des Move 32bit ce qui est un format pas très viable (mais donnerait dans les 3.375 cycle/pixel je pense, pas trouvé d'exemple) mais dans un format 16x16 plus viable ca donnerait 4.625 cycle/pixel et meme 9.25 cycle/pixel en 8x8 puisque ca limiterait a des Moves 8bit (du coup en 8x8 le Graphic layer peut même etre plus rapide que le Text layer).

Mais évidement ca peut parfois être bien plus. Par exemple dans Castlevania parfois les tiles sont chargé pixel par pixel dans le Graphic layer (et à partir du Text Layer ce qui ajoute une pénalité de plus) tout simplement pour pouvoir appliquer un flipping software (et donc économiser de la VRAM) et ca donne alors 22.5 cycle/pixel. Mais Castlevania fait une mise a jour du scrolling très étalé, pas des bandes complètes, juste 2 tiles 16x16 par frame (et plus les déplacement sont lent) donc ca pose pas du tout de problème ce genre de choix.

Bon la faut vraiment que j'arrête car je pourrais encore faire ca pendant des heures

[TotOOntHeMooN]

Mais je pourrai aussi te lire pendant des heures 

[dlfrsilver]

Je continu de scruter quelques jeux tant que j'ai l'émulateur bien en main, je commence a bien le maitriser et a bien connaitre le mapping mémoire (mais le bordel que c'est quand j'ouvre toutes les fenêtre qui m'intéresse, ca me fait 20 fenêtres, heureusement que j'ai 2 écrans)

Je remarque que la VRAM du Text layer est souvent utilisé pour y stocker les tiles des autres layers. Ce qui est un peu logique, on va pas gacher les 512Ko de VRAM du Text layer.
Par exemple Castlevania stocke les tiles des background ainsi que ceux des sprite dans la VRAM du Text layer. Afterburner aussi. Par contre ca peut ajouter quelque cycle de wait mémoire.
Final Fight lui stock les tiles de chaque plan de background dans la VRAM du Graphic layer en question puisque les plans 512x256 n'utilisent que la moitié de la VRAM, l'autre moitié est donc utilisé pour les tiles. Comme ca tout est au meme endroit (le background et son tileset).

J'ai continué quand meme de cherché si y avait pas des fonction DMA calibré pour les bloc d'image, ou encore mieux avec des petites fonction de type blitter mais y a vraiment rien a priori.
After Burner qui utilise un layer complet de sprite software (dans un Graphic layer) pour quasiment tous les sprites du jeu, construit ce layer de la façon la plus basique et fastidieuse qui soi, y a vraiment rien dans le hardware pour aider apparemment a faire du sprite software.
Afterburner se contente donc d'effacer un par un chaque sprite, pixel par pixel et ligne par ligne simplement avec des MOVE pour ensuite réécrire chaque sprite pixel par pixel et ligne par ligne avec des MOVE (du sprite le plus loin au plus proche évidement, et avec un double buffering). Mais il le fait quand meme avec une bonne efficacité. Ca a l'aire très bien codé. D'ailleurs ca tourne quasiment a 60fps sur le X68000 de base (disons entre 40 et 60fps), malgré tous les sprite software (les avions, bullet, explosion) et les FX comme la fumée. La rotation de la ligne d'horizon est une astuce de palette qui utilise 64 slots, encore une bonne façon ingénieuse d'utiliser le format 8bpp.


Mais surtout je me suis intéressé aux cycles de pénalités des différentes VRAM car les MOVE n'ont pas la même vélocité selon la RAM qui peut ajouter des cycles de wait.
Clairement l'acces a la VRAM de Cynthia ne se fait pas dans les même condition que les autres VRAM. Ca ajoute beaucoup de cycle d'attente et avec une distinction entre les accès pendant le Vblank et ceux hors Vblank (contrairement aux autres VRAM). Encore une fois on sent que Cynthia c'est vraiment la partie "console".
Un MOVE.L c'est normalement 20 cycles. Lorsque c'est a destination de la VRAM de Cynthia c'est 12 cycles de pénalité pour un acces pendant le Vblank (donc 32 cycles) et encore 12 cycles de plus hors Vblank (44 cycles). C'est quand meme dommage. Pour les autres VRAM ca va être plutôt 2 ou 3 cycles (pendant ou hors Vblank), parfois 0.

Chaque layer a au final ses atouts et inconvénient. Je me suis alors amusé a tenter de comparer les meilleurs vitesses de chargement des tiles possible selon les layers.
Donc la meilleur routine de chargement de tile dans le Graphic layer (MOVEM.L sur la totalité des 8 registre data + 8 MOVEP.L) ca donne 9.125 cycle/pixel et ca fonctionne pour n’importe quelle format de tile. C'est assez efficace comme combinaison. C'est la meme que Daimakaimura (9.5 cycle/pixel) mais en utilisant tous les registres du 68000 (utilisé dans Final Fight).
Pour les tiles de Cynthia qui ont l’avantage d'être en vrai 4bpp chunky et avec un agencement nativement en tile (donc pas besoin d’offset sur les Move, les lignes de tile se suivent) on va plutot utiliser du MOVE.L et ca donne 5.5 cycle/pixel pendant l’affichage et 4 cycle/pixel pendant le Vblank et ca marche même sur du 8x8 (mais si y avait pas de cycle de pénalité mémoire au moins pendant le Vblank ca donnerait seulement 2.5 cycle/pixel, dommage).
Pour le Text layer c'est pas si bien que ca finalement. Il a l’avantage d’etre en 4bpp effectif mais le planar fait que chaque accès couvre beaucoup de pixel (un bit par pixel), ce qui déjà implique des MOVE avec offset car chaque ligne de tile est a une adresse très différente (contrairement a Cynthia) et nécessite aussi idéalement de grosse tiles 32x32 si on utilise des Move 32bit ce qui est un format pas très viable (mais donnerait dans les 3.375 cycle/pixel je pense, pas trouvé d'exemple) mais dans un format 16x16 plus viable ca donnerait 4.625 cycle/pixel et meme 9.25 cycle/pixel en 8x8 puisque ca limiterait a des Moves 8bit (du coup en 8x8 le Graphic layer peut même etre plus rapide que le Text layer).

Mais évidement ca peut parfois être bien plus. Par exemple dans Castlevania parfois les tiles sont chargé pixel par pixel dans le Graphic layer (et à partir du Text Layer ce qui ajoute une pénalité de plus) tout simplement pour pouvoir appliquer un flipping software (et donc économiser de la VRAM) et ca donne alors 22.5 cycle/pixel. Mais Castlevania fait une mise a jour du scrolling très étalé, pas des bandes complètes, juste 2 tiles 16x16 par frame (et plus les déplacement sont lent) donc ca pose pas du tout de problème ce genre de choix.

Bon la faut vraiment que j'arrête car je pourrais encore faire ca pendant des heures

C'est normal qu'after Burner soit super bien codé, c'est le code source de Yu Suzuki qui a été utilisé pour la version X68000. Si tu fais un désassemblage de l'arcade et du code x68000 tu verras qu'il y a pas grand chose de changé. C'est pareil pour Super Hang On. C'est l'arcade qui tourne sur le sharp pur et simple, et ça m'a été confirmé par mon contact américain qui maitrise le X68000.

[TotOOntHeMooN]

C'est normal qu'after Burner soit super bien codé, c'est le code source de Yu Suzuki qui a été utilisé pour la version X68000.

Je pense qu'il parle de l'affichage, qui n'a rien à voir avec le code original.

[dlfrsilver]

C'est normal qu'after Burner soit super bien codé, c'est le code source de Yu Suzuki qui a été utilisé pour la version X68000.

Je pense qu'il parle de l'affichage, qui n'a rien à voir avec le code original.

Shaun Thompson, mon comparse, m'a dit que le programmeur a pas retouché grand chose dans son source. 
Maintenant, il est clair que d'après ce que dit upsilandre, Afterburner aurait du être beaucoup mieux que ça graphiquement. Matsushima a adapté le jeu pour des machines à 2mo. avec 8 ou 12mo sur un x68000, tu peux faire des super trucs.

[upsilandre]

Toute la partie affichage est propre au X68000, y a aucun point commun possible avec le jeu d'origine (et c'est le plus gros morceau je pense dans cette version. Mais si ils ont gardé le reste c'est cool). Et ce qu'arrive a sortir le jeu est plutôt impressionnant, le problème vient pas du jeu mais du X68000 qui n'est pas adapté a ce type de jeu.
Il y a trop de truc a afficher et trop gros pour que les petits sprite 16x16 de Cynthia puissent suffire (Cynthia s'occupe du sol, des effets de fumé, du dégradé sur l'horizon et du HUD) donc cette solution de sprite software est plutôt logique (ils l'ont surement pas fait de gaité de cœur car c'est bien plus compliqué) et c'est plutôt bien exécuté et optimisé vu que le X68000 propose rien pour aidé de ce coté. Je ne suis pas sur que plus de RAM change beaucoup de chose (si ce n'est que ca permettrait d'avoir plus d'étape intermédiaire pré-scalé pour mieux simuler le scaling)
Je pense que t'as trop de fantasme sur le X68000, ce n'est pas une machine d'arcade, c'est vraiment un micro  
Gérer tout ces gros sprites software, ces effets de fumé, de rotation d'horizon, le sol... en visant les 60fps avec un simple 68000 9.79mhz ca me parait vraiment du bon boulot.

[upsilandre]

Mais je pourrai aussi te lire pendant des heures 

Oui mais bon moi j'ai plus le temps de jouer la
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.

[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.