Dans les coulisses d'Agony

[Anarkhya]

L'histoire de la création d'Agony, racontée et (richement) illustrée par le/l'un des graphistes du jeu aka Franck Sauer.

Creating the owl animation was a very complicated and time consuming task. I started by analysing videos of flying owl and took a lot of notes. Then I used Sculpt4D to create a crude animation of two planes flapping and bending so I could generate a series of frame from the side view. For each frame I had to manually rotate each plane to a particular angle (see notes below). There was no such thing as texture mapping, so it was just two flat planes moving. I would then import each image into DPaint3 and draw all the owl feathers and body frame by frame, pixel by pixel.  Here are some notes and sketches that helped me puting this all together.

http://francksauer.com/index.php/games/15-games/published-games/index.php?option=com_content&view=article&id=10:agony&catid=15:published-games

[nowhereman]

trop beau
putain, 20+ ans 

[Frog]

Merci pour cet article très complet, sur un jeu visuellement très réussi et riche dans ses animations du décors.
En fait je n'ai jamais trouvé le gameplay formidable loin de là mais j'ai été motivé de continuer pour découvrir la richesse graphique de ce jeu.

Si le jeu était redéveloppé pour Amiga 1200 les sprites en 4 couleurs de la version A500 pourrait indubitablement être beaucoup plus coloré, le jeu serait probablement plus beau

[Anarkhya]

Et l'anecdote sur Redon, j'ai souri, l'intro d'agony a été dessinée à partir d'une photo de coucher de soleil prise dans un patelin à 60 bornes de chez moi (que tu dois connaitre Frog), énorme

Oui c'est vrai que l'aspect très cru et monochrome des sprites clashent un peu quand on les met en regard des superbes backgrounds et des artworks inter-niveaux, Beast III avait le meme probleme je trouve, Lionheart aussi dans une certaine mesure ou a été utilisé le meme style d'artifice pour le ciel d'agony, dégradé de couleurs en calque par dessus des tiles monochromes de 2/4 couleurs maxi.

Après, je ne sais pas, est ce que c'est une limitation imposée par des choix de programmation, sans doute, il y a d'ailleurs quelques limitations qui m'ont interpellé dans l'article, puisque d'une façon très simpliste j'imaginais qu'il y avait juste 32 couleurs au choix parmi 60000, un canvas de 320x240 et hop c'est parti on dessine, nan, nan, apparemment, il y a des limitations par bloc et par scanlines, (comme sur zx spectrum, en moins drastique?)

[Frog]

Et l'anecdote sur Redon, j'ai souri, l'intro d'agony a été dessinée à partir d'une photo de coucher de soleil prise dans un patelin à 60 bornes de chez moi (que tu dois connaitre Frog), énorme

oui oui je connais Redon, j'ai du y passer 1 ou 2 fois. Mais en fait j'avais même pas fait attention que l'équipe était francaise 

