Bon suite au sujet sur les portages de graph en mode1, j'ouvre ce sujet (Merci Hermol de déplacer ou renommer si tu le souhaite...)
HATE.
un superbe jeux en isométrique par Costa Panayi...
Auteur aussi de Deflektor, Revolution, Alien highway/Highway Encounter et autres, Co-fondateur de Vortex software et à la base ingénieur en mécanique...
Ce qui explique sont intérêt pour l'isométrique et le fait qu'il fut un peu un précurseur en la matière sur les ordis 8bit anglais.
Note : La page de "HATE" sur CPCpowers est mal remplis, costa PANAYI y est nommé "PANAVI" (ce qui chie les liens) et il n'est pas fait mention de Vortex software.
bon, le jeux est un co-dévelopement Speccy-CPC (plutot tendance Speccy hélas).
La musique est l'une des plus mémorables, merci mister DAGLISH...
c'est un portage fidèle et un peu amélioré de la version spectrum, mais aussi un poil plus lente.
Enfin si le cadre du jeux est plus large et plus ouvragé que sur Speccy, et inclus bien les 4 couleurs, la zone de jeux est elle en 2 couleurs...
Topic sur CPC wiki :
http://www.cpcwiki.eu/forum/games/h-a-t ... arning%29/
en regardant rapidement sous winape le jeux en RAM...
=une police de caractères (lettres et chiffres) est en Mode1 natif (2bpp)
=les tuiles de la zone de jeux sont en "mode2" donc encodé en spectrum/1bpp.
=les Sprites sont en 1bpp et masqués en 1bpp, ce qui fait que les sprites font en fait 2bpp (sort of).
=le décors utilise en fait assez peu de tuiles... et est aussi en 1bpp.
=il y a des ombres pour la plupart des sprites, ce qui est fait par un "masque" en 1bpp s'appliquant sur le background.
=le HUD et cadres hors zone de jeux, ça ne bouge pas vraiment donc doit simplement rester dans la VRAM en 2bpp je pense...
Clairement ça fait pas mal de Datas et de trucs a processer pour le CPU.
le scrolling semble relativement smooth.
Les sprites existent tous en 4 frames, avec en général un décalage latéral (voire diagonal, à vérifier) de 2 pixels en horizontal (et je ne sais pas en vertical, peut être 1 pixel) ce qui prend de la place en RAM mais semble plus simple/designed pour gérer le scrolling diagonale/isométrique.
Et la plupart de ces sprites sont animés (genre dessin animé) donc devaient avoir plusieurs frames d'animation de toute manière.
Je ne sais pas trop comment est généré le scrolling des tuiles de background car je n'ai pas trouvé de versions multiples avec décalage pré-encodé.
Bon.
un jeux mode1 n'utilisant que 2 couleurs pour les Sprites et les tuiles, c'est clair que c'est frustrant et renvoi au pire du speccy port.
Au moins on se dit que les sprites auraient peut être pu avoir un système d'attribution de couleur et donc avoir une autre couleur que le background...
le jeux est un portage du Spectrum48... mais possède plus de musique "in-game" me semble-t'il, il se peut que le CPCx64 soit un peu limité en RAM de toute manière vu les truc en plus nécessaires pour émuler le spectrum, et vu la Zique en plus.
Mockups :
j'ai fait des essais divers... et du ripp de graphismes.
une version en taille réelle est dispo ici :
http://cpcwiki.eu/imgs/7/7c/Hate_cpcmap_redone10.png
donc là l'idée est de recolorer proprement les tuiles de background (le décors) en 2bpp donc vraiment 4 couleurs.
les trames font que l'on ajoute en fait des tuiles en plus, ce qui peut être assez lourd aussi.
Et oui, le décors reste en fait en 3 couleurs finalement pour le moment...
Ce n'était qu'un mockup pour voir comment ça aurait pu rendre simplement sans contrainte par case et avec un usage de trames pour mixer avec du noir et du blanc et donc avoir des variation de teinte assez basiques.
(Et les sprites utilisant aussi des couleurs autres que la couleur principale du background)
le verdict est sans appel.
Mais le jeux aurait il assez de CPU pour gérer ça comme il faut ?
(= pas trop lent non plus)
les tuiles :
l'image est en version magnifié afin d'être utilisable avec tilestudio...
il faut noter que c'est inversé au niveau de l'axe Y... il faut faire un flip vertical pour les avoir comme il faut.
enfin les sprites...
ouch, je sais.
le set de characters (l'alphabet...)
les masques, les sprites, puis les sprites masqués en 2bpp... rippé depuis winape...
Ombres :
ça fait beaucoup de tuiles d'ombres aussi.
comme il s'agit de masques 1bpp... ça peut être une couche en plus a gérer en plus des sprites...
Donc :
=couche inférieur : les tuiles de background, qui sont scrollées "normalement".
=couche du milieux : les ombres, qui sont un masque que l'on applique sur les couches tuiles. leur scrolling se fait en multipliant pas 4 le nombre de tuiles d'ombre avec des frames d'animation donc (décalage de 2 pixels horizontal par frame, et peut être du décalage vertical aussi, à vérifier)
=couche supérieur : les sprites, qui sont masqués (2x1bpp donc) et sont affichés par dessus les tuiles de background et les ombres.
le truc c'est que les sprites peuvent avoir une coordonnée verticale variable (la hauteur/altitude) que l'on peut alors juger en fonction de l'ombre justement qui indique les coordonnées 2D sur le sol.
Ensuite, les ombres suivent la "pente" du sol, ce qui explique qu'il y ait autant de tuiles d'ombres...
en comptant vaguement j'arrive donc à :
(en tuiles e 8x8 pixels)
=72 tuiles de sol/background/décors (8x8x1bpp)
=318 tuiles d'ombre (8x8x1bpp... masque)
=424 tuiles de sprites et 424 tuiles de masque de sprites.
(424x 8x8x1bpp + 424x 8x8x1bpp = 856 tuiles de 8x8x1bpp)
Niveau technique, garder cela simplement à du full 1bpp, et du masque 1bpp... ça évite de multiplier les variantes de routines d'affichage, et garder ces datas en 1bpp évite qu'ils ne soient trop gros pour la contrainte des 64K du CPC464/664.
en effet les ombres n'ont pas lieux d'être générée autrement que par un masque en 1bpp...
et cumuler de l'affichage en masque 1bpp ET du masque en "une couleur sacrifiée sur du 2bpp" c'est peut être pas si simple en fait.
De même appliquer l'ombre sur du 1bpp natif (le background/décors) ou du du 2bpp (si ça avait été codé en CPC natif) ça peut être assez différent aussi.
Head over Heels qui utilise des graphismes en 2bpp... n'a pas d'ombre sous les sprites.
Ce qui par contre est assez gênant pour réussir a juger des coordonnées 3D des personnages.
Enfin, le décors est en fait l'élément comptant le moins de tuiles... donc le passer en 2bpp ne boost pas tant la place des Datas en RAM...
Citer :
72bytes x8rows = 576 bytes/octets... x2 in order to put them into 2bpp... 1152 bytes...
en gros, 72 tuiles... en 1bpp. une tuile faisant 8x8x1bpp pixels ça fait donc 72x8bits (largeur) x8(hauteur des tuiles) x2 (passage en 2bpp).
Soient à peu presque 1152octets.
Seulement voilà, les routines d'affichage comme la conversion du 1bpp de stockage en 2bpp d'affichage... il faut les changer, et donc probablement le système de masque, or ce système de masque1bpp est aussi utilisé pour les ombres... qui sont une feature qui doit rester.
Il peut être possible de garder le masque en 1bpp en plus des graphismes nativement en 2bpp pour les sprites.
l'avantage st alors de permettre l'usage effectif des 4 encres pour ces sprites.
Par contre ça peut aussi faire pas mal de bits à manipuler/déplacer en plus...
il faut donc voir avec l'avis de vrai codeurs et pas mes spéculations foireuses.
Le gros défaut du jeux est en fait que lorsque les Sprites sont affichés, et sont passé du 1bpp au 2bpp en "VRAM"... ils n'ont pas de colour swap.
le jeux aurait simplement tant bénéficié d'avoir une différenciation de couleur entre sprites et décors.
Passage en mode0 :
il est vrai que pour de l'isométrique, le mode 0 peut sembler aussi un truc super bien pratique et évident.
Bon en gros, je ne suis même pas persuadé que ça soit non plus si intéressant.
les graphismes mode1 de HATE sont excellents (juste pas assez colorés)
avoir des masques en 1bpp permet de donner u rendu type encrage de BD, avec de beau contours détaillés et fins.
De plus il n'y a pas de des lignes diagonales en 2x1... il u a aussi des lignes verticales et diagonales 1x1... et là le mode0 peut être plus brouillon.
De plus utiliser de la trame fine au lieux de simplement d'autres couleurs, c'est un rendu aussi très intéressant je trouve.
Et le but est aussi de montrer que le Mode1 n'est pas réduit a du mauvais portage graphique Spectrum et peut se montrer supérieur malgré qu'il n'y ai que 4 couleurs à l'écran, notamment pour ce type de jeux.
Enfin rester en Mode1 permet plus de palette swap je trouve car alors les dégradés sont généré en trames... il y a plus de combinaisons que si on utilise directement des dégradés sur 3 teintes existant dans la palette CPC, ces derniers étant en plus parfois limités aussi en contrastes (jaune, vert... les 2 teintes claires sont assez/trop identiques).
Comme d'habitude, refaire le tileset en 2bpp bien coloré n'est vraiment pas le plus compliqué, mais analiser le moteur et trouveru n moyen de le patcher voire qu'il arrive à être plus rapide (version 128k bien sûr) ça c'est uen autre paire de manches...l'idéal serait d'arriver à contacter Costa Panayi donc, de lui faire une interview déjà, car oui ce type a été un des grand du Jeux sur micro 8bit Anglais des 80's... et donc sur CPC...
Bref un réservoir probable d'anecdotes et de détails techniques comme on les aime.
Et voir si il aurait pas quelques souvenirs et autre Sourcecodes qui traineraient dans ses cartons.
Il semblerai qu'il bosse comme ingénieur en mécanique ou consultant dans ce genre de domaine... en Angleterre.
ci joint : les tuiles des masques d'ombres.
