[INFO] Les options d'émulation

Bonjour à tous,

Vous l'avez surement déjà vu, vous avez probablement déjà bidouillé sans voir de différence, je parle évidemment des options d'émulation présent sur PrBoom+/DSDA.
Par défaut, il ressemble à ça



Beaucoup de joueurs n'y touchent pas, par méconnaissance et/ou par peur de tout péter, et pourtant votre run et votre démo peut en dépendre. L'une des ces options et particulièrement importante sur les maps de Wilou, les connaisseurs sauront laquelle.
Heureusement, votre serviteur est là pour tout vous expliquer.

Qu'est-ce que c'est ces "Emulation" ?

Ce n'est un secret pour personne, Doom à l'origine contenait des bugs, de par sa programmation et en partie dû au langage qu'il utilisait à l'époque : le langage C.
Ces options d'émulation permettent de reproduire ces bugs particuliers, l'un d'eux a également servi dans des speedrun, vous avez surement déjà expérimenté ce même bug, vu qu'il est activé par défaut.

Warn on.../Try to emulate it

Vous l'avez vu dans le screen, une option commençant par "Warn on" est suivi d'une autre appelé "Try to emulate it". C'est bizarre, mais en fait c'est très simple :
L'option précédé de "Warn on" fait apparaître une popup lorsque le bug peut se déclencher, et c'est l'option qui suit (Try to emulate it) qui défini si on l'"émule" ou non.

Par exemple, si je déclenche un "spechits overflow" (on expliquera juste après ce que c'est) avec l'option Warn on... activé, mais sans l'émulation, ça donne ça :

Quand je disais que votre démo peut en dépendre... C'est pas moi, c'est PrBoom+ qui le dit

Heureusement, votre jeu se met en pause lorsque ça arrive. Ces options de warn on sont très pratique lorsque vous mapper du vanilla pour repérer les bugs "invisible" qui pourraient potentiellement casser votre map.

Je le rappelle, le "Warn on" ne déclenche pas le bug, il vous préviens simplement qu'en vanilla, il se déclenchera et le "Try to emulate it", si il est activé, le déclenchera.

Le détail

Bien, le vif du sujet, on va interroger notre cher DoomWiki, les différentes ressources et l'expérimentation dans notre Ultimate Doom Builder puis, tenter synthétiser tout ça

SpecHits Overflow : Un SpecHits Overflow se produit lorsqu’un joueur ou monstre traverse et active plus de 8 "linedefs spéciaux" (des WR ou des W1 par exemple, bref, des linedefs déclenchant des actions) simultanément.

Techniquement, le "tableau" (les cases dans la mémoire qui stock les actions pendant 1 tick) associé au joueur ou monstre ne peut contenir que 8 actions, et si on déborde, bah on déborde sur les cases mémoire suivante.

Cela entraîne le déclenchement d’autres "linedefs spéciaux", ainsi que la non-vérification d’autres linedefs. En fin de compte, cela peut conduire à des désynchronisations de démo. Par exemple, dans le cas de la map pour produire ce bug pour le screen, j'ai fait quelque chose comme ça :

Les lignes vertes, sont des linedefs de téléporteur, ceux du haut, du milieu et du bas téléporte à plusieurs endroits différents

La conséquence du bug c'est quoi ?
Le risque est que les arachnotrons, si ils sont dans l'incapacité de passer le TP (car la place est prise à l'autre bout, et donc ne va pas déclencher les linedefs) vont continuer leur chemin. Et lorsque la place sera libre, ils se retrouveront au milieu de pleins de linedefs qui vont s'activé en même temps (+ de 8 ).
Le bugs se déclenche, et vont se retrouver à déclencher un linedefs qu'il ne touche pas, donc il risque de se TP à la destination d'un autre linedef TP, et c'est le début de la desync.

Reject overflow

Celui ci, qu'on pourrait appeler "bug des monstres aveugles" est assez technique. Il va être difficile celui là.

Le tableau de REJECT est une ressource d'une map pour optimiser le calcul de savoir si un joueur visible par un monstre, car un vrai calcul en temps réel prendrait trop de ressources aux PC de l'époque, donc on simplifie et on "précalcule" les lignes de visée direct.
En début de map, les monstres sont dans des états « endormis ». Ils peuvent se réveiller en « voyant » le joueur ou par le son (comme le joueur tirant près d’eux). Le tableau REJECT permet à Doom de déterminer quand il est impossible pour les monstres de voir les joueurs. Celui-ci est généré à la compilation de la map, et compose un tableau .

Heureusement, l'auteur de cet article du DoomWiki a fait un petit tableau :


Ceci est une table, d'une map contenant 5 secteurs, numéroté de 0 à 4.
Alors:
Sur l'axe verticale : Cas où un monstre ce trouve dans ce secteur (identifié par son numéro)
Sur l'axe horizontal : Cas où le joueur se trouve dans ce secteur

Lorsqu'on croise les valeurs, on obtient 1 ou 0 :
1 : Ces deux secteurs ne peuvent pas "se voir", donc on en reste là et on passe au suivant. (par exemple, le joueur est dans le secteur 4, et un monstre dans le secteur 1)
0 : Ces deux secteurs peuvent "se voir", dans ce cas, le calcul complexe qu'on souhaitait éviter faire en temps réel, se fait, et détermine précisément si le joueur est visible ou non

