GAMOPAT
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.

La PC-Engine : vraie ou fausse 8 bits ?

+10
Joel ARRAULT
kawickboy
guyome
môa
Seb25
shubibiman
ryosaeba
Chô Aniki
drfloyd
elodiebo
14 participants

Page 6 sur 6 Précédent  1, 2, 3, 4, 5, 6

Aller en bas

La PC-Engine : vraie ou fausse 8 bits ? - Page 6 Empty Re: La PC-Engine : vraie ou fausse 8 bits ?

Message par oiseau de proie Mer 23 Sep 2009 - 1:24

[HS]
Archimedes a écrit:Je ne veux pas m'avancer mais j'imagine que la 3DO ne connait que le 'chunky' et pas le 'bit plane'.
Il est dur d'avoir de vraies infos sur cette console (enfin du moins à une époque où j'en cherchais) mais ton hypothèse est intéressante. Il faut une grosse puissance sous le capot pour faire des scrolls diff avec un affichage chunky. Or si elle ne gère pas d'affichage planar et encore moins de dual playfield cela pourrait expliquer cette absence dans SFII ou le manque de fluidité pour les jeux qui utilisent cette technique comme GEX.
D'un autre côté elle a été conçu pour des jeux en 3D mappés mais c'est quand même dommage...

oiseau de proie
Guéri miraculeux

Nombre de messages : 2588
Date d'inscription : 25/03/2009

Revenir en haut Aller en bas

La PC-Engine : vraie ou fausse 8 bits ? - Page 6 Empty Re: La PC-Engine : vraie ou fausse 8 bits ?

Message par Invité Mer 23 Sep 2009 - 8:43

Oui.

Je dis ça car c'est tout le problème sur l'Archimedes également, qui n'a que le chunky.
Après il faut passer à la création de code généré, ce que j'ai fait, mais c'est quand même assez lourd.

Pour info : code généré : on génère le code assembleur qui va directement afficher un sprite, exactement ce que le processeur devrait exécuter comme instructions.
Ca évite toutes les étapes de chargement du fond de l'écran, de le 'trouer' avec le mask, pour ORRer le résultat 'troué' avec le sprite pour finalement stocker le résultat à l'écran.

C'est aussi bien plus rapide que le chargement octet par octet du sprite, la comparaison avec 0 (couleur de la zone à ne pa afficher du sprite), pour ne stocker que le non 0 à l'écran.
(L'architecture de l'ARM2 ou l'ARM3 de l'Archimedes (mais aussi de l'ARM6 de la 3DO) fait que le chargement / écriture d'un octet prend le même temps que pour 4, donc cette méthode octet par octet est à fuir.
Dans le code généré on privilégiera évidemment les instructions de chargement/déchargement par 4 octets autant que possible).

Avec le code généré, on finit avec des tables de pointeurs sur les routines d'affichage correspondant à chaque sprite, et on les appelle avec un GO SUB, en passant le x,y d'affichage.

Ca marche d'enfer, aussi bien pour du sprite vrai que pour du décor de fond qui doit scroller.
Et ça permet d'être dans la VBL là ou les autres sont en 2.
Mais ça prend beaucoup plus de place mémoire.
avatar
Invité
Invité


Revenir en haut Aller en bas

Page 6 sur 6 Précédent  1, 2, 3, 4, 5, 6

Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum