Re: Le x68000 et la supériorité japonaise

[TotOOntHeMooN]

Oui 16Bpp ça fait 65535 couleurs, on est d'accord, mais en attendant chaque layer est en 256 couleurs séparées soit 8bpp+8pp qui ne s'additionnent pas.

Ils n'ont pas besoin de s'additionner, puisqu'il est possible d'afficher un plan directement en 16bit...

le jeu a été développé par des développeurs de konami qui ont voulu faire une version X68000, profitant à fond de la plateforme. 

Ca, c'est un discourt de fan ou de commercial... Mais pour de vrai, il y a des infos ?

[dlfrsilver]

Oui 16Bpp ça fait 65535 couleurs, on est d'accord, mais en attendant chaque layer est en 256 couleurs séparées soit 8bpp+8pp qui ne s'additionnent pas.

Ils n'ont pas besoin de s'additionner, puisqu'il est possible d'afficher un plan directement en 16bit...

le jeu a été développé par des développeurs de konami qui ont voulu faire une version X68000, profitant à fond de la plateforme. 

Ca, c'est un discourt de fan ou de commercial... Mais pour de vrai, il y a des infos ?

Les layers sont indépendantes :) 

C'est pas un discours de fan, google est ton ami, il y a sur le net une interview de l'équipe konami qui a développé la version X68000.

[TotOOntHeMooN]

Les layers sont indépendantes :) 

65536 colors (1 plane)
256 out of 65536 colors (2 planes)
16 out of 65536 colors (4 planes)

http://museum.ipsj.or.jp/en/computer/personal/0038.html

[dlfrsilver]

Les layers sont indépendantes :) 

65536 colors (1 plane)
256 out of 65536 colors (2 planes)
16 out of 65536 colors (4 planes)

http://museum.ipsj.or.jp/en/computer/personal/0038.html

Les termes ne sont pas corrects. Layer en anglais, se traduit par couches ou calques. 

Oui 65535 couleurs, c'est 1 couche, 256 couleurs, c'est sur 2 couches indépendantes, et il y a effectivement 4 pages et non couches en 16 couleurs.

[TotOOntHeMooN]

Arrête de dire n'importe quoi... On parle de plans et non de calques ou de couches.

[dlfrsilver]

Arrête de dire n'importe quoi... On parle de plans et non de calques ou de couches.

Non, les mots ont un sens. dans le manuel japonais il est question de layers (couches/calques) et non de "planes".

on reprend : 

• Graphics hardware: Hardware scrolling, priority control, super-impose, dual tilemap background layers,^[4] sprite flipping^[5]
  
  
• Graphical planes: 1-4 bitmap planes, 1-2 tilemap planes, 1 sprite plane^[5][6]
  
  
  
  • plans Bitmap ^[1][5]
    
    
    
    • 1 couche: 512×512 resolution @ 65,536 colors on screen, or 1024×1024 resolution @ 64 colors on screen (out of 65,536 color palette)
      
    • 2 couches: 512×512 resolution @ 256 colors à l'écran par couche (512 colors combinées) (out of 65,536 color palette)
      
      
    
    
    
  
  
  

=> ceci est le mode utilisé par la plupart des jeux 2 couches en 512x512 avec 256 couleurs dans chaque soit 512 couleurs combinées

• 4 couches: 512×512 resolution @ 16 colors à l'écran par couche (64 colors combinées) (out of 65,536 color palette)
  

=> pas utilisé, ni dans akumajo ni dans aucun jeu converti du CPS1 de capcom

• BG tilemap planes^[5][6]
  
  
  
  • BG plane resolutions: 256×256 (2 layers) or 512×512 (1 layer)
    
  • BG chip/tile size: 8×8 or 16×16
    
  • Colors per BG layer: 256 (out of 65,536 color palette)
    
  • BG colors on screen: 256 (1 layer) or 512 (2 layers), out of 65,536 color palette
    
  • BG tiles on screen: 512 (16×16 tiles in 256×256 layers) to 4096 (8×8 tiles in 512×512 layer)
    
  
  
  
• Sprite plane^[1][5][6]
  
  
  
  • Sprite count: 128 sprites on screen, 32 sprites per scanline, 256 sprite patterns in VRAM (can be multiplied up to 512 sprites on screen with scanline raster interrupt method^[7])
    
  
  
  

=> jusqu'à 512 sprites à l'écran en raster

• Sprite size: 16×16
  
• Colors per sprite: 16 colors per palette, selectable from 16 palettes (out of 65,536 color palette)
  
• Sprite colors on screen: 256 (out of 65,536 color palette)
  

=> 256 couleurs pour les sprites + les 512 des décors = 768 couleurs !

• Sprite tile size: 8×8 or 16×16
  
• Sprite tile count: 128 (16×16) to 512 (8×8) on screen, 256 (16×16) to 1024 (8×8) in VRAM
  

Tu vois bien que dans les specs du X68000, il est bien question de couches (layer), on parle de plans dans l'ensemble.

[TotOOntHeMooN]

Et bien expliques nous la différence entre plan et layer japonais ! 

[dlfrsilver]

Et bien expliques nous la différence entre plan et layer japonais ! 

un plan est constitué de plusieurs couches. 

c'est pour cette raison que si tu utilises pas les bons termes, tu vas juste embrouiller les gens.

[TotOOntHeMooN]

un plan est constitué de plusieurs couches. 
c'est pour cette raison que si tu utilises pas les bons termes, tu vas juste embrouiller les gens.

Et bien tu tiens un sacré plan alors ! 

[dlfrsilver]

un plan est constitué de plusieurs couches. 
c'est pour cette raison que si tu utilises pas les bons termes, tu vas juste embrouiller les gens.

Et bien tu tiens un sacré plan alors ! 

t'es trop plan plan comme mec, ça doit être ça 

[TotOOntHeMooN]

Pourquoi remplaces-tu le terme "plan" par "couche" dans tes citations, si tu dis qu'un plan est composé de couches ? Et pourquoi personne d'autre que toi ne porte parle de couches ?

[dlfrsilver]

Pourquoi remplaces-tu le terme "plan" par "couche" dans tes citations, si tu dis qu'un plan est composé de couches ? Et pourquoi personne d'autre que toi ne porte parle de couches ?

Parce que plan en informatique se dit "plane". Sur Amiga quand on parle de bitplan, un anglais va parler de "bitplanes". un jeu en 5bpp sur amiga soit 32 couleurs, ça veut dire qu'il y a "5 bitplanes" soit 5 plans de bits.

Idem sur X68000, une layer (couche) en 8bpp, c'est 8 plans de bits, 8 plans de bits pour 1 Layer/couche ! 

Tu vois le cafouillage ? dire plan au lieu de calque ou couche ça induit les gens en erreur.  

Sur CPS1 on parle de layers pour les décors, c'est à dire de couches graphiques de tuiles indépendantes. 

Les concepteur du sharp décrivent dans le manuel de la machine les couches ou layers en anglais. Ils ne parlent pas de plans !

A défaut de couche, t'en tiens une bonne 

[Zarnal]

Pourquoi remplaces-tu le terme "plan" par "couche" dans tes citations, si tu dis qu'un plan est composé de couches ? Et pourquoi personne d'autre que toi ne porte parle de couches ?

Parce que plan en informatique se dit "plane". Sur Amiga quand on parle de bitplan, un anglais va parler de "bitplanes". un jeu en 5bpp sur amiga soit 32 couleurs, ça veut dire qu'il y a "5 bitplanes" soit 5 plans de bits.

Idem sur X68000, une layer (couche) en 8bpp, c'est 8 plans de bits, 8 plans de bits pour 1 Layer/couche ! 

Tu vois le cafouillage ? dire plan au lieu de calque ou couche ça induit les gens en erreur.  

Sur CPS1 on parle de layers pour les décors, c'est à dire de couches graphiques de tuiles indépendantes. 

Les concepteur du sharp décrivent dans le manuel de la machine les couches ou layers en anglais. Ils ne parlent pas de plans !

A défaut de couche, t'en tiens une bonne 

Tu planes ?  

Et  si j'organise en 3+2, j'ai toujours 5 bitplans mais plus 32 couleurs...

--->

[TotOOntHeMooN]

Parce que plan en informatique se dit "plane". Sur Amiga quand on parle de bitplan, un anglais va parler de "bitplanes". un jeu en 5bpp sur amiga soit 32 couleurs, ça veut dire qu'il y a "5 bitplanes" soit 5 plans de bits.

J'étais certain que tu avais fait l'analogie avec l'Amiga qui fonctionne avec 6 ou 8 plans de 1bit. Mais tu ne peux pas te permettre d'appliquer cela à une autre machine dont la structure mémoire est différente.

Idem sur X68000, une layer (couche) en 8bpp, c'est 8 plans de bits, 8 plans de bits pour 1 Layer/couche ! 
Tu vois le cafouillage ? dire plan au lieu de calque ou couche ça induit les gens en erreur.  

Tu mélanges les technologies et tu t'induis tout seul en erreur. Voici d'ailleurs ce que dit le Wikipedia japonnais du X68000, où le terme plan est utilisé et non le terme couche/layer :

"In addition, it was possible to have a maximum of 4 planes (512x512 dots for 16 colours) on the graphic screen alone. In 16-colour mode, 1,024 x 1,024 dots, 1 plane or 512 x 512 dots, 4 planes, in 256-colour mode, 512 x 512 dots, 2 planes, and in 65,536 colour mode, 512 x 512 dots, 1 plane. In addition to being able to display, there was a translucent function. In addition, spherical scrolling in which the top, bottom, left, and right are connected independently is possible."

Reprenons depuis le début...

Quelle est la différence entre :
1-bit plane
1-bit layer
1-bit map

Tu as 4 heures.

[upsilandre]

J'ai longuement fait mumuse avec l'émulateur, le debug et une quinzaine de jeux et j'ai enfin toutes les réponses a mes questions (depuis le temps, j'arrivais jamais a trouver des informations claire et pas contradictoire sur le web).
Je comprend bien mieux les tenant et aboutissant, ca fiat plaisir, et c'est assez différent de ce qu'on comprend en lisant les specs sur internet qui sont souvent incomplète voir erroné. Il y a pas mal de chose plus positive que je ne pensais et d'autre moins et assez surprenante.
TotOOntHeMooN je te fais un debrief plus tard la j'ai un truc a faire. Je pense que ca va t'intéresser.

[TotOOntHeMooN]

J'ai bien pensé que tu regardais sagement de ton coté. Souvent les specs "internet" sont le fait de constatations visuelles et d'interprétations erronées, aussi j'attend avec impatience tes découvertes !

[upsilandre]

Bon aller je suis chaud bouillant la, c'est partie  

Je suis plutôt d'accord avec TotOOntHeMoon. J'ai tendance a plutôt faire la distinction entre les termes "plan" et "bitplan" qui ne sont pas la meme chose mais pour éviter toute confusion j'utiliserais pas du tout le terme plan et donc j'utiliserais uniquement "bitplan" et "layer".

Donc a priori dans le X68000 il y a plusieurs chip qui s'occupe de l'affichage mais en gros y a "Cynthia" qui est un peu la partie "console" de la machine (sans doute la que Hudson a participé si c'est le cas) et une autre partie plus "micro".


Je commence par la partie "console" avec Cynthia.
Cynthia s'occupe donc du "Sprite layer". 128 sprites 4 bpp 16x16 pixels, max 32 sprites sur la meme scanline. Il y a apparemment une SAT de 16 Ko interne a Cynthia + une VRAM de 32 Ko dédié a Cynthia qui va donc pouvoir contenir le tileset des sprites (256 tiles 16x16)
Cynthia s'occupe aussi des 2 layers de background au format tilemap si pratique pour les jeux a scrolling et qui ici sont communément appelé "BG layers". On va donc garder cette appellation. Et contrairement a ce que j'ai souvent lu c'est bien 2 layers 512x512 voir même 1024x1024 quand tu choisie le mode tiles 16x16 (car tu peux choisir entre 8x8 et 16x16). Donc la bonne nouvelle c'est qu'il y a bien 2 layers 512x512 (indispensable pour le scrolling) et pas un seul comme on lit parfois mais la grosse surprise elle vient maintenant: Tout le tileset de de ces 2 BG layers ainsi que les tilemap (qui font chacune 8 Ko en full usage) doivent aussi être contenu dans les même 32 Ko de VRAM utilisé par les sprite et ca je l'ai pas vu venir!
Pour résumé Cynthia c'est en gros l'équivalent d'une Supergrafx (2 BG layers, 128 sprites, 32 max par scanline...) mais avec seulement 32 Ko de VRAM! (128 Ko dans la SGX). Si tu utilise complètement ces 2 BG layers il te reste en gros 8 Ko pout le tileset sprite et 8 ko pour le tileset des 2 BG. Je vous laisse imaginer la galère (meme si le X68000 a de grosse capacité DMA pour la gestion dynamique des sprites).
Le résultat c'est que ces 2 BG layers ne sont quasiment jamais utilisé a cause de ca car les 32 Ko c'est déjà léger rien que pour les sprites. Et d'ailleurs dans l'usage courant (dans l'émulateur ou dans les docs) le chip Cynthia est souvent résumé a sa fonction Sprite layer, c'est souvent comme ca qu'est nommé le chip en occultant les BG layers donc c'est plutôt comme ca qu'il faut le considérer.
En testant les jeux j'ai moi même eu du mal au départ a comprendre pourquoi ils utilisaient pas ces layers tilemap (BG layers) plutôt que les layers bitmap car c'est quand même plus économique en ressource pour faire du scrolling. Et la réponse c'est ca, y trop peu de VRAM dédié a ca (moi je croyais que les BG layer était dans la VRAM 512 ko). C'est quand même utilisé parfois dans certains jeux. Notamment ca a l'air nécessaire quand on veut faire un effet de transparence, ce type d'effet a l'aire de se faire uniquement entre la couche "micro" et la couche "console" (donc entre Graphics layers et BG layers).
Du coté palette Cynthia a ses 16 palettes 256 couleurs qui sont partagé a la fois avec le Sprite layer et aussi les 2 BG layers qui utilisent donc tous les même 16 palettes.


Dans la partie "micro" y a les "Graphics layers" qui sont donc des layers purement bitmap. La y a en gros 4 possibilités:
-- Soit 1 graphic layer 512x512 en direct color 16bit (donc 65535 couleurs) par vraiment utiliser dans les jeux a part sur des écrans titres.
-- Soit 2 graphics layers 512x512 en clut 8bit donc 256 couleurs 16bit mais la meme palette 256 couleurs pour les 2 layers. Le mode couramment utiliser dans les jeux.
-- Soit 4 graphics layers 512x512 en clut 4bit donc 16 couleurs 16bit mais attention car les 4 layers partage la même palette 16 couleurs (la palette 0) donc difficile a exploiter dans les jeux.
-- Soit 1 graphic layer 1024x1024 en clut 4bit (ca j'imagine c'est pour la hires)
Tout ces layers ont un scrolling hardware donc jusque 4 scrolling hardware pour cette partie Graphics layers.
Et toute cette partie "Graphics layers" a sa VRAM dédié de 512Ko et n'est pas partagé avec autre chose (donc on peut oublier les histoires de conflit et de partage de place avec les tilemap et tileset de Cynthia qui me préoccupait. On peut donc utiliser tous les Graphics layer en même temps que les BG layers).
Et ces grahics layers sont totalement chunky, c'est pas du bitplan. L'astuce c'est que ces 512Ko de VRAM sont couvert par un mapping miroir étalé sur 2Mo et selon par quel adresse on accède a un word de la VRAM physique la controleur va comprendre si on veut acceder au word entier (mode 16bit) ou juste au 8bit LSB ou MSB, ou juste a un paquet 4bit dans ce word. Mais retenez que c'est pas du bitplan, c'est important pour la suite.
Et le fait que ce soit du bitmap chunky et qu'il y a l'air d'y avoir pas mal de fonction DMA alors les Graphics layers peuvent être utilisé aussi pour du sprite software, certain jeux le font.


Ensuite dans cette partie "micro" de l'affichage y a aussi le "Text layer" qui est souvent oublié dans les specs alors qu'il n'est pas négligeable et qu'il est quasiment tout le temps utilisé dans les jeux.
En réalité c'est juste un autre layer bitmap 4 bpp 1024x1024 avec ses propre 512 Ko de VRAM (rien que pour ca c'est pas du tout négligeable) et son propre scrolling hardware donc ca ressemble beaucoup aux Graphic layer vu au dessus qui peut lui aussi se configurer en bitmap 1024x1024 4 bpp exactement comme ce Text layer donc c'est quoi la différence?
Et bien cette fois c'est un vrai layer en bitplan! Et c'est pour cette raison qu'ils le nomment "Text layer" c'est que tu peux utiliser ce layer comme 4 layers monochromes en utilisant chaque bitplan individuellement (sauf qu'évidemment dans ce cas ils n'ont pas de scrolling individuel, y a un seul scrolling pour le layer 4 bpp complet).
Dans les jeux il va juste être utilisé comme un autre layer graphic 4 bpp classique. Mais comme c'est seulement du 4 bpp et en plus en bitplan c'est moins pratique pour les jeux donc son usage est secondaire mais quand meme plus souvent que les BG layers (et y a sans doute certain effet qui peuvent profiter de cette configuration bitmap bitplan donc c'est cool qu'il existe).
Ce layer utilise uniquement la palette 0 du pool de 16 palettes utilisé par Cynthia (donc pas la même palette 16 couleurs que les Graphics layers 4 bpp)


Donc pour résumer .
-- On peut avoir jusqu'a 7 layers de background (sans compter le Sprite layer) avec chacun son scrolling hardware ce qui est assez impressionnant mais dans ce cas la on a donc 5 layers en 16 couleurs (dont 4 partages la même palette ce qui rend ca peut exploitable) et 2 layers en 16x16 couleurs (mais avec quasiment pas de VRAM)
-- On peut avoir jusqu'a 5 layers 256 couleurs quand on combine 2 graphics layers (256 couleurs), 2 BG layers (16x16 couleurs) et 1 sprite layers (16x16 couleurs)
-- L'usage courant dans les jeux c'est d'utiliser 2 Graphics layers 256 couleurs pour les background, le Text layer pour le HUD (qui a donc un peu la même fonction que le 3ème layers de la SNES) et d'utiliser seulement le Sprite layer de Cynthia (pas les BG layers)
-- Du coté palettes au total y a 512 couleurs 16bit (c'est donc le max affichable sans raster et sans utiliser le mode direct color) divisé en 2 pools de 256 couleurs. Un réservé et partagé pour tous les Graphics layers et l'autre réservé et partagé pour tous les layers Cynthia (Sprite layer et BG layers) et le Text layer.


Je reviendrais plus tard pour le cas concret des jeux comme Castlevania puisqu'on se posait la question (et j'ai des screenshot) mais la je commence a fatiguer   .

[TotOOntHeMooN]

Merci d'avoir pris le temps de toutes ces explications. 

En préambule :

- On peut imaginer qu'une version console avec Cyntia aurait pu être intéressante avec 64K ou 128K de VRAM si Hudson avait fait une "SuperGrafx" avec un 68000 chez SHARP plutôt que rester faire du bricolage chez NEC.

- Peut-on imaginer que Hudson qui a fait l'OS de cette machine ait fournis ce circuit qu'ils avaient sous le coude pour lui permettre d'avoir des sprites pour le coté "jeu" de la machine ? (sans quoi ça serait un micro-ordinateur plus classique). Car je ne crois pas que Cyntia ait été conçu pour le X68000, vu l'usage qu'il en est fait.

Alors...

La VRAM sur X68000 est composée de deux banques de 512K. Chaque banque dispose de 16 circuits de 65536 mots de 4bit. Aussi, en fonction de la configuration de l'adressage de cette mémoire, il est possible de l'utiliser en 16x 4bit (indivisible), 8x "2x4bit" et 4x "4x4bit". Il est ainsi possible d'avoir des plans de 4bit, 8bit ou 16bit par pixels pour définir la profondeur des couleurs de l'image (apparemment juste en 4bit pour la banque mémoire du mode texte donc).

On comprend mieux pourquoi le X68000 est principalement utilisé dans les conversions d'arcade sous la configuration scores, sprites, avant plan, arrière plan. C'est déjà énorme car on dispose de tout ce qu'il faut pour afficher des jeux magnifiques... A condition donc de programmer soi même le tilemap.

Mais ce qui me dérange le plus est quand même la résolution. 256 pixels de large en plein écran c'est peut quand les portages CPS1 voir même R-Type sont à l'origine de 384 pixels de larges... Et même si une telle résolution est affichable, elle se fait sur un écran haute résolution de 512 de large avec des bordures dignes d'un CPC. :)

[upsilandre]

- On peut imaginer qu'une version console avec Cyntia aurait pu être intéressante avec 64K ou 128K de VRAM si Hudson avait fait une "SuperGrafx" avec un 68000 chez SHARP plutôt que rester faire du bricolage chez NEC.

- Peut-on imaginer que Hudson qui a fait l'OS de cette machine ait fournis ce circuit qu'ils avaient sous le coude pour lui permettre d'avoir des sprites pour le coté "jeu" de la machine ? (sans quoi ça serait un micro-ordinateur plus classique). Car je ne crois pas que Cyntia ait été conçu pour le X68000, vu l'usage qu'il en est fait.

Oui ca me parait des hypothèses assez plausible. Mais bon j'ai l'impression qu'on connaitra jamais l'histoire  

La VRAM sur X68000 est composée de deux banques de 512K. Chaque banque dispose de 16 circuits de 65536 mots de 4bit. Aussi, en fonction de la configuration de l'adressage de cette mémoire, il est possible de l'utiliser en 16x 4bit (indivisible), 8x "2x4bit" et 4x "4x4bit". Il est ainsi possible d'avoir des plans de 4bit, 8bit ou 16bit par pixels pour définir la profondeur des couleurs de l'image (apparemment juste en 4bit pour la banque mémoire du mode texte donc). Contrairement aux 32K de mémoire de Cyntia qui sont eux configurés en 32 circuits de 1024 mots de 1bit.

Oui c'est un truc comme ca. Ce que je peux dire c'est que la VRAM des graphics layer est configuré tel que par exemple quand t'es en mode graphic layer 4 bpp 1024x1024 le mapping mémoire du layer s'étale sur 2 Mo d'adressage (alors que physiquement il prend que 512Ko) et donc tu accèdes individuellement a chaque pixel 4bpp par un accès 16bit complet a la VRAM (pour un seul pixel 4 bit). Du coup que le layer soit 16bit, 8bit ou 4bit, il t'apparait toujours comme un buffer chunky avec les pixels les un a coté des autres dans le mapping mémoire (apres chunky je sais pas si c'est le bon terme vu qu'il y a que 4bit utilisé sur 16 mais on se comprend ^^ en tout cas c'est un acces VRAM = un pixel). Par contre j'ai l'impression du coup que du point vu du dev pour écrire un pixel ca se fait donc toujours avec un accès 16bit même pour un pixel 8 bit ou 4 bit et peut etre même pour le DMA? du coup ca peut être assez lent sur les layer 4 bpp (raison de plus de pas les utiliser vu deja les contrainte de palette et y a le Text layer qui fait mieux le job). Du point de vu de la partie "DAC" des accès a la VRAM j'imagine que c'est différent, ca change rien que ce soit en 4bit, 8bit ou 16bit, il doit accéder toujours en full bus et faire sa tambouille de son coté.

La VRAM du Text layer est plus classique dans son mapping. Tu accèdes classiquement mot par mot (16bit par 16bit) sauf que chaque mot couvre 16 pixels puisque le layer est rangé en bitplan dedans. Donc très diffèrent du cas des Graphic layers meme ceux en 4bit.

Mais ce qui me dérange le plus est quand même la résolution. 256 pixels de large en plein écran c'est peut quand les portages CPS1 voir même R-Type sont à l'origine de 384 pixels de larges... Et même si une telle résolution est affichable, elle se fait sur un écran haute résolution de 512 de large avec des bordures dignes d'un CPC. :)

C'est vrai qu'on retrouve pas mal de jeux CPS ou IREM avec R-Type qui ont un pixel ratio bien particulier et qu'on ne peut pas retrouver ici. Finalement c'est presque la PCE la machine qui se rapproche le plus de ce pixel ratio

On comprend mieux pourquoi le X68000 est principalement utilisé dans les conversions d'arcade sous la configuration scores, sprites, avant plan, arrière plan. C'est déjà énorme car on dispose de tout ce qu'il faut pour afficher des jeux magnifiques... A condition donc de programmer soi même le tilemap.

C'est claire que du coup faut programmer les tilemap en software, c'est ce qui m'a surpris au départ, que les devs s'impose ca, je comprenais pas pourquoi alors qu'il y a les BG layer mais maintenant je comprend pourquoi. C'est juste la meilleur alternative. Y a pas trop le choix. Mais oui franchement y a de quoi faire meme en zappant les BG layers. Et ils sont quand même utilisé parfois.
Malheureusement la j'ai plus le temps de parler des jeux (avec les screenshot debug), je ferais ca demain :)

[TotOOntHeMooN]

Désolé de t'avoir "coupé la chique". Il se fait tard et j'ai peut de batterie...
En gros je pense que l'adressage est sur 4 zones de 512K pour permettre cela :

Code:

---------------- ---------------- ---------------- ----------------
4444444444444444
2 2 2 2 2 2 2 2  2 2 2 2 2 2 2 2
1   1   1   1    1   1   1   1    1   1   1   1    1   1   1   1  

A demain.

[upsilandre]

Désolé de t'avoir "coupé la chique". Il se fait tard et j'ai peut de batterie...
En gros je pense que l'adressage est sur 4 zones de 512K pour permettre cela :

Code:

---------------- ---------------- ---------------- ----------------
4444444444444444
2 2 2 2 2 2 2 2   2 2 2 2 2 2 2 2
1   1   1   1     1   1   1   1     1   1   1   1     1   1   1   1  

A demain.

Oui c'est ca :) (j'ai corrigé un peu l'alignement)

[upsilandre]

Donc pour les jeux l'usage classique (notamment les jeux CPS) c'est les 2 graphics layers 8 bpp et le Text layer pour le HUD
Ce qui est marrant c'est qu'au final l'usage courent du X68000 est exactement l'inverse du CPS. Les 2 ont en gros 5 layers mais la ou le CPS va juste utiliser ses 3 layers tilemap et quasi jamais ses 2 layers bitmap le X68000 va utiliser plutot ces 3 layers bitmap et quasi jamais ses 2 layers tilemap.






Le plus intéressant c'est quand meme Castlevania qui fait un usage assez riche et varié des différents layers.
Donc tu peux avoir un usage classique comme sur les jeux CPS:



Mais en général le Text layer est utilisé a fond, pas juste pour le HUD mais pour ajouté aussi un autre plan (en passant par un raster, quite meme a changer la palette du Text layer au raster car celui ci est limité a une seul palette 16 couleur)
Ici la lune fait partie du Texte layer (avec le HUD)



Et ici le Text layer sert de vrai background pour remplacer le graphic layer 8 bpp qui sert ici de sprite pour faire un effet de rotation sur l'arbre qui tombe



Mais toujours pas d'usage des BG layers. Ca vient.
Venons en au passage de la grotte qui nous intriguait. Evidement j'avais tout faux puisque je pensais que le premier plan était en toute logique le BG layer (a l'époque ou je pensais qu'il n'y en avait qu'un en 512x512 et pas de probleme de quantité de VRAM) et que les 3 autres c'était des graphics layers 4 bpp (a l'époque ou je ne savais pas qu'ils partageaient tous la meme palette 16 couleurs)
Au final le premier plan est un graphics layers 8 bpp, les 2 suivants sont les BG layers (enfin) et le dernier est le Text layer encore judicieusement utilisé. Mais du coup sur les 32 Ko de Cynthia y a 10Ko de tilemap, 8Ko de tilset BG et il ne reste donc que 14 Ko pour les sprites, c'est chaud.



Au tout début du jeu quand on fait un petit passage au dessus des douves le décors switch en mode dual BG layers plutot que dual Graphics layers. A priori ca doit etre pour faire l'effet de transparence avec l'eau (qui est dans le graphic layer). J'ai l'impression que l'inverse n'est pas possible (une transparence du BG layer vers le graphic layer)



Et la scène du début dans le chateau est au final celle qui utilise le plus de layer. Ils y sont tout les 5. Les 2 Graphic layers pour le background, un BG layer pour les rideaux (ca permet de les placer ou l'on veut et de carrer les symétries) l'autre BG layer pour les fenetres (ca je ne sais pas pourquoi) et le Text layer pour l'arrière plan et le HUD.




Maintenant le cas Baruusa No Fukushuu que j'avais mis en vidéo.
La dessus on était plutôt bon puisqu'il fait partie des rare jeu qui utilise le mode 4 graphics layer 4bpp sauf que comme j'ai expliqué les 4 layers partagent la meme palette 16 couleurs! (la palette 0) et on le constate bien ici (ce qui donne un visuel assez pauvre)
En plus de ca le jeu utilise aussi un BG layer et meme le Text layer (encore pour le HUD) donc 6 layers! (sans compter le sprite layer). Mais c'est pas vraiment une bonne idée je pense.




R-Type utilise beaucoup aussi le Text layer comme second layer de background plutot que d'utiliser un Graphic layer ou BG layer.





Cynthia un petit shmup qui utilise massivement les 1024x1024 du Text layer pour stocker les frame d'animation de la smart bombe (11 screens)




Afterburner qui nous accueil avec un petit screen en direct color 16bit



Un Graphic layer utilisé pour les sprite software (les avions, meme celui du joueur) un peu comme pour Space Harrier, l'autre Graphic layer pour la ligne d'horizon. un BG layer utilisé pour le HUD, l'autre pour les FX de fumé. Les sprites utilisé pour les motif au sol




La demo de vector ball qui est une occasion de voir quasiment tous les sprites a l'écran, du coup ils ont meme du réduire un peu la grille    (11x11 au lieu de 12x12)



Bon voila je m'arrête la.

[TotOOntHeMooN]

Merci, tu as eu beaucoup de courage de faire cela ! 

Pas trop de miracles avec ces 32K déjà limites pour la quantité de sprites (256), il faut composer avec les moyens du bord qui fort heureusement sont nombreux. C'est quand même vraiment dommage cette limitation à la palette 0 pour afficher en "4x 4bit", quand ils auraient certainement pu arbitrairement fixer les palettes 0,1,2,3 pour cet usage. Ca reste une sacré machine quoi qu'il en soit ! Mais pourquoi pas de version console... Hudson, qu'est-ce que t'as foutu avec la SGX !!! 

[upsilandre]

C'est quand même vraiment dommage cette limitation à la palette 0 pour afficher en "4x 4bit", quand ils auraient certainement pu arbitrairement fixer les palettes 0,1,2,3 pour cet usage. Mais ça reste une sacré machine quoi qu'il en soit !

Oui ca ca fait partie des choses qui m'ont surprit négativement. Je ne m'y attendais pas (et les autres layers on peut de liberté aussi, chaque pool graphique a son set de 256 couleurs sans pouvoir aller piocher dans celle de l'autre). Ca rend ce mode quad layers 4bpp sans grand intérêt pour les jeux.
Les bonnes surprise c'est le Text layer dont on parle jamais mais qui dépanne bien (et qui a 512 Ko rien qu'a lui, tu peux y stocker pas mal de truc) et puis qu'on peut utiliser les 2 graphic layers 8bpp en meme temps que les BG layer vu que les 512ko leur sont entièrement dédié.

[upsilandre]

Du coup j’ai relu la fiche wiki posté par dlfrsilver, c'est la qu'on voit qu'il y a pas mal de truc assez faux

Graphical planes: 1-4 bitmap planes, 1-2 tilemap planes, 1 sprite plane[5][6]

Pas très juste car ca oublie encore une fois le Text layer qui fait tout autant partie des "Graphical planes" que les autres malgré son appellation et c'est bien comme ca qu'il est utilisé dans les jeux.

plans Bitmap [1][5]
1 couche: 512×512 resolution @ 65,536 colors on screen, or 1024×1024 resolution @ 64 colors on screen (out of 65,536 color palette)

Pour le layer 1024x1024 c'est 16 couleurs

2 couches: 512×512 resolution @ 256 colors à l'écran par couche (512 colors combinées) (out of 65,536 color palette)

=> ceci est le mode utilisé par la plupart des jeux 2 couches en 512x512 avec 256 couleurs dans chaque soit 512 couleurs combinées

Les 2 layers partagent la meme palette de 256 couleurs donc ce n'est pas 512 au total mais 256.

4 couches: 512×512 resolution @ 16 colors à l'écran par couche (64 colors combinées) (out of 65,536 color palette)

=> pas utilisé, ni dans akumajo ni dans aucun jeu converti du CPS1 de capcom

Les 4 layers partage la meme palette 16 couleurs donc ca fait 16 couleurs au total pas 64 (utilisé dans Baruusa)

BG tilemap planes[5][6]

BG plane resolutions: 256×256 (2 layers) or 512×512 (1 layer)

C'est 2 layers 64x64 tiles qui donne 2 layers 512x512 (pas 1 seul) avec des tiles 8x8 ou 1024x1024 avec des tiles 16x16

BG chip/tile size: 8×8 or 16×16
Colors per BG layer: 256 (out of 65,536 color palette)
BG colors on screen: 256 (1 layer) or 512 (2 layers), out of 65,536 color palette

La aussi ils partagent les même palette donc c'est bien 256 au total meme avec 2 layers (et meme avec les sprite qui utilise les même palette)
C'est en additionnant les BG layer (ou sprite layer ou text layer) avec les Graphic layers qu'on atteint les 512 couleurs vu qu'ils utilisent un set de palettes différent

BG tiles on screen: 512 (16×16 tiles in 256×256 layers) to 4096 (8×8 tiles in 512×512 layer)

La je ne sais pas ce qu'ils veulent dire pour le nombre de tiles on screen mais c'est max 256 tiles différentes à l'écran car le format de tilemap utilise un pointeur de tile seulement 8bit (+4bit de palette et 2bit de flipping), et les 2 BG layers sont fixé sur les meme 8 premier Ko de VRAM quand c'est en mode tile 8x8 donc le meme set de 256 pour les 2 layers. Et c'est donc encore moins en mode tile 16x16 puisque les tilemap occupe alors une partie de l'espace tileset (ca donne 128 tiles max a l'écran si les 2 tilemap sont full)

La partie Cynthia est peu flexible avec beaucoup de chose qui semble très fixé.
Le fait que les sprites semble fixé au format 16x16 c'est un peu embêtant aussi je pense.

[TotOOntHeMooN]

Déjà sans appronfondir, il était possible de voir une poignée d'incohérences sur Wikipedia, ne serait-ce comparé à d'autre sites... Malheureusement, comme souvant quand on connait un sujet, on se rend compte que cette "encyclopédie" est litéralement truffée d'erreurs... Et ne dites pas qu'il suffit de corriger, car généralement tu as une personne derrière qui vient restaurer ce qui lui semble juste (dlfrsilver si tu nous écoute). Aussi je te souhaite bon courange si tu as l'ambition de t'atteler à cette tâche de Sisyphe.

Le plus incroyable c'est quand même ces 512K "dédiés" du mode texte, alors qu'il aurait certainement pu partager les 512K existants. J'imagine que cela est dû au fait de pouvoir monter en résolution dans ce mode ? D'ailleurs, quand on ajoute de la RAM d'extension sur cette machine, "qui" en profite (hors CPU) ?

Concernant la taille des sprites, c'est sur qu'il faut bien en avoir un total de 128 si seulement du 16x16 est permis, car c'est vite consommé à créer des metasprites. Mais là aussi la résolution de 256x256 fait que ça parrait suffisant et proche de la SNES.

Je pense qu'un hit vraiment taillé pour le X68000 aurait été Double Dragon.

[xinyingho]

Déjà sans appronfondir, il était possible de voir une poignée d'incohérences sur Wikipedia, ne serait-ce comparé à d'autre sites... Malheureusement, comme souvant quand on connait un sujet, on se rend compte que cette "encyclopédie" est litéralement truffée d'erreurs... Et ne dites pas qu'il suffit de corriger, car généralement tu as une personne derrière qui vient restaurer ce qui lui semble juste (dlfrsilver si tu nous écoute). Aussi je te souhaite bon courange si tu as l'ambition de t'atteler à cette tâche de Sisyphe.

Très intéressant vos échanges :)

En ce qui concerne Wikipédia, la partie anglaise est plus ou moins protégée par le fait que les grosses pages qui changaient tous les 4 matins sont modérés par des gens qui imposent des sources fiables. Mais du coup, sur des specs techniques comme ça, il n'y a pas de sources fiables, et donc tout le travail d'upsilandre sera considéré comme original et sans valeur par rapport à un autre contributeur. Comme il y a probablement aucune source fiable pour les specs d'un ordinateur obscur comme le X68K, aucune idée comment serait pris les corrections qu'apporterait upsilandre.

La partie française est plus relaxe par contre :)

[upsilandre]

Le plus incroyable c'est quand même ces 512K "dédiés" du mode texte, alors qu'il aurait certainement pu partager les 512K existants.

Le graphic layer utilise l'intégralité de cette RAM (par exemple quand tu utilise les 2 layers 512x512 8bpp ou le layer 16bpp) donc ca aurait été un peu embêtant meme si on utilise pas souvent les 512x512 des layers mais si tu fait du scrolling multidirectionnel t'as besoin de tout l'espace (ou alors il aurait fallu proposer des modes 512x256 a la limite).

J'imagine que cela est dû au fait de pouvoir monter en résolution dans ce mode ?

La VRAM du Text layer sert a avoir un buffer 1024x1024. Donc oui peut etre pour le mode hires.

D'ailleurs, quand on ajoute de la RAM d'extension sur cette machine, "qui" en profite (hors CPU) ?

A priori juste le CPU mais au final tout les graphisme sont dans cette RAM car le tileset de tes graphics layer tu les stock en RAM puisque tu utilise un systeme de tilemap software. Et tout ce qui concerne Cynthia y a tellement peu de place que tu dois sans doute passer ton temps a gérer l'espace VRAM de Cynthia de façon dynamique avec le DMA (notamment les sprites) donc en stockant tout en RAM.

Concernant la taille des sprites, c'est sur qu'il faut bien en avoir un total de 128 si seulement du 16x16 est permis, car c'est vite consommé à créer des metasprites. Mais là aussi la résolution de 256x256 fait que ça parait suffisant et proche de la SNES.

Le truc cool c'est les 512 pixel-sprite par scanline.

[TotOOntHeMooN]

La VRAM du Text layer sert a avoir un buffer 1024x1024. Donc oui peut etre pour le mode hires.

Oui, c'st plus pour un usage des logiciels "pro" j'imagine.

Et tout ce qui concerne Cynthia y a tellement peu de place que tu dois sans doute passer ton temps a gérer l'espace VRAM de Cynthia de façon dynamique avec le DMA (notamment les sprites) donc en stockant tout en RAM.

Ca doit-être le casse tête des programmeurs sur cette machine.

Le truc cool c'est les 512 pixel-sprite par scanline.

J'ai pensé à la même chose. (dommage qu'ils ne fassent pas 32 de haut :p)

[upsilandre]

En connaissant maintenant mieux la machine voir meme certain adressage j'ai pu feuilleter et déchiffrer un peu directement la documentation jap (notamment la partie Cynthia dont on trouve quasiment rien). Rien de vraiment neuf (juste des petits détails en plus ), ca confirme juste les infos que j'ai pu donnée.

Par contre j'ai decouvert que Cynthia n'est meme pas sur la board vidéo mais sur la main board donc il est vraiment isolé du reste (autant physiquement que dans ses fonctions)

La board vidéo avec ses 4 chip et ses 2 pool de 512Ko de VRAM


Et la main board avec Cynthia tout en haut



Cynthia ressemble vraiment a un chip Hudson Soft. Je pense de plus en plus que Hudson s'est fait la main sur ce chip (peut etre meme bien avant que le X68000 ne sorte, on ne sait pas quand Sharp les auraient contacté, d'ou peut etre le fait qu'il soit calibré uniquement pour du 32Ko, ou alors ils l'avait fait pour autre chose) et quand ils ont réalisé qu'ils avaient les compétences de faire leur propre console ils ont tracer leur propre route avec la PCE.

Et d’une certaine façon le X68000 me fait pensé au PC-FX. Il y a une partie "console" (sprite/tilemap) assez isolé (meme physiquement) et qui détonne  un peu avec le reste, qui ressemble a une pièce rapporté. Et autour de ca y a d'autre chip graphiques (sur la board vidéo a part) qui ajoute des layers bitmap de différentes sortes mais plus micro.
Dans le PC-FX la partie "console" de l'affichage c'est pour le coup réellement une SupergrafX  (donc très proche du Cynthia du X68000 mais 256 ko de VRAM et pas 32) et ailleurs d'autres chip vidéo qui ajoute des layers (bitmap, Jpeg) sauf que cette fois certains layers peuvent aussi fonctionner en tilemap, rendant encore plus superflu la partie console.

Dans les 2 machine la pièce rapporté "console" sert essentiellement pour les sprites

[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