La PC-Engine : vraie ou fausse 8 bits ?
+10
Joel ARRAULT
kawickboy
guyome
môa
Seb25
shubibiman
ryosaeba
Chô Aniki
drfloyd
elodiebo
14 participants
GAMOPAT :: LES PATHOLOGIES CONSOLO-VIDEOLUDIQUES :: LE SYNDROME 8BIT D'EXCITATION GENITALE PERSISTANTE
Page 6 sur 6
Page 6 sur 6 • 1, 2, 3, 4, 5, 6
Re: La PC-Engine : vraie ou fausse 8 bits ?
[HS]
D'un autre côté elle a été conçu pour des jeux en 3D mappés mais c'est quand même dommage...
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.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'.
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 : 2589
Date d'inscription : 25/03/2009
Re: La PC-Engine : vraie ou fausse 8 bits ?
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.
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.
Invité- Invité
Page 6 sur 6 • 1, 2, 3, 4, 5, 6
Sujets similaires
» Vraie ou fausse boite ?
» VRAIE OU FAUSSE BOITE GBA
» console 8 bits vs micro 8 bits
» [Estim] Vraie ou fausse boite gba ?
» [ESTIM] cartouches atari 8 bits, C64 et PC engine
» VRAIE OU FAUSSE BOITE GBA
» console 8 bits vs micro 8 bits
» [Estim] Vraie ou fausse boite gba ?
» [ESTIM] cartouches atari 8 bits, C64 et PC engine
GAMOPAT :: LES PATHOLOGIES CONSOLO-VIDEOLUDIQUES :: LE SYNDROME 8BIT D'EXCITATION GENITALE PERSISTANTE
Page 6 sur 6
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum