P.T. sur PC : vérifier le port natif C++/Vulkan relayé par Kojima

Une démonstration vidéo de trente minutes accompagne le port PC de P.T. développé par LoreanXavier, également connu sous le nom de Lorean The Gamer. Son ambition technique est de reconstruire la démo pour Windows en C++, avec un rendu Vulkan, sans émuler la PlayStation 4. Cette vidéo documente une séquence jouable. L’architecture du programme et sa fidélité au comportement original demandent d’autres vérifications.

Hideo Kojima a relayé un article consacré au projet sur ses comptes X anglais et japonais. Ce partage donne une visibilité importante au travail du développeur, sans constituer une certification technique. Pour évaluer le port, les éléments décisifs restent le fonctionnement du binaire, les ressources qu’il charge et la reproduction des séquences sensibles de la démo.

Table des matières (12)

Ce que le port de P.T. cherche à reconstruire

Sorti sur PS4 en août 2014, P.T. était le teaser jouable de Silent Hills, le projet dirigé par Hideo Kojima avec Norman Reedus. La démo a été retirée du PlayStation Store en 2015 après l’annulation du jeu par Konami. Le travail de LoreanXavier porte sur cette démo originale. Il s’agit d’un projet de fan, sans publication officielle de Konami.

La méthode annoncée part de la rétro-ingénierie de l’exécutable PS4 pour reconstruire la logique en C++ et réécrire le rendu avec Vulkan. Les niveaux, modèles, textures, sons, scripts et cinématiques sont lus à l’exécution depuis la copie personnelle du joueur. Le port ne fournit aucune de ces ressources originales.

Le développeur a communiqué un avancement d’environ 97 %. Ce pourcentage représente son estimation du travail accompli : il ne quantifie pas le nombre de comportements correctement reproduits. L’objectif annoncé de fidélité « 1:1 » englobe les scripts Lua, les boucles du couloir, les événements, la progression, le puzzle final et sa séquence de reconnaissance vocale. Chacun de ces éléments constitue un point de contrôle.

Ce projet a une histoire. LoreanXavier avait déjà publié des solutions de contournement pour faire tourner P.T. sur l’émulateur shadPS4, ainsi que sur ModDB. Le passage à un port natif est donc un choix délibéré de quelqu’un qui connaît les limites de l’émulation sur ce titre précis. Le dataminer Lance McDonald, connu pour ses fouilles dans les entrailles de P.T., a décrit le résultat comme un portage 1:1 de l’ensemble du code, jusqu’aux comportements non documentés. Le développeur précise de son côté n’avoir utilisé l’IA que pour déboguer lorsqu’il était bloqué. Cette caution reste une évaluation experte et non un audit public. Elle donne toutefois une direction claire aux tests décrits plus bas.

Élément	Caractéristique annoncée	Conséquence pratique
Développeur	LoreanXavier / Lorean The Gamer	Identifier précisément l’auteur et la version du binaire examiné.
Plateformes visées	Windows 10/11 ; Linux x86-64 et Steam Deck également visés	Contrôler les dépendances et les pilotes nécessaires avant le lancement, plateforme par plateforme.
Logique et rendu	Reconstruction en C++ ; rendu Vulkan	Vérifier séparément l’architecture du programme et son comportement.
Données originales	Fournies par le joueur depuis sa propre copie de P.T.	La possession du programme PC ne suffit pas à constituer une installation complète.
Commandes	Clavier-souris et manettes modernes	Tester les interactions et le périphérique utilisé. Aucune liste exhaustive de manettes n’est précisée.
Reconstruction d’image	AMD FSR 3.1, NVIDIA DLSS et XeSS selon le matériel	Relever les modes réellement présents. La version de DLSS et la génération d’images restent à préciser.
Cadence	Cible de 60 i/s ; fréquences d’affichage plus élevées également prises en charge	Mesurer la régularité du rendu et contrôler les scripts à différentes limites.
Configuration matérielle	Carte graphique compatible Vulkan 1.3 ; microphone pour la séquence vocale ; minimum CPU, RAM et stockage non précisés	Aucune recommandation de CPU, de RAM ou d’espace disque ne peut être déduite.

Port natif, émulation et remake : les différences vérifiables

Un exécutable Windows, des textures originales et une sortie Vulkan restent des indices incomplets. Un émulateur peut lui aussi être écrit en C++, utiliser Vulkan et charger les données du jeu. Pour distinguer les approches, il faut examiner la chaîne entière, du lancement jusqu’à l’exécution de la logique.

Approche	Fonctionnement	Vérification utile	Limite
Port natif revendiqué	Logique reconstruite pour PC, rendu Vulkan et données originales.	Binaire autonome, dépendances documentées et absence de couche d’émulation PS4.	Une reconstruction peut modifier des timings ou des comportements.
Émulation PS4	Exécution du programme original au travers d’une couche reproduisant les services de la console.	Présence de composants d’émulation et exécution de code destiné à la PS4.	Vulkan peut servir de moteur de rendu à l’émulateur.
Remake	Recréation des scènes et de leur logique dans une nouvelle implémentation.	Examiner le moteur, l’origine des scripts et la méthode de reconstruction.	Une image proche peut masquer une progression ou des interactions différentes.

La rétro-ingénierie ne signifie pas que le code source original a été récupéré. Elle consiste à analyser un programme compilé pour reconstruire son fonctionnement. La fidélité se juge donc sur les conditions de déclenchement, les collisions et les états internes, au-delà de la ressemblance du couloir.

Le cas de P.T. rend cette distinction particulièrement concrète. Avec l’émulation, le code PS4 original tourne tel quel : ses bizarreries sont préservées par construction, mais chaque service de la console doit être imité correctement. Avec un port natif, ces services disparaissent. En contrepartie, chaque fonction du moteur original doit avoir été comprise puis réécrite. Les deux approches peuvent échouer, mais pas de la même façon. Une émulation imparfaite produit plutôt des plantages, des artefacts graphiques ou des ralentissements. Une reconstruction imparfaite produit plutôt des écarts discrets : un événement qui se déclenche une seconde trop tôt, une porte qui réagit différemment, une condition de progression légèrement assouplie.

La liste de contrôle pour établir le caractère natif

1. Identifier le binaire et son processus de compilation

Avant tout test, consignez le numéro de version, la provenance du fichier et son empreinte cryptographique. Comparez cette empreinte à celle publiée par le développeur, si elle existe. Une empreinte calculée localement sert à identifier le fichier, mais elle ne suffit pas à garantir son authenticité.

Si le code est accessible, recherchez le compilateur utilisé, les options de compilation, les dépendances et le commit correspondant au binaire. Une procédure reproductible permet de relier le programme exécuté à l’implémentation décrite. Il faut aussi déterminer quels composants sont reconstruits : rendu, scripts, audio, entrées, sauvegardes et reconnaissance vocale.

La question n’a rien d’académique. Plusieurs fans ont demandé que le projet passe en open source, précisément pour qu’il survive à une éventuelle action liée au droit d’auteur. Un dépôt public, compilable par n’importe qui, rendrait aussi la vérification beaucoup plus simple. Tant que les éléments de build ne sont pas publiés, chaque contrôle porte sur un binaire précis, et ses conclusions ne s’étendent pas automatiquement aux versions suivantes.

2. Observer les processus et les fichiers chargés

Le Gestionnaire des tâches et Process Monitor permettent d’observer le processus lancé, ses éventuels processus enfants et les fichiers auxquels il accède. Recherchez un environnement d’émulation, des modules associés ou une demande de firmware PS4. L’absence de second processus reste un indice limité, car une couche d’émulation peut être intégrée au même exécutable.

Après l’extraction initiale, une vérification utile consiste à isoler les exécutables et fichiers système PS4, tout en conservant les ressources requises par le port et une sauvegarde intacte de l’installation. Le programme doit fonctionner avec les données attendues, sans dépendre d’un environnement PlayStation. Ce test doit respecter la procédure documentée par le développeur, afin de ne pas retirer un fichier de données nécessaire.

3. Vérifier le chemin de rendu Vulkan

