Whatever is happening the cdaudio-winmm wrapper is unusable with the original game executable at this point. I thought the game is suspending the threads or the player application but I am not sure. This is difficult to notice when using a real cdaudio disc but it's very noticeable when. What happens is that the music keeps "pausing" unless the mouse cursor is moved all the time. Of course with the Open1560 executable I can use either output device without issues.Īs for cdaudio-winmm it fails to work with the original game executable. Setting the sound quality to low together with the primary audio device results in a game crash and I had to delete "\players\player0.cfg" to get the game running again. However if I select the primary audio device all sounds and music is muted when exiting a race. I have two options and if I leave it set to the default Realtek device the music and sounds seem to work fine. I see the issue with changing the audio device now. For now, I think I will stick with using Open1560, since it has this fixed. Turns out, the problem isn't probably lying in winmm, but instead somewhere in the game, this thing occurs on every winmm wrapper I tested out. Regarding Midtown Madness, I actually enjoy playing the original game over some fan-made remasters/patches, so I wanted to test if this one would fix the bug where the game wouldn't play the music after exiting a race. It is a mistake from my side, I confused some other games with these two.
#MIDTOWN MADNESS 3 DIC WINDOWS#
My bad, I tried out the games on a Windows 98 PC, and the same behaviour exists on both the system. This appears to be the behaviour of the game even when run without mci wrappers using a music cd in the CD-drive. In this case a simple MCI_STOP / MCI_PLAY method is used. However if one alt tabs later on in the actual gameplay part the music does stop and begins again from the beginning of the track with MCI_PLAY when returning to the game. In the main menu of the game if one uses alt+tab the music continues playing.
Here I saw no references to MCI_PAUSE call in the winmm.log. I tested the Shareware version which also supports cdaudio tracks.
#MIDTOWN MADNESS 3 DIC CODE#
This is something I need to look at in the code as it is currently hard coded to return "2001" milliseconds or the first track "1". The second issue with Midtown Madness and the cdaudio-winmm wrapper is that later on when the game tries to play a cdaudio track it queries for the track position and instead of receiving the answer that it expect it always receives "1". This can be done using a ASM jump for all the winmm functions that are meant to be passed to the real winmm.dll. The way to do this in the future would be a more intelligent winmm wrapper that has a pass through for video, etc. The short answer is that the current cdaudio-winmm wrapper is not build to handle this situation and will fail miserably. This means that the game is unable to play videos using MCI and this also results in the error message. The ogg-winmm based wrapper is not equipped to handle pass-through for other devices and intercepts all calls made to the MCI API. Midtown Madness uses the MCI API to play videos in addition to music.
0 kommentar(er)
