Gaming : des modders parviennent à décompiler Super Mario 64 et à publier le code en C grâce à un oubli de Nintendo

Le 28/08/2019 à 21:20

Qu’en pensez-vous ?

Qu'il faut le télécharger rapidement parce Nintendo va vite réagir dès qu'il va en avoir connaissance

11

1

Kannagi

Expert éminent sénior

Le 29/08/2019 à 9:23

Envoyé par Patrick Ruiz

[
« Vous pouvez compiler ces contenus en l’état et obtenir une ROM Super Mario 64 fonctionnelle », ont indiqué les modders. Des chaînes d’outils modernes comme gcc permettent d’y parvenir. D’ailleurs, des preuves de concept sont déjà disponibles.

Il faut juste prévenir que c'est juste illégal , et il me semble que les regles de ce forum sont assez clair sur le piratage

Envoyé par Patrick Ruiz

[
Les modders expliquent qu’ils y sont parvenus parce que Nintendo n’a pas activé les optimisations lors de la compilation. La manœuvre permet pourtant aux éditeurs de jeux vidéos de réduire la taille du code source et d’obscurcir sa structure. Les développeurs de l’éditeur japonais ont plutôt compilé sans le flag -O pour obtenir le binaire que la console exécute. En s'appuyant sur cette omission, les modders n’ont eu qu’à lire le code assembleur et à réécrire les fonctions qu’ils ont par la suite passées au test jusqu’à parvenir à une ROM fonctionnelle.

Je trouve ça étonnant qu'il n'y a pas eu d'option pour l'optimisation , il est probable qu'il ne les ont pas mis parce que le compilo bug quand on met une optimisation (cela m'est deja arrivé sur certaine ancienne consoles !).
Je m'attendais à plus de code asm (après j'ai pas tout lu) , le MIPS d'ancienne génération (avec j'imagine un compilo de la fin des années 90) , j'aurais imaginé beaucoup plus de code asm !

Pour le code source C , je le trouve assez classic , mais l'idée de rotation xyz + translation sur la même matrice est intéressante !

7

0

Ryu2000

Membre extrêmement actif

Le 29/08/2019 à 9:59

Envoyé par Patrick Ruiz

Qu’en pensez-vous ?

C'est génial ! Les Tools Assisted Speedrunners vont pouvoir comprendre ce qu'il se passe vraiment dans le code quand ils exploitent des bugs et ils vont peut-être pouvoir en trouver d'autres.

3

0

Zuthos

Membre habitué

Le 05/09/2019 à 14:16

les modders n’ont eu qu’à lire le code assembleur et à réécrire les fonctions

Ca a l'air tout simple de lire de l'assembleur!!

3

0

Kannagi

Expert éminent sénior

Le 29/08/2019 à 18:49

Envoyé par floyer

J'avais trouvé le principe dans les années 80 dans la revue Micro-système qui malheureusement n'est plus édité. Il y avait un dossier spécial sur la 3D.

Le principe consiste à appliquer des matrice 4x4 sur un vecteur (x y z 1). Le 1 peut servir à ajouter une constante aux coordonnées. Par ailleurs, si un vecteur (x y z d) code des coordonnées (x/d, y/d, z/d), on peut aussi en changeant "d" obtenir une projection à une certaine focale avec une matrice ad'hoc, mais c'est anecdotique. (on doit faire la division séparément de toute manière, et entre la faire avec "z" ou "d", cela ne change pas grand chose.

C'est la base de la 3D actuelle , des matrices 4x4.
Ensuite oui on fait la division , j'imagine que dans les années 80 avant l'explosion d'internet ce genre d'info est cool à avoir

Mais les machines suivante à la N64 , il y avait des instructions pour ça par exemple la Dreamcast avait une instruction Matrice*vecteur pour 4 cycles !
La PS2 ces VU était plus violent ,tout pouvait aller sur un cycle donc tu avait la transformation complète (avec la division) pour 8 cycles !
( 4 instructions de vecteur*vecteur équivalent à Matrice* vecteur , une division et ensuite la multiplication (w*vecteur) ).

Pour faire simple la PS1 et la Saturn bossait avec des nombres fix

La PS1 c'était des matrices 3x3 en fix16 (oui oui de la 3D avec du 16 bits en virgule fixe !) , mais c'est un coprocesseur qui s'en occupait de ces calculs.
La N64 avait un vrai FPU et un micro code pour optimiser le rendu 3D.

Envoyé par Bousk

C'est pas un quaternion ?

Vu le code ça ne semble pas , ça ressemble aux 3 rotationXYZ + translation additionner:

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void mtxf_rotate_zxy_and_translate(Mat4 dest, Vec3f translate, Vec3s rotate) {
    register f32 sx = sins(rotate[0]);
    register f32 cx = coss(rotate[0]);

    register f32 sy = sins(rotate[1]);
    register f32 cy = coss(rotate[1]);

    register f32 sz = sins(rotate[2]);
    register f32 cz = coss(rotate[2]);

    dest[0][0] = cy * cz + sx * sy * sz;
    dest[1][0] = -cy * sz + sx * sy * cz;
    dest[2][0] = cx * sy;
    dest[3][0] = translate[0];

    dest[0][1] = cx * sz;
    dest[1][1] = cx * cz;
    dest[2][1] = -sx;
    dest[3][1] = translate[1];

    dest[0][2] = -sy * cz + sx * cy * sz;
    dest[1][2] = sy * sz + sx * cy * cz;
    dest[2][2] = cx * cy;
    dest[3][2] = translate[2];

    dest[0][3] = dest[1][3] = dest[2][3] = 0.0f;
    dest[3][3] = 1.0f;
}

1

0

foetus

Expert éminent sénior

Le 29/08/2019 à 21:59

Envoyé par floyer

Il est peu pertinent de parler de point 1 (quelle coordonnée est 1?) et de vecteur 0 (est-ce 0,0,0,0 ?)

Si c'est important

Un point (u1, v1, w1, 1) + un vecteur (u2, v2, w2, 0), donne un point (u3, v3, w3, 1) (<- note le 1)
Un vecteur (u1, v1, w1, 0) + un vecteur (u2, v2, w2, 0), donne un vecteur (u3, v3, w3, 0) (<- note le 0)
Un point (u1, v1, w1, 1) - un point (u2, v2, w2, 1), donne un vecteur (u3, v3, w3, 0) (<- note le 0)

Un point (u1, v1, w1, 1) + un point (u2, v2, w2, 1) n'a pas de sens (u3, v3, w3, 2) (<- note le 2)

Et ensuite toute matrice affine a comme dernière ligne (la 4ième) (0, 0, 0, 1)
Une matrice de translation T par un vecteur (u, v, w) ressemble à
1, 0, 0, u
0, 1, 0, v
0, 0, 1, w
0, 0, 0, 1

Et note un point (u1, v1, w1, 1) * T fonctionne parce que tu as ce 1 en 4ième (u1 + u, v1 + v, w1 + w, 1), et donne un point.
Mais pour un vecteur (u2, v2, w2, 0), cela donne le même vecteur parce que tu as ce 0 en 4ième (u2 + 0*u, v2 + 0*v, w2 + 0*w, 0) (<- note le 0)

Effectivement, un vecteur ne pas être translaté parce que c'est "juste" une "direction" (édit: et une distance/ coefficient - poids/ ...)

1

0

floyer

Membre éclairé

Le 29/08/2019 à 22:42

Je pense que l’on est assez en phase : tu proposes même la matrice qui représente la translation et me prouve qu’elle fonctionne sur des points représentés par x,y,z,1... mais j’écris qu’un point est représenté par un «*vecteur*» (x,y,z,1) pour deux raisons : Ces 4 coordonnées font parti de R^4 qui est un espace vectoriel, et on lui fait subir des opérations vectorielles : multiplication par des matrices. Que l’addition de deux tels vecteurs n’ait pas de sens n’y change rien.

En fait, il y a deux types de vecteurs : ceux de dimension trois dont les coordonnées sont celles de la translation, et ceux de dimension 4 (que tu appelles points) qui représentent un point. Après on peut ergoter : doit-on dire que ces derniers «*représentent*» un point ou «*est*» un point ? En géométrie projective, les points sont associés à une classe d’équivalence de vecteurs : tout ceux de la forme x.d, y.d, z.d, d. Du coup, représenté me semble préférable s’il n’y a pas unicité. Ceci-dit, appeler (x,y,z,d) un point ne me dérange pas, et c’est sûrement ce que fait le programmeur (qui s’intéresse plus à ce que signifie ses données - ma variable EST un point - qu’à la structure de données). Mais si (x,y,z,d) est appelé un point, cela vaut aussi pour ceux qui sont à l’infini (d=0). Ce sont des points normaux en géométrie projective (et peut-être utile pour placer les étoiles dans le ciel...)

Par contre, je ne sais pas ce qu’est une matrice affine.

Pour moi, une matrice est un tableau de nombres sur laquelle on a défini des opérations... affine n’apporte pas grand chose.

Si tu as un vecteur (u,v,w) de dimension finie la translation d’un point à l’infini (x,y,z,0) te donnera le même point, en effet il restera dans la même direction. C’est assez intuitif... mais pas rigoureux je l’admets. En définissant la translation par la matrice que tu as présenté, cela devient rigoureux.

1

0

Jonathan muswil

Membre à l'essai

Le 01/09/2019 à 16:07

C'est génial !

1

0

floyer

Membre éclairé

Le 29/08/2019 à 15:11

Envoyé par Kannagi

Pour le code source C , je le trouve assez classic , mais l'idée de rotation xyz + translation sur la même matrice est intéressante !

J'avais trouvé le principe dans les années 80 dans la revue Micro-système qui malheureusement n'est plus édité. Il y avait un dossier spécial sur la 3D.

Le principe consiste à appliquer des matrice 4x4 sur un vecteur (x y z 1). Le 1 peut servir à ajouter une constante aux coordonnées. Par ailleurs, si un vecteur (x y z d) code des coordonnées (x/d, y/d, z/d), on peut aussi en changeant "d" obtenir une projection à une certaine focale avec une matrice ad'hoc, mais c'est anecdotique. (on doit faire la division séparément de toute manière, et entre la faire avec "z" ou "d", cela ne change pas grand chose.

0

Bousk

Rédacteur/Modérateur

Le 29/08/2019 à 16:35

C'est pas un quaternion ?

0

Identifiez-vous

Créer un compte

Gaming : des modders parviennent à décompiler Super Mario 64 et à publier le code en C

Grâce à un oubli de Nintendo

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

Gaming : des modders parviennent à décompiler Super Mario 64 et à publier le code en C Grâce à un oubli de Nintendo

Gaming : des modders parviennent à décompiler Super Mario 64 et à publier le code en C

Grâce à un oubli de Nintendo