Une capture RenderDoc, lorsque le programme l’autorise, peut montrer les commandes Vulkan, les ressources graphiques et les passes de rendu. L’inventaire des bibliothèques complète cette observation. La présence d’un fichier portant le nom Vulkan ne démontre ni l’utilisation effective de l’API ni l’absence d’émulation.

Le niveau d’API requis est aussi un indice exploitable. Le projet exige une carte graphique compatible Vulkan 1.3. Si l’outil de capture affiche une instance créée directement par l’exécutable PC, avec des passes cohérentes avec une scène de couloir plutôt qu’avec une couche de traduction générique, le dossier se renforce. L’inverse, des structures qui évoquent la traduction systématique d’appels graphiques propres à la console, justifierait un examen plus poussé.

4. Relier les données du joueur au code reconstruit

C’est le point le plus subtil du pipeline. Les scripts Lua de P.T. sont lus depuis la copie du joueur : la description des événements provient donc bien des fichiers originaux. Mais un script ne fait rien seul. Il appelle des fonctions du moteur pour ouvrir une porte, jouer un son, déplacer Lisa ou tester une condition. Dans un port natif, toutes ces fonctions ont été réécrites en C++. La fidélité dépend alors de la précision avec laquelle chacune reproduit l’original : mêmes paramètres, mêmes valeurs de retour, même ordre d’exécution.

C’est pourquoi la phrase « utilise les assets originaux » garantit la fidélité des données, sans prouver celle de la logique. De même, « C++ et Vulkan » décrit une technologie de portage, pas une preuve de conformité au comportement PS4. Les tests de fidélité décrits plus loin servent justement à combler l’écart entre ces deux affirmations.

Le dossier le plus solide associe une architecture documentée, un binaire PC autonome, des dépendances examinées et des traces cohérentes avec la logique reconstruite. Aucun test visuel isolé ne remplace cet ensemble.

FSR 3.1 et DLSS : contrôler les options effectivement intégrées

Le projet annonce FSR 3.1, DLSS et XeSS selon le matériel. Le menu doit préciser les modes disponibles, la résolution de sortie et, idéalement, la résolution de rendu interne. La version exacte de DLSS, le runtime livré et les GPU pris en charge sont également à relever. Aucune génération d’images ne doit être déduite du seul nom de ces technologies.

Deux notions doivent rester distinctes. L’exécution native sous Windows décrit l’architecture du programme. Le rendu en résolution native décrit la résolution à laquelle l’image est calculée. Un port natif peut parfaitement utiliser une reconstruction d’image à partir d’une résolution inférieure.

Le port propose aussi un préréglage qui reproduit les réglages de la PS4. C’est lui qui doit servir de point de départ à toute comparaison de fidélité. Les options de rendu amélioré, y compris le ray tracing, réservé au matériel qui prend en charge les ray queries, modifient l’apparence de la scène. Elles ne constituent pas l’expérience visuelle par défaut de la console. Le développeur indique d’ailleurs traiter à part les différences graphiques restantes : l’image peut encore s’écarter de l’original même quand la logique est conforme.

• Établir une référence : partir du préréglage PS4, conserver une résolution de sortie fixe, et désactiver la reconstruction d’image ainsi que toute génération d’images disponible. Cette capture sert de base aux comparaisons.
• Modifier un seul réglage : activer successivement les modes FSR, DLSS ou XeSS réellement proposés, en notant la résolution interne lorsqu’elle est accessible. Comparer le temps GPU sur la même séquence.
• Examiner l’image en mouvement : surveiller les contours dans l’obscurité, les transparences, le grain et les mouvements rapides de caméra. Une capture immobile révèle mal les traînées ou l’instabilité temporelle.
• Isoler la génération d’images : si une option explicite existe, la tester séparément. Les images affichées, la cadence de simulation et la latence de commande doivent être évaluées indépendamment.

Le couloir de P.T. est un terrain difficile pour ces technologies. Les scènes sont très sombres, la lumière vacille et le grain de l’image participe à l’ambiance. Les algorithmes de reconstruction temporelle peuvent lisser ce grain, faire scintiller les zones peu éclairées ou laisser des traînées derrière une silhouette qui bouge à la limite du champ de vision. Dans un jeu qui repose sur ce que le joueur croit apercevoir, ces artefacts ne sont pas anodins : un mode qui gomme une ombre change ce que l’on voit.

