[RÉSOLU] Pas de musique dans wipeout 2097

[barbarian_bros]

Le 'Patch XP' détecte la présence du CD en testant si la piste 2 (la piste audio 1) est présente.

J'ai testé en créant différentes images-CD (sans les données du jeu pour aller plus vite) :
Si on met les 9 musiques mais pas de piste data, ça marche, mais les musiques sont décalées par rapport à ce qui devrait être entendu dans le jeu (la musique 2 devient la musique 1).
Si on met les 9 musiques avec une piste 1 en data (juste mis un fichier txt) ou en piste audio silencieuse (quelques secondes de blanc), le patch demande le CD.
Si on met les 9 musiques avec avec une piste 1 en data ou en piste audio silencieuse (quelques secondes de blanc) MAIS qu'on a ajouté une demi-seconde de silence au début de la piste 2, le jeu se lance.

Du coup je vois 2 possibilités :
-une version automatique avec injecteur pour lire les musiques en ogg au lieu des musiques CD (peut-être qu'il faudra légèrement modifier la piste 2, donc la 1ere musique).
-le remplacement de l'image du jeu par une version modifiée, faut que je teste la quantité minimale de 'blanc' à ajouter au début de la piste 2 pour que le patch ne demande pas le CD original

[The Uploader]

Je vais prendre l'option 1, car le jeu a besoin de dgVoodoo2 de toutes façons, et j'aime bien que l'image CD corresponde exactement à ce qu'il y avait au départ.

Du coup il doit appeler quand même WINMM.SendCommandA, mais dynamiquement (avec LoadLibrary + GetProcAddress), raison pour laquelle dans le 'patch XP' le seul import de WINMM spécifié est une fonction pour lister les joysticks.

Merci pour tous tes tests, ils sont très utiles pour démêler tout ça.

[barbarian_bros]

Je pense qu'il teste juste une checksum sur le tout début de la piste 2, car une modification même minime fait que ça marche :
Quand on édite la piste, elle commence par 0.2 secondes de blanc avant que la musique commence, supprimer 0.1 seconde de blanc suffit à ce que le Patch XP ne reconnaisse pas le CD et accepte de se lancer.

[willow2]

C'est comme MechWarrior 3, il faut le limiter à 30 FPS.

je crois que DXWND peut faire ça.

Le XP Patch est cracké et n'appelle même plus WINMM.SendCommandA, donc il ne va pas lire les musiques CD.
Il ne lit pas non plus les vidéos MPEG (qui sont sur le CD)

Les vidéos sont lues.

[The Uploader]

Investigations sur mon vieux PC dédié :
- Windows 98 SE : Pas de musiques CD, le nombre d'images par seconde oscille entre 45 et 65. Pas jouable.
- Windows XP SP3 : musiques CD présentes. Nombre d'images par seconde constant à 60. Jouabilité parfaite. Seule ombre au tableau : J'ai dû lancer SETUP.EXE en mode Wn95 pour qu'il accepte d'installer le jeu.

Dans les deux cas: exécutable d'origine, CD gravé et présent dans le premier lecteur optique.

(je suis un peu sur le cul d'avoir trouvé un cas où XP est plus rapide que 98 SE, mais bon...)

[The Uploader]

Voici le XP patch unpacké (il était packé avec UPX 2.93), et un fichier SDB.
Ça s'installe ainsi :

sdbinst wipeout2.sdb

Ça se déinstalle ainsi :

sdbinst -u wipeout2.sdb

sdbinst existe à partir de Windows XP.

Ce fichier SDB ne correspond qu'au fichier "xp patch" unpacké. Ça ne marche pas avec la version d'origine du XP Patch.

Il ne contient que le shim "CorrectCreateSurface".

Investigations supplémentaires avec le XP Patch (et non pas l'exécutable d'origine, comme hier soir) :
- Le jeu se bloque à 30 FPS sous Windows 10, le rendant injouable (nombre de FPS rapporté par Fraps). L'usage de shims telles que EmulateSlowCPU (il semble calculer les perfs avec des appels continuels à WINMM.timeGetTime, mais se limiter à 30 FPS de toutes façons) n'arrangent rien, au contraire.
- Il fonctionne aussi avec ddrawCompat, ou en installant un fichier SDB contenant le shim "CorrectCreateSurface" (le jeu appelle CreateSurface incorrectement, DirectDraw retour DDERROUTOFMEMORY, le jeu plante...)
- J'ai testé le jeu sans avoir le CD monté. D'après API Monitor, il appelle WINMM.mciSendCommandA correctement, mais sur un périphérique multimédia par défaut retourné par WINMM (semble-t-il) -> pas de musique. J'ai pourtant un wrapper WINMM.DLL et les pistes audio en Ogg Vorbis en place. Et c'est bien le wrapper qui est chargé à l'exécution.
Comme pour Motorhead, il va me falloir corriger les appels à l'aide de EasyHook à l'exécution. Oh, joie.

Et pour les FPS, je pense qu'il faudrait réussir à utiliser l'exécutable d'origine. Le XP Patch est trop lent.

[The Uploader]

willow2 :
Voici une solution pour les musiques CD.

Tu décompresse l'archive ci-jointe dans le dossier d'installation du jeu.
Tu montes le CD (l'image corrigée, sous forme de CUE/BIN, disponible sur la fiche du jeu) dans Daemon Tools. Le lecteur émulé par Daemon Tools doit être ton premier lecteur optique.
Tu fais ceci dans l'invite de commandes, dans le dossier du jeu. Exemple avec le dossier du jeu qui serait dans C:\jeux\Wipeout2097 :

Touche Windows et R en même temps.
Taper : "cmd.exe" (sans les ")

Taper :

c:
cd C:\jeux\wipeout2097
sdbinst wipeoutv2.sdb

Répondre oui à la demande d'autorisation.

Lancer le jeu.

Le jeu aura les musiques CD, et une vitesse jouable.

barbarian_bros :
Ce novueau fichier SDB contient :
- CorrectCreateSurface
- CorrectFilePaths
Le fichier Wipeout2.exe dans l'archive n'est rien d'autre que l'exécutable d'origine du jeu. Le fichier SDB s'applique à celui-là spécifiquement.

Le XP Patch a le même comportement sur Windows 10 que sur mon vieux PC (testé sous Windows XP) : limité à 30 FPS donc injouable.

L'exécutable d'origine se lance (grâce à CorrectCreateSurface), et est jouable (limité à 60 FPS au lieu de 30) et lit les musiques CD (grâce à CorrectFilePaths).

Par ailleurs :

J'ai une première version d'un crack qui fonctionne même si on a pas le moindre lecteur optique ou quelque soit l'état des lecteurs optiques.

Les appels à mciSendCommandA sont mauvais du coup (périphérique multimédia incorrect), je vais voir si je peux les corriger ou si je dois passer par EasyHook.

J'ai un cas d'un jeu qui n'a pas eu besoin de EasyHook pour ses musiques CD, c'est Forsaken. Le wrappper WINMM fonctionne bien avec lui. Et il utilise mciSendCommandA. Je vais voir si je peux pas d'abord m'en inspirer pour corriger les appels.

[barbarian_bros]

Concernant la vitesse : Le jeu d'origine tourne normalement à 30FPS... à 60 FPS c'est totalement injouable car ça va 2 fois trop vite (il n'y a qu'à regarder le compte à rebours : les secondes défilent 2fois trop vite du coup il est quasiment impossible de ne pas se prendre un 'time over' ).

Testé pour l'instant :

-Jeu d'origine + CD dans 1er lecteur : plante après l'écran titre

-Jeu d'origine + CD dans 1er lecteur + dgVoodoo : fonctionne avec les musiques, mais 2fois trop rapide (60Fps rapportées par Fraps, compteur de temps qui défile 2 fois trop vite, injouable dès que le turbo s'active)

-Patch XP + CD dans le 1er lecteur + dgVoodoo : demande le CD original.

-Patch XP + dgVoodoo : fonctionne sans musiques. Vitesse presque normale mais un peu saccadé (35FPS rapportées par Fraps).

-Jeu d'origine + CD dans 1er lecteur + dgVoodoo + wipeout2v2.sdb : fonctionne avec les musiques, mais 2fois trop rapide (60Fps rapportées par Fraps, compteur de temps qui défile 2 fois trop vite, injouable dès que le turbo s'active) en fait je vois aucune différence avec le jeu d'origine + dgvoodoo.

[The Uploader]

Bizarre, la version 30 fps est trop lente et pas du tout agréable pour moi, et le FPS varie entre 30 et 45, rendant le contrôle du véhicule impossible et le jeu pas fun.
Mais tu as raison, à 60 fps constant c'est beaucoup mieux au niveau des contrôles mais beaucoup trop dur. Hmmm...

Le fichier SDB ne sert à rien si on utilise dgVoodoo2 ou DdrawCompat (enfin, CorrectCreateSurface ne sert à rien, CorrectFilePath permet aux musiques de fonctionner).

Merci pour tes retours.

J'ai déjà pu copier/coller le bout de code responsable de la limitation à 30 fps sans problème dans ma version crackée. Pour l'instant, j'essaie de corriger nativement les appels à WINMM pour que les musiques CD avec le wrapper fonctionne sans faire appel à EasyHook.

[barbarian_bros]

Ok mais sans dgvoodoo ça plante après l'écran titre, comme le jeu de base sous Windows 10.

Jeu d'origine + CD dans 1er lecteur + wipeout2v2.sdb : plante après l'écran titre.

[The Uploader]

C'est là où CorrectCreateSurface devrait faire son office. C'est l'appel incorrect à DDRAW.CreateSurface qui plante le jeu à ce moment là. Le fichier SDB est-il installé ?

sdbinst wipeouv2v2.sdb

[The Uploader]

barbarian_bros :
J'ai la version crackée du "XP patch" ci-dessous, si ça t'intéresse.

En fait, la version patché limite à 30 FPS, mais en plus n'a pas besoin de dgVoodoo2/ddrawCompat/CorrectCreateSurface (c'est même mauvais), ni de CorrectFilePaths.
Donc, c'est pas mal du tout.

Par contre, cracké ou non,y'a pas de musiques CD. :/

[barbarian_bros]

Avec ou sans "sdbinst wipeout2v2.sdb" ça plante après l'écran titre sous Win10

[barbarian_bros]

Je viens de tester ton patch cracké, même chose : "wipeout2.exe a cessé de fonctionner" dès la fin de l'écran titre.
J'ai même fait une désinstallation/réinstallation au propre pour vérifier.
Sous Win10, si j'utilise pas dgVoodoo je peux pas lancer le jeu.

[The Uploader]

Oups, j'avais encore un de mes SDB installé sans m'en rendre compte.

Ce bug s'enlève dès qu'on utilise ddrawCompat/dgVoodoo2 (je suis sous la dernière version de Windows 10 moi aussi)