Re: Zoom sur les systèmes 16 bit.

[sengoku 2]

Sinon réellement faire de petit zoom / rotation temps réel c'est possible, du moins sur MD (sur SNES de petit zoom doivent être possible aussi).
Mega Turrican en est l'exemple (plusieurs ennemis utilisent du zoom et/ou de la rotation temps réel). Et perso je trouve que c'est préférable à la méthode de tout mettre en ROM, l'air de rien une animation zoom/rotation smooth (30/60 FPS) ça consomme vite beaucoup de ROM !

Je pige pas là, zoom temps réel, ça veut dire que tu rentres des lignes de programmation où tu dis : "déplaces le point z à l'échelle 15 etc..." ?


Sinon, je suis d'accord avec toi sur le mode 7 utilisé pour le petit boss de SMW, le reste du décor doit être affiché en sprite.

J'ai revu le stage de lave de Musha Aleste et je retire ce que j'ai dit dans mon dernier post car c'est vraiment fluide et donc c'est un exemple réussi de zoom précalculé.

Touko, pour Aldynes il y a aussi les options modules du vaisseau qui viennent se greffer en utilisant un zoom.

[Tryphon]

Sinon réellement faire de petit zoom / rotation temps réel c'est possible, du moins sur MD (sur SNES de petit zoom doivent être possible aussi).
Mega Turrican en est l'exemple (plusieurs ennemis utilisent du zoom et/ou de la rotation temps réel). Et perso je trouve que c'est préférable à la méthode de tout mettre en ROM, l'air de rien une animation zoom/rotation smooth (30/60 FPS) ça consomme vite beaucoup de ROM !

D'où ma question : comment tu (ou un autre codeur) ferais pour optimiser ça avec le hardware de la MD ?

[Invité]

L'exemple de level de Musha reproductible sur PCE (avec la vidéo postée par Touko) je pense qu'il faut quand même dire que ce n'est pas aussi simple que ça avec la PCE :p
Là ça marche d'une part car il s'agit d'un motif répété mais surtout ça ne marcherait pas en condition in-game car tu ne peux pas utiliser autant de sprites pour refaire le premier plan (ça clignoterait de partout avec les ennemis car parfois le premier plan prend quasiment toute la ligne).

Oui je parle seulement de l'effet Vscroll, le premier plan tel qu'il est dans musha n'est pas faisable, ça l'est facilement sur SGX par contre .

[Stef]

Je pige pas là, zoom temps réel, ça veut dire que tu rentres des lignes de programmation où tu dis : "déplaces le point z à l'échelle 15 etc..." ?

?? Ben de la même manière que le zoom du boss de puggsy par exemple...
En gros oui tu as une fonction en code qui te permet de scaler une image. Le plus simple c'est de lui donner l'image de base et de lui donner un facteur de zoom en paramètre ou la taille de sortie souhaitée mais ça ça te regarde je dirais
Dans SGDK j'ai une méthode de scaling software, bon elle est codée en C mais ça marche quand même (je l'utilise dans la rom de test SGDK).

[sengoku 2]

Trouvé un passage de zoom réussi de Mega Turrican, en + y en a plusieurs à la fois :

https://www.youtube.com/watch?v=6H-qskYLiAE&feature=youtu.be&t=6m20s

Maintenant Stef, j'aimerais savoir comment tu fais pour reconnaître sur MD, un zoom pré-calculé et un zoom temps réel.

[Tryphon]

Grosso modo, si je veux faire un zoom 7/16 (je dis ça au pif), je copie 7 pixels bien choisis par tranche de 16, sur 7 lignes bien choisies par tranche de 16 ?

J'envoie ça direct en VRAM ?

[sengoku 2]

Une autre question, avec ta technique de zoom temps réel, " j'aimerais savoir Stef, si on peut éviter l'effet "gros bloc pixellisé" ?

Sinon Tryphon, bien que le system 16 ait le mode "Shrinking" , tu es chanceux que ça n'a pas été utilisé sur Shinobi arcade.

[Stef]

sengoku 2> En général tu le repères car il est bien plus smooth (plus d'étapes d'animation) qu'un zoom précaculé, aussi il est imparfait dans le sens où il n'y a pas d'interpolation sur les pixels, c'est d'ailleurs ça qui donne cet effet de "pixellisation". Avec un zoom précalculé, tu vas mélanger les pixels ensemble pour former le nouveau afin de mieux respecter l'image initiale. Quand tu fais du zoom en temps réel (surtout sur ce genre de machine) tu vas utiliser un algo qui prends toujours des pixels de l'image d'origine pour construire l'image destination. En gros si tu dézoomes, tu as l'image d'origine mais avec moins de pixels (effet d'aliasing)... si tu zoomes au contraire tu dédoubles les pixels (pixellisation).