Une charge GPU presque inchangée après activation d’un mode ne prouve pas qu’il est inactif : une limite CPU ou un plafond d’images par seconde peut masquer le gain. Il faut examiner la résolution interne et les temps GPU avant de conclure.

Mesurer les performances sans se limiter au compteur d’images

À 60 i/s, chaque image dispose d’environ 16,67 ms. À 30 i/s, ce budget atteint 33,33 ms. Ces valeurs servent de repères et ne constituent pas des résultats mesurés sur ce port. Une moyenne de 60 i/s peut masquer des pointes de temps d’image suffisamment longues pour perturber les déplacements ou les transitions.

Un protocole reproductible peut retenir une séquence de cinq minutes, répétée trois fois, avec le même parcours et les mêmes événements. Consignez le premier passage puis les suivants, en notant l’état du cache de shaders. PresentMon ou CapFrameX permettent de relever les temps d’image, les moyennes, les 1 % low et les 0,1 % low, c’est-à-dire les cadences atteintes pendant les 1 % et 0,1 % d’images les plus lentes. Les séquences et durées doivent rester identiques pour que les comparaisons aient un sens.

• Résolution : comparer 720p, 1080p, 1440p et 4K lorsque ces modes sont accessibles. Si le temps d’image varie peu malgré la baisse de résolution, la limite se trouve probablement ailleurs que dans le rendu GPU.
• Compilation et chargements : relever le lancement, les transitions de boucle et les saccades du premier passage. Une amélioration aux passages suivants mérite une investigation du cache de shaders.
• Mémoire : relever RAM et VRAM sur le même parcours, puis comparer les modes de reconstruction. Une hausse persistante doit être distinguée d’un chargement ponctuel de ressources.
• Stabilité : tester la perte de focus, le changement de résolution et la déconnexion d’une manette ou du périphérique audio. La fluidité habituelle ne renseigne pas sur ces interruptions.

Le framerate déplafonné mérite un passage séparé. Une charge GPU accrue peut augmenter la consommation, la température et la ventilation sans bénéfice pratique sur l’écran utilisé. Le plafond retenu doit ensuite être validé sur une session prolongée, en surveillant les temps d’image plutôt que le seul maximum atteint.

Les transitions de boucle sont le moment à surveiller en priorité. Dans P.T., franchir la porte du fond ramène le joueur au début du couloir, légèrement transformé. Une saccade à cet instant précis peut trahir un chargement mal géré. Elle peut aussi casser l’effet de continuité sur lequel repose toute la démo. Mieux vaut un plafond plus bas et des temps d’image réguliers qu’un compteur impressionnant ponctué d’accrocs au pire endroit.

La fidélité se joue dans les scripts, l’audio et le puzzle final

Les ressources originales peuvent préserver l’apparence des lieux tout en cohabitant avec une logique différente. Pour tester la promesse de reproduction intégrale, il faut comparer les mêmes actions à une référence PS4, avec des conditions de départ contrôlées. Les événements sensibles exigent davantage qu’un parcours unique jusqu’à la fin.

• Boucles et interactions : vérifier l’ordre des événements, l’état des portes et le déclenchement de la radio ou du téléphone. Consigner les conditions exactes d’activation.
• Lisa et collisions : comparer les apparitions, déplacements, sons et réactions aux actions du joueur. Une position similaire sur une capture ne suffit pas à valider le script.
• Cadence et simulation : répéter les séquences à 30 i/s, à 60 i/s et à une limite supérieure si elle est proposée. Mesurer les délais en secondes pour détecter une logique dépendante du temps d’image.
• Audio spatial : examiner la direction, le volume et le déclenchement des sons. Une modification du mixage peut altérer les indices de progression.
• Reprise : contrôler les états conservés après une fermeture normale, puis après une interruption du programme, si une sauvegarde ou un checkpoint est présent.