Et l'overflow dans tout ça ?

Globalement, cela se produit lorsqu'un secteur ne figure pas la table, tout ce qui se trouve en mémoire après le tableau de REJECT sera utilisé comme valeur, ce qui peut causer des angles morts alors que vous êtes visible, ou vous faire voir alors que vous ne l'êtes pas. C'est devenu quelque chose de très rare car les builder moderne font un bon travail, mais il est possible de modifier cette table et de créer un petit effet spécial en passant les valeurs de REJECT à 1 pour les secteurs voulu, comme sur la map02 de Requiem dont ses pinky restent immobile, ce qui est plutôt stylé:


Intercept Overflow

Celui là est le plus connu, et je me déteste d'avoir joué à des maps à Wilou avec l'émulation de ce bug activé.
Alors qu'est-ce que c'est et qu'est-ce qui se passe ?

Lorsque vous tirer un projectile hitscan (pistol, shotgun, SSG, chaingun...), un "rayon" est lancé de votre joueur, jusqu'à la portée maximum, en traversant mur, things, monstres. De là, un "tableau" de 128 cases mémoire se créer.

A chaque fois qu'un rayon rencontre un obstacle, on rajoute cette entité ou mur dans le tableau. Et vous l'aurez deviné, si le rayon traverse plus de 128 obstacles, on va écrire dans d'autres cases mémoire :
l'overflow commence, possible que ce soit sans conséquences si vous dépasser de quelques uns seulement. Arrivé à un certains nombres, vous écrivez dans les cases mémoires de la "block map" : cette grille sert à calculer les collisions, dont celles des projectiles, et là, c'est la foire à la saucisse : vous, vos balles, celles des monstres traversent tout, y compris les murs, et votre partie est ruiné. Seul une sauvegarde peut la sauver ou si un "damaging floor and exit" est présent sur la carte (bravo, vous avez gagné votre speedrun dans ce cas).

La video de Decino explique très bien ce phénomène :


PlayerInGame overflow

Celui-ci on pourrait l'appeler le "bug du joueur zombie".
Dans les faits, celui-ci ne se produit en théorie qu'en multijoueur :
Quand un joueur meurt, un "nouveau joueur" devrait être créer et apparaître à un spawn, Doom vérifie si l'emplacement de spawn est valide, c'est à dire, pas trop près d'un angle de mur, si il considère que c'est trop près, il va refuser de le faire spawn à cet endroit.
Et si tout les spawn sont bloqué ?
Il va utiliser les spawn du joueur solo/ccop. Bloqué aussi ?!
Le joueur mort tente de réapparaître, mais Doom n'arrive pas à créer un nouveau marine tout neuf avec 100% de vie pour mettre le joueur dedans, du coup, le joueur réapparaît dans son propre corps mort à 0% et dans l'état mort. Doom le considère en vie, et peut se déplacer et ouvrir les portes, mais son cadavre court sur le sol.

C'est peut-être inexact car très technique (et car j'essaye de synthétiser), les infos sur ce bug sont très rare, tellement qu'il n'y a pas d'infos dessus sur le DoomWiki.

Donut overflow

Cas très spécifique, et pas le plus passionnant :
Lorsque vous utilisez le lindefs special 9 (Floor raise donut), si votre numéro de linedefs le plus petit (qu'on va appeler "linedef X") situé à l'extérieur de votre piscine (c'est comme ça que s'utilise le donut), un emplacement de mémoire est alloué pour la hauteur de votre secteur qui correspond à la "sortie de piscine".
Ca c'est le cas standard.
Mais si votre linedef X, n'a qu'un seul côté (celui dont la face, est face à la "piscine"), Doom va écrire à l'emplacement de mémoire où est censé être cette hauteur. En général, votre pièce s'effondre.

MissedBackside overflow

Je n'ai pas trouvé d'infos sur celui-ci, j'ai bien une théorie mais il me faudrait un vieux Doom builder un peu plus permissif...
Ce qui est certain c'est que ce type de bug est similaire aux autres : une écriture dans des adresses mémoire non autorisé, résultant un comportement inattendu.
Car au final, un "bug", c'est ça : un comportement inattendu

Si je trouve la réponse un jour, ou si vous même l'avait, je l'ajouterai à cet article.

----------------------------------------------------

Désolé, mais je n'ai pas pu faire un article complet pour une fois.
En tout cas, au cours de mes recherches, j'ai découvert que les deux dernières émulations de bugs ajouté à PrBoom+ ont été ajouté assez tardivement, tellement ceux-ci sont anecdotiques. Ils sont plutôt présent pour les mappeurs en guise de "test de validation" car, si certains peuvent être utilisé car nécessaire à la lecture de démo particulière ou assurer une compatibilité de sa demo sur Doom vanilla, les deux derniers sont plus pour ceux utilisant de vieux Doom builder permettant les erreurs de mapping de ce genre qui rendrait de toute manière la map injouable.

Si des infos vous paraissent inexact, du à une mauvaise compréhension ou une mauvaise synthèse de ma part, faite le savoir et je corrigerais