tryphon> oui en gros c'est ça, c'est une méthode rapide mais imparfaite dans le résultat produit comme je l'explique juste au dessus (effet de pixellisation).

[Tryphon]

Pour la pixellisation, je suppose que c'est inévitable. On peut pas faire de l'antialiasing avec la MD (ou alors ça va bouffer des couleurs, déjà qu'on en manque )

Pour Shinobi, j'aurais précalculé je pense :)

[Stef]

Ouais non pas d'anti-aliasing possible :p Déjà parce-que ça coute déjà bien trop en CPU et aussi parce-que ça nécessite un mode RGB et non paletté comme on a sur ces générations de machine.

[airdream]

Tu as des zooms en temps réel sur les boss de Mr nutz amiga(ici celui de fin):
https://youtu.be/j5e78_9Eo2Y?t=55m32s

somptueux, le zoom est vraiment bien fait!!!!! Bien plus fluide que le boss de Puggsy sur MD  


On trouve aussi des astuces sur PCE comme cet exemple dans alydness, avec des boulette ennemies venant du fond du decor a voir sur le passage ci dessous

https://youtu.be/vvBctR39Rd0?t=10m21s

ou encore dans bomberman 93 ici le zoom est plus consequent (zoom facon TMNT 4 sur SNES). Bon c'est hors phase de jeu mais ca rend bien pour une petite PCE  

https://youtu.be/iEwOvr7-4zU?t=6m5s



et sur MD j'illustre juste l'exemple de stef, mais toujours hors phase de jeu.

https://youtu.be/mbLeh0K9_Lw?t=4m58s



aussi le logo sega dans gunstar heroes (mieux fait que celui de mega turrican je trouve)

https://www.youtube.com/watch?v=bMn1AN6Iclg

Ou encore les boules d'un niveau dans Aladdin, mais en phase de jeu cette fois

https://youtu.be/uWhJOIFKtm8?t=16m54s

sinon il est vrai que ca reste rare sur MD et PCE. Il y en a beaucoup plus sur MCD ou SNES

voir deja les effets presents dans le bios qu'on retrouve dans divers jeux MCD et meme en mieux.

[Invité]

sinon il est vrai que ca reste rare sur MD et PCE. Il y en a beaucoup plus sur MCD ou SNES

Normal car ces machines ont le moyen d'en faire en hard, voir hard+soft avec le MCD ..
Je suis même étonné qu'il y ai pas plus d'effets originaux dans les jeux MCD .

somptueux, le zoom est vraiment bien fait!!!!! Bien plus fluide que le boss de Puggsy sur MD    

Le zoom est bcp plus important aussi, le boss zoomé prend presque tout l'écran, tu as aussi un scrolling en même temps et un changement de palette pendant le zoom pour renforcer l'effet .

[airdream]

somptueux, le zoom est vraiment bien fait!!!!! Bien plus fluide que le boss de Puggsy sur MD    

Le zoom est bcp plus important aussi, le boss zoomé prend presque tout l'écran, tu as aussi un scrolling en même temps et un changement de palette pendant le zoom pour renforcer l'effet .

c'est incroyablement bien fait, en effet en plus du zoom (qui a deja une plus grande amplitude) il y a le scroll et un changement de couleur pour renforcer son éloignement/rapprochement.
Les copro de l'A500 aide bien en ce sens aussi je pense, tout comme le second motorola 68000 aide au jeux MCD, car a mon avis les roto-zoom du MCD doivent etre realiser grace a cet ajout CPU, et non deux copro specifique comme sur SNES 

[Invité]

Les copro de l'A500 aide bien en ce sens aussi je pense, tout comme le second motorola 68000 aide au jeux MCD, car a mon avis les roto-zoom du MCD doivent etre realiser grace a cet ajout CPU, et non deux copro specifique comme sur SNES  

Oui bien sur sans ça je pense que c'était impossible .
Par contre comme tu dis sur MCD, je comprends pas qu'avec l'asic+le second 68000, il n'y ai pas bcp plus d'effets dans les jeux,et je trouve ça dommage .

Sinon tu as aussi le rotozoom+déformation sur l'intro de brian the lion qui est très bien fait aussi et fluide .

[airdream]

Par contre comme tu dis sur MCD, je comprends pas qu'avec l'asic+le second 68000, il n'y ai pas bcp plus d'effets dans les jeux,et je trouve ça dommage .

ca doit etre un poil plus laborieux a implementer sur MCD que sur SNES, je vois pas d'autre raisons.
en effet c'est dommage qu'ils s'en sont pas plus servit

[Invité]

Par contre comme tu dis sur MCD, je comprends pas qu'avec l'asic+le second 68000, il n'y ai pas bcp plus d'effets dans les jeux,et je trouve ça dommage .

ca doit etre un poil plus laborieux a implementer sur MCD que sur SNES, je vois pas d'autre raisons.
en effet c'est dommage qu'ils s'en sont pas plus servit

Je sais pas peut être, mais franchement je vois pas pk ..

Sinon tu as ça aussi dans un niveau bonus(la platerforme qui zoome):
https://youtu.be/m-IDcTW8JQ4?t=9m29s

[Stef]

Le MCD a été vraiment sous exploité, y'a quand même des jeux comme Soulstar ou Thunderawk qui montre un peu ce que pouvait faire le MegaCD en terme de zoom, rotation... J'aime bien ce passage dans Soulstar :
https://youtu.be/rObi13jlNy4?t=1024

On voit qu'en plus de la rotation et du zoom des sprites, les capacités de scrolling sont mises à contribution pour simuler un effet de déformation dans l'eau... Ca montre à quel point c'est plus flexible que la SNES dans ce domaine mais en contrepartie on ne peut pas avoir du 60 FPS en plein écran.

Sinon le MCD intègre un mode qui permet de facilement faire du bitmap, dommage que ce n'est pas été plus utilisé pour faire de la 3D basique par exemple :-/

[Invité]

Ouai mais c'est dommage que dans les jeux MCD 2D classiques, y'a aucun effet particulier,hormis ceux déjà gérés par le hard de la MD .
Peut être dans robot aleste avec l'effet de transparence sur les tirs ..

[upsilandre]

j'aime bien celui la

[DePouLe02]

j'aime bien celui la

Clair que l'effet est super impressionnant

[sengoku 2]

Upsilandre, je suis un grand partisan de tes gif animés , tu devrais faire un site pour les compiler dans une rubrique adéquate.
En tout cas, très bon exemple ton gif batman and robin, de plus ça s'assombrit légèrement lors de l'éloignement et ça s'illumine légèrement en phase d'approche.
Cela renforce l'effet comme avec l'exemple de zoom de mr nutz Amiga qui est très réussi comme le font remarquer airdream et Touko.

Le mega cd, un gars de sega-16 avait fait cette vidéo :




De toute manière, quand on voit Soulstar, on ne peut qu'applaudir la prouesse.

Vu les capacités de zoom de la mega cd, je ne comprends pas pourquoi la version mega cd de Sengoku Densyo n'a pas les effets de sprites zoomés de la version NG.
Y avait largement de quoi faire une conversion encore plus proche de la version NG...

[sengoku 2]

En parlant de sengoku densyo, je me suis sans doute trompé dans la description de certains sprites qui disparaissent. J'avais fait une vidéo avec l'emploi du mot " shrinking explosion" en pensant que ça utilisait le shrinking de la neo geo.
Mais à voir le retrogametest sur le System 32 de Sega où Douglas Alves décrit cela comme un stretching comme un effet comme un livre qui s'ouvre où  "des lignes qui sont éliminées et d'autres qui apparaissent..."
Du coup, je me demande si cela correspond + à la description du Raster effect ?

A voir le passage de 24 min 30s à 25 min 20s :

https://www.youtube.com/watch?v=NMF6JIXAh8I&feature=youtu.be&t=24m30s


Sinon la vidéo que j'avais fait :

[Stef]

j'aime bien celui la

Il est bien réalisé c'est sur... Bien évidemment les sprites sont précalculés mais pour le coup c'est mieux ainsi, ils ont mis le paquet sur le nombre d'étapes du coup ça passe bien. Aussi ce qui sublime l'effet c'est la réalisation parfaite de l'animation avec une superbe gestion de la profondeur en Z avec l'ombrage...

[upsilandre]

En parlant de sengoku densyo, je me suis sans doute trompé dans la description de certains sprites qui disparaissent. J'avais fait une vidéo avec l'emploi du mot " shrinking explosion" en pensant que ça utilisait le shrinking de la neo geo.
Mais à voir le retrogametest sur le System 32 de Sega où Douglas Alves décrit cela comme un stretching comme un effet comme un livre qui s'ouvre où  "des lignes qui sont éliminées et d'autres qui apparaissent..."
Du coup, je me demande si cela correspond + à la description du Raster effect ?

Ce qu'il appel du streching ca a l'aire d'etre juste du shrinking mais sur un seul axe (ici du shrinking horizontal sur les sprites).
Et faire du shrinking sur le seul axe vertical ca on sait le faire effectivement sur le background en raster effect meme sur une NES.

Le shrinking et le zoom sont les 2 faces d'une meme piece.

[sengoku 2]

Donc, j'ai bien fait d'intituler ma vidéo : shrinking explosion.

Je profite pour poster 2 de tes gifs qui illustrent du shrinking vertical :







Pour Summer carnival, tu avais illustré cela en parlant de shrinking vertical, moi avec mes grosses lacunes en connaissances techniques, j'aurais employé le mot : distorsion. 

Sinon puisque les autres consoles savaient le faire, pourquoi ne pas l'avoir reproduit dans sengoku mega cd, king of monster 2 snes ?
Est-ce parce que sur du sprite, ça consomme + de cpu ou du DMA ?
Et que sur du background, c'est + facile à gérer ?

[Stef]

Pour le shrinking vertical bien sur tu ne peux l'appliquer que sur les plans (sauf lorsqu'il y a un support hard comme sur NeoGeo) car pour faire cet effet tu vas modifier le scrolling vertical à chaque scanline (ce qui n'est visiblement pas possible sur SMS, une grosse lacune de cette machine à mon sens).
En réalité faire du shrinking sur les sprites, ça doit pourvoir se faire sur MD qui accepte les modifications de la table de sprites pendant l'affichage. Mais du coup, ça signifie que tu dois modifier la position verticale du sprite à chaque scanline et comme tu as très peu de marge sur ce que tu peux modifier en 1 seule ligne, je dirais que de manière réaliste tu dois pouvoir l'appliquer sur 5/6 sprites maximum (en optimisant bien ton code). Sur SNES il me semble qu'il est impossible de modifier les sprites pendant la période active, idem sur PCE et sur NES il me semble. En fait je me demande si pour le coup la SMS en serait pas capable non plus (je ne la connais pas assez).

Pour Summer Carnival, y'a un mélange de distortion + shrinking vertical en fait, c'est à dire qu'ils modifient à la fois le scrolling vertical et horizontal par scanline. Par contre pourquoi est-il aussi saccadé O_o ?? Peut être ont-ils délibérément limité les modifications du scroll pour soulager le CPU.

[Invité]

Sur pce tu peux pas modifier directement la SAT qui est dans un buffer propre au VDC le codeur n'y a pas accès(c'est pour ça que le changement de dot clock, n'augmente pas le nombre de sprites/ligne) .
Cependant tu peux définir plusieurs frame dans une frame (ce qui va forcer la réactualisation de la SAT du VDC, donc ça pourrait être possible (perso j'ai jamais fait ça).

Pour Summer Carnival, y'a un mélange de distortion + shrinking vertical en fait, c'est à dire qu'ils modifient à la fois le scrolling vertical et horizontal par scanline. Par contre pourquoi est-il aussi saccadé O_o ?? Peut être ont-ils délibérément limité les modifications du scroll pour soulager le CPU.

J'ai plus l'impression qu'il est buggé, tu as une grosse partie en haut qui scrolle juste de gauche à droite .
Après c'est possible que ce soit pas un bug, mais pour diminuer la charge CPU.

[Stef]

Sur pce tu peux pas modifier directement la SAT qui est dans un buffer propre au VDC le codeur n'y a pas accès(c'est pour ça que le changement de dot clock, n'augmente pas le nombre de sprites/ligne) .
Cependant tu peux définir plusieurs frame dans une frame (ce qui va forcer la réactualisation de la SAT du VDC, donc ça pourrait être possible (perso j'ai jamais fait ça).

Qu'est ce que tu veux dire par "définir plusieurs frames dans une frame" ? comment cela force la réactualisation de la SAT ? je pensais que sur PCe c'était un peu comme sur NES, tu avais un DMA dédié à la SAT qui fonctionne que pendant le VBlank et basta...

[Invité]

Qu'est ce que tu veux dire par "définir plusieurs frames dans une frame" ? comment cela force la réactualisation de la SAT ? 
je pensais que sur PCe c'était un peu comme sur NES, tu avais un DMA dédié à la SAT qui fonctionne que pendant le VBlank et basta...

En gros, tu indiques au VDC via une interruption ligne qu'il commence une nouvelle image (c'est comme si il sortait d'un vblank), et donc le DMA va recharger le buffer sat (en VRAM) vers le VDC,et faire comme si il commençait une frame .
C'est tricky et je sais même pas si c'est vraiment exploitable dans un jeu, mais il semble que le jeu coryoon le fait .

Sinon oui en temps normal, une seule MAJ de la SAT se fait automatiquement(par défaut) dès que le vblank claque .

[sengoku 2]

Bon, il y a aussi du shrinking horizontal dans Sengoku Densyo.

Pour le shrinking horizontal, qu'est-ce qui empêche cela sur les autres supports ?

En tout cas, merci Upsilandre, Touko et Stef pour vos expertises car je suis parfois perdu quand il s'agit différencier un raster effect avec un autre effet. J'ai même lu que dans certains vs de combats ( à la street fighter 2 ) , le linescroll du scroll est fait avec un raster effect ?







A gauche, version SNES avec un zoom pré-calculé et à droite version arcade.

Une autre projection zoom de la version arcade dont je ne me souviens pas si elle est présente sur SNES :





Présentation de stage sur Snes et sur Arcade mais avec ce qui ressemble à un shrinking horizontal :

[upsilandre]

C'est un shoot donc faut quand meme gardé un peu de ressource CPU je pense.
Ca m'a permis de voir que le gif etait bugué, c'est mieux comme ca

Du coup pour ce genre de shrinking vertical (ou plutot streching) c'est la SNES et son HDMA qui doit etre le plus commode.


Ce qui est marrant c'est que toutes les premieres machines a sprite avait une fonction zoom, Atari 2600, Odyssey2, Intellivision, Colecovision, C64. C'etait basique, en général du zoom 1 bit avec juste 2 alternative en ratio entier, 1:1 ou 2:1 et basta (ca permetait d'avoir de gros sprite lowres). Ca a disparu ensuite car on comprend bien que ce qui est intéressant et compliqué c'est les valeurs intermediaire de transition.

Meme si a l'epoque les exigences en scaling etaient faible, il etait pas question d'interpolation ou de préservation de l'information (un vrai shrinking c'est pas enlever de l'information mais melanger de l'information pour la rendre plus dense, c'est evidement pas ce qu'on demande a l'epoque), mais juste de choisir quelle pixel/ligne dupliquer ou quelle pixel/ligne enlever selon le facteur de scaling selectionner, mais rien que ce choix la etait deja compliqué a faire (on le voit sur Neogeo qui est obligé de passer par une table précalculé dans une ROM pour eviter de passer par de l'arithmetique et on est dans les années 90).
On devine un peu que l'architecture dominante de l'epoque qui consistait a construire l'image a la volé au raster sans framebuffer etait pas tres "scaling friendly", généralement ca consistait a recomputé toute la liste de sprite a chaque ligne, rajouter de l'arithmetique la dedans c'etait compliqué. Les choses se sont decoincé je pense quand on est passé a des solutions de construction defferé dans un framebufer comme c'est le cas jusqu'a aujourd'hui.

Ca serait intéressant d'en savoir plus sur les solution hardware de scaling de l'epoque (a mon avis doit y en avoir autant de differente que de hardware) au moins chez Sega en Arcade. Les X et Y board etait je pense encore des machines au raster (avec peut etre quand meme un buffer bitmap d'une seul ligne ), faudrait voir comment elles gerait tout ca.
Pole position en 1982 ca serait intéressant de savoir aussi comment etait fait le scaling, précalculé ou pas (y a seulement 96 Ko de tiles)
https://youtu.be/FFs1Xc82Q0U

Et encore avant y avait le tres etrange Turbo de Sega qui utilisait une sorte de scalling analogique en faisant varier la frequence d'horloge du bus de la ROM GFX, un truc dans le genre.
https://youtu.be/H-miyT1Vz1w



Sur le System 16 y a un shrinking mais limité a un facteur 1:2 (contrairement au shrinking NeoGeo qui va jusqu'a 1:128) ce qui est bien suffisant car idéalement le principe du shrinking c'est qu'une fois que t'a divisé ton sprite par 2 ( avec 30 nuances intermediaire possible ici) tu le remplaces par un autre plus correct que tu shrink a nouveau ect... ca evite la derive de perte d'information. Si tu shrink un sprite 128x128 en 8x8 ca va faire de la bouillie alors qu'avec des etapes intermediaires ca sera plus propre et ca consomme au max qu'un tiers de pattern en plus (c'est aussi le principe du mipmaping en rendering 3D).
La aussi je me demande a quoi ressemble l'implementation hardware du shrinking sur System 16 (est ce que ca passe aussi par une table précalculé? ca m'a l'aire de s'adapter en fonction de la taille originel du sprite du coup ca met le doute)