Le test de cadence est sans doute le plus révélateur. Beaucoup de jeux conçus pour la console lient discrètement certains calculs à la durée d’une image. Quand la cadence change, des minuteurs se raccourcissent, des animations s’accélèrent ou des collisions deviennent permissives. Un port qui autorise des fréquences supérieures à l’original doit soit découpler sa simulation du rendu, soit reproduire fidèlement l’ancien couplage. Comparer la durée d’un même événement à 30 i/s puis au-delà de 60 i/s montre immédiatement laquelle de ces voies a été choisie, et si elle tient.

La reconnaissance vocale demande son propre protocole : microphone sélectionné dans Windows, niveau d’entrée, langue utilisée, bruit de fond et délai de détection. Un microphone est nécessaire pour cette séquence. Tester aussi un microphone absent ou désactivé permet de comprendre les conditions de déclenchement. La vidéo de gameplay montre que la fin de la démo est atteignable, puzzle vocal compris. Atteindre la fin confirme qu’un chemin fonctionne, sans démontrer que toutes les conditions de la version PS4 sont reproduites.

Pour les événements scriptés, une capture à cadence fixe permet une comparaison temporelle. Il faut distinguer le délai de simulation, le délai de présentation et les variations dues aux commandes. L’éclairage, le post-traitement et la colorimétrie se comparent séparément : corriger une différence visuelle ne garantit pas la conformité d’un événement.

Mode photo, VR, Game+ : des bonus à écarter des tests de référence

Le port ne se contente pas de reproduire. Il ajoute un mode photo, une caméra libre, un navigateur de boucles, un musée, un chronomètre de speedrun, un Game+ et des modes expérimentaux à la troisième personne ou en réalité virtuelle. Pour un archiviste ou un chasseur de secrets, la caméra libre et le navigateur de boucles sont des outils précieux : ils permettent d’inspecter le couloir sous des angles que la PS4 n’a jamais autorisés, et de retrouver rapidement une boucle précise pour la comparer.

Ces ajouts ne doivent pas être confondus avec le comportement original. Une vue à la troisième personne modifie forcément ce que le joueur voit et le moment où il le voit, dans une démo bâtie sur le cadrage subjectif. La VR transforme la perception de l’espace et ne garantit pas une restitution équivalente à l’expérience PS4. Le chronomètre et le Game+ changent la manière de jouer, pas le contenu, mais ils ajoutent du code qui n’existait pas. La règle est simple : toute session de vérification se fait avec ces options désactivées et le préréglage PS4 actif. Les bonus s’évaluent ensuite, pour ce qu’ils sont.

Intérêt pratique et limites actuelles

L’intérêt principal est évident pour quiconque a raté P.T. en 2014 : rendre à nouveau jouable un teaser retiré du PlayStation Store en 2015, sans devoir garder précieusement une PS4 sur laquelle la démo est restée installée. Sur le plan de la fidélité fonctionnelle, la promesse est ambitieuse et bien ciblée. Le projet conserve la maison, les contenus originaux, les scripts Lua, les boucles du couloir, les événements, la progression, la séquence vocale et l’énigme finale. L’avis de Lance McDonald pèse lourd dans ce dossier, venant de quelqu’un qui a passé des années à disséquer le code de la démo.

Les limites sont tout aussi concrètes. La première, et la plus importante : il faut posséder et extraire sa propre copie PS4. Le port ne s’installe pas comme un jeu autonome et ne résout donc pas entièrement la disparition commerciale de P.T.. Ceux qui n’ont jamais téléchargé la démo restent à la porte du couloir. Viennent ensuite les exigences techniques : un système compatible, une carte graphique Vulkan 1.3, un microphone pour le puzzle vocal et, pour le ray tracing, un matériel qui prend en charge les ray queries. Une partie des joueurs peut s’en trouver exclue.

Le statut du projet constitue la dernière limite. Il est non officiel, n’est affilié ni à Konami ni à Kojima Productions, et n’a pas été approuvé par l’éditeur. Le relais de Hideo Kojima sur X reste un partage d’article, pas une validation technique ni un aval de l’ayant droit. Son avenir n’est pas garanti, ce qui explique les appels de la communauté à ouvrir le code. Enfin, des différences graphiques subsistent, et le développeur les traite à part. Ceux qui recherchent l’image exacte de 2014 doivent donc s’en tenir au préréglage PS4 et garder un œil critique sur l’éclairage.