Pour les sprites en 4 couleurs oui c'est une limitation hardware de l'amiga. Par contre un bob peut être en plus de couleurs mais je pense que le sprite prend moins de temps processeur. (un petit article sur Wikipedia pour en savoir un peu plus sur les organes de l'Amiga)
Un choix de programmation facile à comprendre par exemple est que bouger une image en 4 couleurs prend moins de place mémoire à stocker (donc laisser de la place pour stocker d'autre image) et surtout prend moins de temps processeur. Pourquoi... et bien c'est simple à comprendre n'est ce pas Jamie :
...oui en effet puisque
1 image de 2 couleurs prend 1 bitplan
1 image de 4 couleurs prend 2 bitplans
1 image de 8 couleurs prend 3 bitplans
1 image de 16 couleurs prend 4 bitplans
1 image de 32 couleurs prend 5 bitplans.
On imagine donc bien que bouger 1 seul bitplan est plus facile et rapide à gérer que bouger ou ne serait-ce qu'afficher une image en 32 couleurs soit recomposer 5 bitplans à chaque VBL.

Autre astuce pour les couleurs est le copper ou peut changer la palette dans différentes portions de l'écran ce qui explique que parfois quand on voyait des ennemis passer dans certaines zones du décor, leur couleur de fond changeait et se retrouvait avec un beau dégradé. Mais le copper permet bien d'autres choses comme décrit dans l'article de wikipedia. On peut même si on le souhaite découper l'écran en quatres parties avec une partie en haut à gauche dans une résolution de 320x256, une autre en haut à droite en 640x256, une autre en bas en 320x512 et une autre en bas à droite en 640x512.
On peut même comme il l'explique pour les couleurs de fond du jeu créer de nouvelle résolution en changeant à chaque VBL par exemple les palettes de couleurs et se retrouver ainsi avec 2 écrans de 32 vraies couleurs (pas comme l'extra half brite) qui se superpose, ca créer par contre un léger effets de scintillement.
Un peu comme sur Atari avec le logiciel Spectrum 512 ou sur C64 et d'autres plateformes aussi sauf que sur Amiga c'est plus simple grace au Copper.
On peut aussi théoriquement créer de nouvelles résolutions.

En tout cas, le travail graphique de ce jeu est énorme surtout quand on voit que c'est seulement 2 graphistes qui ont réalisé tout ca !

[Anarkhya]

On peut même si on le souhaite découper l'écran en quatres parties avec une partie en haut à gauche dans une résolution de 320x256, une autre en haut à droite en 640x256...

Oh la la l'histoire des résolutions simultanées ! Ce qui voudrait dire que dans telle portion de l'ecran on serait sur un rapport de 2:1 par pixel et sur une autre portion un rapport de 1:2 ou 1:1... Cybfree a déjà essayé de m'expliquer mais ça veut pas rentrer dans ma cervelle, le concept est trop choquant pour moi    En fait je crois qu'il me faudrait un screenshot pour réaliser que ça existe et comment c'est fichu.

1 image de 2 couleurs prend 1 bitplan
1 image de 4 couleurs prend 2 bitplans

Là c'est clair chez moi, en revanche je me demande comment étaient fait des jeux avec plus de 8 couleurs par sprite, 4 couleurs je trouve ça trop tendu au niveau graphique, ça me semble donner des sprites un peu fades. Tiens par exemple, un jeu plutot coloré, avec pas mal de couleurs par sprite, plus que 8 apparemment, que j'aimerais bien déconstruire: http://www.lemonamiga.com/games/screenshots/full/fire_and_ice_04.png

[nowhereman]

On peut même si on le souhaite découper l'écran en quatres parties avec une partie en haut à gauche dans une résolution de 320x256, une autre en haut à droite en 640x256...

En fait je crois qu'il me faudrait un screenshot pour réaliser que ça existe et comment c'est fichu.

note : winuae avait encore du mal il y a quelques versions, fonctionne depuis 1.5.3 pour Disposable et 1.5.4+ pour RunAway

j'en connais que 2 qui l'utilisent :
- l'ecran start du jeu Disposable Hero : haut gauche/bas gauche/bas droite lores 32, haut droite hires 16

avec le bug winuae : http://youtu.be/S1gID8faNPw?t=2m43s

sans le bug winuae : http://youtu.be/DInBUpFCHY4?t=3m16s
la partie droite du menu "start options..." est faite avec des sprites 16 couleurs (lores) pour qu'elle soit raccord avec la partie gauche, sinon il y a un "trou" de 16 pixels entre les 2 (voir generique fin ci-dessous) : le temps raster mis par le copper pour changer les registres bitplans et la resolution.

- le generique de fin de Disposable Hero : à droite vertical scroll 1 bpl hires, à gauche image lores
http://youtu.be/S1gID8faNPw?t=32m5s (petit bug)
http://youtu.be/DInBUpFCHY4?t=29m13s (sans bug)

- l'intro de la demo RunAway/2000 a.d. : sans bug

à gauche lores, texte au "centre" hires, logo en haut à droite lores, et crayon à droite lores (sprites)
le bout du bras qui est sur le texte est en sprites 16 couleurs (lores)

si quelqu'un en connais d'autres utilisant ce truc.

c'est le meme principe que le "trial playfield" utilisant les sprites, utilisé pour les montagnes du fond de Jim Power par exemple, ou des arbres du Shadow of the Beast.
ou ici : http://youtu.be/EsQkx7tVp0s?t=4m44s

autre utilisation des sprites sur une image HAM : 16 premiers registres couleurs utilisés, 16 autres "libres" utilisés par les sprites.
ça le fait toujours :
voir ICE/Silents : http://youtu.be/EsQkx7tVp0s?t=2m15s

ou BBS Tracktro/Devils : image HAM hires interlaced avec un sinus scroll dessus
http://youtu.be/DPgA_ti841M?t=3m5s

un canvas de 320x240

rahh c'est 320x256 !

dégradé de couleurs en calque

un calque ? quel calque ? degradé au copper par changement de couleur du fond chaque x lignes. Ici il swappait à chaque vbl sur 3 copperlist differentes avec 3 degradés differents, comme Lionheart ou Unreal, pour multiplier le nombre de teintes (principe du HAM)

[Anarkhya]

Pour les résolutions simultanées, ok, je vois, je vois aussi pourquoi ça ne m'a jamais choqué quand j'en ai vu passer (si j'en ai vu passer), Si on utilise une image LoRes avec une font HiRes à coté, ça passe inaperçu, et meme dans le cas de disposable hero, c'est assez transparent du fait que d'un coté on ait une illustration et de l'autre une représentation 3D de laquelle on attend un résultat pixellisé (sur amiga)
Si quelqu'un tentait de placer deux images une LoRes une HiRes cote à cote dans le meme écran, là ça ferait bizarre, on verrait de suite un problème de pixellisation/déformation

rahh c'est 320x256 !

320x256 ou x200 oui oui je m'en suis rendu compte après, je sais pas pourquoi je veux que ce soit 240, sans doute parce que c'est la moitié de 640x480.

un calque ? quel calque ? degradé au copper par changement de couleur du fond chaque x lignes. Ici il swappait à chaque vbl sur 3 copperlist differentes avec 3 degradés differents, comme Lionheart ou Unreal, pour multiplier le nombre de teintes (principe du HAM)

Oui, j'exprime ça avec mes références anachroniques de graphisme bien à moi :P

[Frog]

Si quelqu'un tentait de placer deux images une LoRes une HiRes cote à cote dans le meme écran, là ça ferait bizarre, on verrait de suite un problème de pixellisation/déformation

on verrait effectivement qu'une partie de l'écran affiche une résolution plus fine (si c'est du 640x256) qu'une autre (si c'est du 320x200) mais par contre les images en elle même ne serait pas déformé puisque chaque image est affiché dans sa résolution native et l'écran est donc réellement découpé en un écran avec différente résolution.
C'est un peu comme si tu avais plusieurs écrans avec différentes résolutions et qu'un écran supplémentaire affichait le résultat de chaque écran sur un écran unique, c'est le miracle du copper de l'Amiga.
On le voit bien sur l'image qu'a posté nowhereman (ou cybfree) de l'intro de la demo RunAway/2000 a.d.

Pour le jeu Fire & Ice, je pense que ce sont des bobs (blitter object) qui ont été utilisé et un bob peut avoir autant de couleurs que l'écran sur lequel il est affiché, le bob utilisant la palette de l'écran sur lequel il est utilisé (il me semble) par contre un bob demande plus de ressource processeur qu'un sprite. Après un rapide coup d'oeil le jeu à l'air d'être un habile mélange de bobs et de sprites.
Le différence entre le bob et le sprite ne s'arrête pas là puisque dans l'absolu on peut afficher un nombre illimité de bobs alors que le sprite est limité au niveau hardware à 8, peut être y-a-t-il eu des astuces pour en afficher plus ?

[Anarkhya]

C'est un peu comme si tu avais plusieurs écrans avec différentes résolutions et qu'un écran supplémentaire affichait le résultat de chaque écran sur un écran unique, c'est le miracle du copper de l'Amiga.

C'est fou! Mais attends, imaginons que l'image HiRes soit sur la portion de droite, on verrait quand meme une déformation du fait que 640x256 utilise des pixels deux fois plus allongés en hauteur pour dessiner l'image (mmm à y réfléchir j'ai l'impression que je suis en train de dire une connerie là, c'est compliqué tout ça :P)

Pour le jeu Fire & Ice, je pense que ce sont des bobs (blitter object) qui ont été utilisé et un bob peut avoir autant de couleurs que l'écran sur lequel il est affiché, le bob utilisant la palette de l'écran sur lequel il est utilisé (il me semble) par contre un bob demande plus de ressource processeur qu'un sprite.

Héhé j'imagine la bataille que ça devait être entre graphistes et programmeurs:

Le graphiste, enthousiaste: Je t'ai fait des ennemis en 12 couleurs, ils sont top !
Réponse du programmeur: Laisse tomber le blitter ça bouffe trop de cpu faut que tu fasse des sprites, et pas plus de 4 couleurs sinon le jeu tournera à 12fps.

[nowhereman]

oh putaing con, je viens de comprendre ton erreur   

il ne faut pas confondre la Resolution de l'ecran (basse 320, haute 640...) et la taille de la zone ecran concernée ou taille des bitplans !

tu pense que quand on dit on coupe l'ecran en deux : premiere moitié en 320x256 et deuxieme moitié en 640x256
= 320+640=960 pixels !

Non! c'est la resolution choisie :
1ere moitié en LoRes (320) mais taille bitplan à afficher, 160 pixels de large
2eme moitié en HiRes (640) mais taille bitplan à afficher, 320 pixels de large en hires = pixel 2 fois moins gros donc equivalent à 160 en largeur
je ne parle pas de pixels, mais de temps raster : le faisceau parcours la meme distance

la taille max en pixels d'une TV PAL  4:3 est 720*576 (format DVD)

[Anarkhya]

ahah ok oui je vois l'erreur maintenant et je vois à peu près d'ou elle vient, je pense que c'est à force d'utiliser des émulateurs en fenetré du coup mes références de comparaison sont en terme de taille, nombre de pixels qui compose l'image, et là ou ça déconne c'est que je compare ces tailles d'image avec l'affichage sur mon PC qui est dans une résolution gigantesque comparé à un amiga.. Bon le fait de n'avoir pas vu tourner un vrai amiga sur un vrai moniteur ou une petite TV depuis des lustres n'aide pas franchement, je confondrais pas résolution et définition d'image, non, c'est pas ça ?

Par contre, je réalise aussi que je n'ai toujours pas compris cette histoire de bitplans, ça ne me parle pas du tout   

[nowhereman]

Par contre, je réalise aussi que je n'ai toujours pas compris cette histoire de bitplans, ça ne me parle pas du tout   

calque ? texture ? en langage djeun 

[Frog]

ahah ok oui je vois l'erreur maintenant et je vois à peu près d'ou elle vient, je pense que c'est à force d'utiliser des émulateurs en fenetré du coup mes références de comparaison sont en terme de taille, nombre de pixels qui compose l'image, et là ou ça déconne c'est que je compare ces tailles d'image avec l'affichage sur mon PC qui est dans une résolution gigantesque comparé à un amiga.. Bon le fait de n'avoir pas vu tourner un vrai amiga sur un vrai moniteur ou une petite TV depuis des lustres n'aide pas franchement, je confondrais pas résolution et définition d'image, non, c'est pas ça ?

effectivement le PC avec ses très haute résolution peut afficher les résolutions de l'amiga du moins en les émulants. Du coup WinUAE pour certaines résolutions amiga n'existant pas sur PC on dédouble certains pixels pour que le rendu sur PC donne le même rendu.
Par exemple pour qu'une image d'Amiga en 640x256 s'affiche correctement sur PC, on dédouble le rendu d'affichage de l'image sur les Y pour qu'elle apparaisse correctement sur PC dans une résolution classique 640x400
Pour le 320x512, on dédouble le rendu d'affichage de l'image sur les X pour qu'elle apparaisse correctement en 640x400, sur PC en 640x400.
Par contre quand on a une image originale de l'Amiga en 640x256, si on ne passe pas par un émulateur, on est forcé de dédoubler les pixels en Y de l'image pour qu'elle s'affiche correctement.
Ca explique pourquoi certaines images sur ArtCity n'ont pas le rendu correct comme sur l'ordinateur sur lequel l'image a été concu si l'uploader à conserver la forme originale de l'image.

Par contre, je réalise aussi que je n'ai toujours pas compris cette histoire de bitplans, ça ne me parle pas du tout   

C'est assez simple, imagine une peinture à l'huile par exemple. La technique selon wikipedia est la suivante :
Les couches picturales du tableau sont superposées selon le principe du « gras sur maigre » et exploitent les transparences de certains pigments, alliées à celle des médiums.
En gros on met d'abord certaines couleurs de base, puis ensuite on va rajouter d'autres couches de couleurs qui vont se superposer les unes aux autres
Les bitplans en informatique c'est un peu pareil. Je te conseil d'utiliser un ripper d'image si tu veux comprendre le principe, ca te parlera beaucoup plus.
Codetapper a sorti il n'y a pas longtemps MapTapper je ne l'ai pas utilisé mais il est parait-il très bien, il fonctionne sur PC
Sinon sur Amiga il y a HRTMon, 3rdDay ou encore BPlRipper

[Anarkhya]

Mais donc les bitplans ce seraient des calques, j'entends par là que le calque du sommet de la pile affecte tous ceux situés en dessous ? J'ai lu l'entrée bitplane sur wiki, j'ai rien compris :P En fait visiblement il faudrait que j'assimile ce qu'est un bit et ce qu'est un plane, avant de chercher à comprendre ce qu'est un bitplane.

En fait j'ai déjà essayé de ripper avec plus ou moins de succès, mais comme j'utilisais un tutorial très détaillé, je ne comprenais de toute façon pas ce que je faisais (probleme typique de l'apprentissage par tutorial d'ailleurs) et j'avoue que je ne cherchais pas non plus à comprendre puisque seul le résultat m’intéressait, à savoir: choper des tiles que je ne pouvais pas récupérer avec la méthode screenshot.