Explications(ENG) comment le moteur 3D de toy story MD a été codé

[Invité]

Bonjour une video ,sur comment le moteur 3D(partie fps) de toy story sur MD a été codé .

Intéressante,il explique la technique qui a été utilisé pour le jeu .

[philip]

Merci pour l'info ! :)

[tetsuro]

Merci pour le partage vieux ! :)

[Invité]

De rien les "jeunes" 

[Tryphon]

Merci Touko. Ça c'est intéressant !

[TotOOntHeMooN]

A cela, il va ajouter le gameplay basic et ça va chuter facile d'une dizaine de fps...
Du coup, optimisation radicale, on colle un gros HUD qui prends 1/4 de l'écran et nous voici à 60fps. 

[Tryphon]

Je comprends rien à ce qu'il raconte (blame my spoken english), mais le premier code me paraît déjà bizarre (pourquoi move.b et pas move.l ? pourquoi pas de (a0+), (a1+) au lieu de add.l juste après ?)

[Invité]

Technique intéressante ! Je l'avais vu sur le forum très Select de Sega16.
Et oui le secret d'une bonne optimisation, c'est aussi un gros HUD !

[TotOOntHeMooN]

Je comprends rien à ce qu'il raconte (blame my spoken english), mais le premier code me paraît déjà bizarre (pourquoi move.b et pas move.l ? pourquoi pas de (a0+), (a1+) au lieu de add.l juste après ?)

J'imagine que c'est parce que les données sont sur 8bit et leurs adresses sur 16bit.
(j'ai pas fait de 68000 depuis le lycée, mais je crois me rappeler que les parenthèses indiquent le contenu de l'adresse, c'est à dire la donnée)

[Tryphon]

Ben, suffit d'aligner ? Avec des move.l tu transférerais les données 4 par 4, ce serait plus rapide. Et je suis à peu près sûr que les post incrémentations sont plus rapides que les add. Touko confirmera (il connaît les cycles par cœur )

[Invité]

Je comprends rien à ce qu'il raconte (blame my spoken english), mais le premier code me paraît déjà bizarre (pourquoi move.b et pas move.l ? pourquoi pas de (a0+), (a1+) au lieu de add.l juste après ?)

Je dirais parce que les bandes sont d'une largeur de 2 pixels, et sur Md 2 pixels sont codés sur 8 bits (4bits/pixel) puisque l'affichage est en chunky .
Et comme tout le rendu du moteur est basé sur ces fameuses bandes de 2 pixels, t'es obligé d'utiliser les bytes,mais ça donne un meilleurs rendu,car plus précis .
Par contre je me suis aussi demandé pk il utilise pas la post incrémentation au lieu de faire un +1 .

Il aurait pu le faire sur des long, mais il aurait fallut faire des traitements sur les bits avant pour garder la même granularité au niveau des bandes,donc surement plus lent au final .

Après peut être qu'un re-agencement des données en RAM aurait permis d'utiliser des long sans traitement,en stockant chaque bande de façon contigu ..

[Tryphon]

S'il écrit deux pixels par deux pixels, il faut qu'il ajoute 4 à a0 et a1 entre deux écritures (ce qui explique qu'il ne puisse pas utiliser la post-incrémentation), mais du coup ça fait sens en effet.

[Stef]

Pour ce genre de rendu raycasting en strip vertical tu ne peux pas faire mieux que du byte. Mais dans la vidéo je trouve qu'il simplifie un peu la réalité, déjà pour la texture l'adresse est variable forcément, et même pour le destination, étant donné que tu rends en strip vertical et que tu dois transférer dans des tiles tu ne dois pas pouvoir utiliser la post incrémentation..

[Invité]

Oui, c'est du coup surement pour ça qu'il incrémente juste A0 et A1 sur 32 bits, ça fait le saut +4

[Tryphon]

add.l #1, a0 ça rajoute 4 ?

[Invité]

Non ça ajoute +1 à une adresse 32 bits = 4x8bits 

[Tryphon]

donc c'est bien un
add.l #4, a0
add.l #4, a1
qu'il aurait fallu dans la vidéo (en 2:45) ? Ainsi, l'écriture du prochain octet (=2 pixels) se serait faite 4 octets (= 8 pixels = 1 ligne) plus loin ?

Bon, d'une façon ou d'une autre va falloir que je comprenne ce qu'il raconte, fucking spoken English

[Invité]

Vous leurrez pas ... Il ne va pas tout expliquer !!
Juste en surface .. J'imagine le code de fond qui doit être 3 fois plus complexes que ces bêtes lignes de code ASM que je suis arrivé à comprendre en partie !

Le mieux, est que l'un de vous en fasse un et que l'on en discute ensemble non ?

[Invité]

@tryphon: j'ai dit ça comme ça, mais en fait je sais pas le pk du +1,plutôt que le post increm  

Surtout que les données de chaque bandes semblent être alignées .

[Tryphon]

Baah de toutes façons, après Shinobi, j'ai l'intention d'essayer divers trucs pour d'autres projets. En particulier je voulais tester des rendus 3D pour faire un beau port de Phantasy Star premier du nom, ce sera l'occasion...

[Stef]

Bien sur il ne rentre pas dans tout les détails, il donne l'idée générale des optimisations qui a mis en place, et le add.l #1 c'était juste pour montrer qu'il faut mettre à jour les pointeurs d'adresse des 2 côtés (à la base), ensuite il montre avec l'unrolling et les offsets en dur pour montrer l'optimisation effectuée :)
Ce qui est impressionnant c'est que le moteur de base peut tourner à 30 FPS :) Pour de la MD c'est quand même bien impressionnant.

[Invité]

Bon ben au boulot les gars !!

[upsilandre]

Je pense que c'est plus rigolo de s'amuser a faire du raycasting sur des machines qui justement sont pas cablé pour le jeux video et pour t’épater a coup de sprite et de scrolling. C'est la ou tu pourra le mieux surprendre, genre ZX-spectrum, CPC, Atari ST...

[Stef]

Au contraire, je dirais que faire du raycasting sur des machines à base de frame buffer ça n'a rien de bien impressionnant, c'est classique et d'ailleurs c'est sur ce genre de machine qu'on a vu apparaitre ce genre de moteur en premier... Enfin perso je trouve ça moins impressionnant que sur une machine qui fonctionne à base de tilemap (et donc pas très adaptée).

Et d'ailleurs :
https://www.youtube.com/watch?v=COH55Uj53TY
Celui ci est particulièrement impressionnant (j'avais un peu suivi le dev) :
https://www.youtube.com/watch?v=Z3-J2-VeoH8

[upsilandre]

Oui toi tu parle d'impressionner les programmeurs.
Mais si tu veux convaincre des joueurs ca sera bien plus convaincant et ca fera beaucoup moins tache dans le catalogue sur des machines qui sont justement deja en galère pour faire un simple scrolling ou bouger un sprite mais qui par contre sont plus a l'aise pour du raycasting. Y a moyen de séduire des joueurs (du coup ca peut etre gratifiant) alors qu'avec du raycasting sur NES ou SNES aucun joueur n'en veut comparé au reste du catalogue y a un gouffre visuel. C'est juste un défi de programmation personnel (ce qui est bien aussi mais c'est un autre delire).

[Tryphon]

Ça se discute : sur NES ou SNES (ou SMS ou MD) il n'y a (quasiment) aucun jeu 3D raycastée. En en faisant un, tu peux aussi séduire des joueurs par la nouveauté.

Le Wolfenstein 3D de gasega (si je me souviens bien ?) est un des projets homebrews les plus attendus de la scène MD, pas que des programmeurs.

[TotOOntHeMooN]

S'il y a une chose qui a pourri les jeux "16bit" dans les années 90, c'est bien d'avoir voulu faire de la 3D.
Soyons réalistes, c'est moche et vide... Même la PS1 faisait pitier à ses débuts, alors une MD.

Je dirai même que c'est définitivement ce qui a plombé le 32X...
Alors qu'il y avait tant à faire de génial en 2D avec !

[Hpman]

En vrai il est pas du tout fait pour la 2D le 32X, ça à même plutôt tendance à mouliner.

[TotOOntHeMooN]

En vrai il est pas du tout fait pour la 2D le 32X, ça à même plutôt tendance à mouliner.

Pas plus que pour la 3D... C'est juste* deux CPU plutôt rapides, de la RAM et un double framebuffer.
Tu es libre d'en faire ce que tu veux, en plus de la superimposition de la Megadrive.
De souvenir: Une démo du SuperVDP

* sans parler de l'audio en PWM.

[Stef]

Oui toi tu parle d'impressionner les programmeurs.
Mais si tu veux convaincre des joueurs ca sera bien plus convaincant et ca fera beaucoup moins tache dans le catalogue sur des machines qui sont justement deja en galère pour faire un simple scrolling ou bouger un sprite mais qui par contre sont plus a l'aise pour du raycasting. Y a moyen de séduire des joueurs (du coup ca peut etre gratifiant) alors qu'avec du raycasting sur NES ou SNES aucun joueur n'en veut comparé au reste du catalogue y a un gouffre visuel. C'est juste un défi de programmation personnel (ce qui est bien aussi mais c'est un autre delire).

L'attrait de la 3D au début c'était aussi un peu cette (fausse impression de) liberté d'exploration... Dans Toy Story, il faut admettre que ça a été très bien réalisé, visuellement ce n'est pas moche, c'est fluide, ça donne une ambiance un peu oppressante de déambuler dans ce labyrinthe un peu sombre. Ils n'ont pas fait trop durer le moment non plus et puis techniquement je pense que même un joueur lambda (sans être programmeur) était assez impressionné.
C'est vrai que sur des machines à base de frame buffer ce genre de jeux avaient plus de sens, surtout qu'ils étaient incapables de produire des jeux 2D convenables donc ça aurait été effectivement une solution. Mais ce genre de jeux est apparu sur le tard, début 1990 au mieux... et à cette époque les machines dont tu parles étaient déjà limite en fin de vie.