Activity for dippy dipper
-
dippy dipper posted a comment on discussion General Discussion
For system emulation are you sure Vmware supports cdaudio? Most virtual machines like VirtualBox do not. The only emulator I know for sure that supports it is PCem.
-
Analog audio lead from a sound card to an IDE drive on a 64-bit Windows system? Seems unlikely. Since you have the original disc could it be that it is an issue with the optical drive letter? E.g. the game could be searching for the disc in the wrong drive letter. Old games can assume that the system has just one optical drive.
-
Sorry, but that analog CD aux theory is nonsense. The music is played from the CD probably through the wail32.dll library. There is also evidence that the original disc plays CD audio fine as per this blog: https://thisoldrecliner.neocities.org/pitfall.html Now I don't have the original disc and I assume you are also using cd images downloaded from the net. So in this case any kind of more complex copy protection requires a cracked pitfall.exe. Things are further complicated by the fact that the...
-
Oh, would you look at that! SourceForges artificial stupidity has eaten my post again.
-
For example the pixels at co-ordinates: 64-65,56 for the window texture come out as RGB 0,0,0. Flood filling the matching colors with magenta produces a pattern that can be seen in-game. Note that not all textures use the same color for transparent pixels. Look at the staircase column and the comparison to the texture. Also some unintentional holes in the texture? Or maybe the house just has a termite problem. Here the transparent color is RGB 206,203,206. (or CECBCE in hex) I feel like the issue...
-
Tested on an even older PC just for fun and it showed no transparent pixel issues with or without the "Suppress DX common errors" flag using "v2_05_71_build.rar". It had an integrated ATI graphics card. So the issue seems complicated and highly dependent on GPU and/or it's drivers. P.S. I am still running on Windows 10 version 20H2. I have not yet upgraded to 21H1. Hopefully that makes no difference.
-
Yes, with “v2_05_71_build.rar” and enabling the "Suppress DX common errors" flag I can see those transparent pixels on the ground textures. However not with the “dxwnd.2.05.72.nocolorkey.rar” test build. I will need to arrange some tests runs on other machines with newer hardware. It may take a while though. In the mean time a compromise could be to not mess with the code and maybe just add a note in the .dxw file for Rainbow6 to try the "Suppress DX common errors" flag if there are issues with transparent...
-
That "ddraw:ForcesHEL" trick is neat! It results in a fluent gameplay with the software renderer.
-
Regarding the different color gradients in Rainbow6: There is definitely a noticeable difference between running the game in Dxwnd or not. However it might not be noticeable on a poor quality / badly calibrated monitor. Or with poor eye sight. However this is fairly simple to test. Running the game outside Dxwnd take a screenshot using the "PrtScr" button and a second screenshot using the in-game "F2" screenshot button. At least on my system the screenshot taken with the games internal method shows...
-
I may have tracked down the critical code in ddraw.cpp here: static HRESULT WINAPI extGetColorKey(int dxversion, GetColorKey_Type pGetColorKey, LPDIRECTDRAWSURFACE lpdds, DWORD flags, LPDDCOLORKEY lpDDColorKey) { HRESULT res; ApiName("GetColorKey"); BOOL IsPrim; IsPrim=dxwss.IsAPrimarySurface(lpdds); OutTraceDDRAW("%s(%d): lpdds=%#x%s flags=%#x(%s)\n", ApiRef, dxversion, lpdds, (IsPrim ? "(PRIM)" : ""), flags, ExplainColorKeyFlag(flags)); res=(*pGetColorKey)(lpdds, flags, lpDDColorKey); if(res) //...
-
I may have tracked down the critical code in ddraw.cpp here: static HRESULT WINAPI extGetColorKey(int dxversion, GetColorKey_Type pGetColorKey, LPDIRECTDRAWSURFACE lpdds, DWORD flags, LPDDCOLORKEY lpDDColorKey) { HRESULT res; ApiName("GetColorKey"); BOOL IsPrim; IsPrim=dxwss.IsAPrimarySurface(lpdds); OutTraceDDRAW("%s(%d): lpdds=%#x%s flags=%#x(%s)\n", ApiRef, dxversion, lpdds, (IsPrim ? "(PRIM)" : ""), flags, ExplainColorKeyFlag(flags)); res=(*pGetColorKey)(lpdds, flags, lpDDColorKey); if(res) //...
-
I may have tracked down the critical code in ddraw.cpp here: static HRESULT WINAPI extGetColorKey(int dxversion, GetColorKey_Type pGetColorKey, LPDIRECTDRAWSURFACE lpdds, DWORD flags, LPDDCOLORKEY lpDDColorKey) { HRESULT res; ApiName("GetColorKey"); BOOL IsPrim; IsPrim=dxwss.IsAPrimarySurface(lpdds); OutTraceDDRAW("%s(%d): lpdds=%#x%s flags=%#x(%s)\n", ApiRef, dxversion, lpdds, (IsPrim ? "(PRIM)" : ""), flags, ExplainColorKeyFlag(flags)); res=(*pGetColorKey)(lpdds, flags, lpDDColorKey); if(res) //...
-
Got it, I just had to turn on "Suppress DX common errors" and the textures rendered fine. Very interesting... Turning on "Suppress DX common errors" actually causes the textures to turn transparent on my system. So perhaps a note in the dxw config suggesting to experiment with the flag depending on the situation. I also remember a post about the game "Mig Alley" where some users were having transparent texture issues. Perhaps it could be a similar issue.
-
Curious... That bmp is in a fairly normal format. On my system the texture is different size. (9kb vs. 13kb) The texture position is shown in the attached screenshot. I am also attaching the texture that comes out of the texture dump on my system. In addition to the smaller size it has a header "BMz" which I assume to mean some kind of bmp compression is used.
-
It's most likely an issue with "newer" GPU's and their drivers having issues with the texture format. I don't have this issue on my test system which is not surprising since my machine is quite old (circa 2012). You could try the following test: 1. Make sure Dxwnd is set to expert mode (Options/Expert mode). 2. In the Dxwnd configuration for Rainbow6 go to the "3D" tab and enable the option "Dump". 3. Start the game and visit the mission where the texture transparency issues occur. Then exit the...
-
Yes, mmdump output could also be helpful. For mmdump you can run it from command prompt with the command: mmdump > mmdump.txt Hit Enter two times and the text file should be filled with the output. Then post it here. P.S. If you use the mmdump.exe gho attached you may need to "Unblock" it before it will run. Right click "Properties" and under Security check the "Unblock" option. To avoid the need for this step it is better to always .zip programs before posting them...
-
Yes, mmdump output could also be helpful. For mmdump you can run it from command prompt with the command: mmdump > mmdump.txt Hit Enter two times and the text file should be filled with the output. Then post it here.
-
Since the installer complains "Access is denied" I would be almost tempted to create a new user account and see if that clears it. E.g. theory being some messed up user access permission setting, etc... For the broken system hypothesis there is always the System File Checker tool: https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e The article is more detailed but one could simply open the admin...
-
Well Dxwnd is open source so the code can be viewed by anyone to find the bad programming and fix it. However if one can not replicate the issue it can be difficult to figure out what exactly is causing the problem. I mentioned that it could be an issue with mixer device numbering. The code for the mixer emulation for the cda proxy is located in initmixer.cpp. So that is the place to look for if you have better knowledge of the API and how the mixer logic could be improved. There is also a possibility...
-
I have not had these issues but I found this post: https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install-winpc/error-extracting-support-files-catastrophic/2faea46b-96ed-4b05-8f56-f49089fd1539 Which suggests that the configuration file gets corrupted under the hidden folder: "C:\Program Files (x88)\Installshield Installation Information" There you will find several "{random GUID number}" folders which contain the configuration data for the installer program. If you can figure...
-
I have not had these issues but I found this post: https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install-winpc/error-extracting-support-files-catastrophic/2faea46b-96ed-4b05-8f56-f49089fd1539 Which suggests that the configuration file gets corrupted under the hidden folder: "C:\Program Files (x88)\Installshield Installation Information" There you will find several "{random GUID number}" folders which contain the configuration data for the installer program. If you can figure...
-
Tested with a couple of games and it seems to work fine.
-
I tested the demo version of the game and the issue I saw (or heard) was that the music volume slider was tied to the SFX volume slider. So if one reduced the music volume also the sound effects would be reduced in volume. What worked here was to simply enable "emulatecdmixer=1" in winmm.ini. I could not replicate the crash you were having. It is a curious thing though as it could indicate some unforeseen issue with different hardware setups and mixer device numbering.
-
The winmm.ini file for the stand alone cdaudioproxy in the "vcda" folder is formated in a slightly confusing way as everything is commented out with "#". A better winmm.ini could look like this: [winmm] #log, 0-1, 1: enables logging, default:0 log=0 #volume, range 0-100, default 100 volume=100 #repeat, 0-1, 1:enable AUTO-REPEAT, default:0 repeat=0 #pause, 0-1, 1:enable PAUSE capability, default:0 pause=0 #cdrompresent: 0-1, 1: forces CD detection in the CD caddy also when there are no audio tracks...
-
The winmm.ini file for the stand alone cdaudioproxy in the "vcda" folder is formated in a slightly confusing way as everything is commented out with "#". A better winmm.ini could be like this: [winmm] #log, 0-1, 1: enables logging, default:0 log=0 #volume, range 0-100, default 100 volume=100 #repeat, 0-1, 1:enable AUTO-REPEAT, default:0 repeat=0 #pause, 0-1, 1:enable PAUSE capability, default:0 pause=0 #cdrompresent: 0-1, 1: forces CD detection in the CD caddy also when there are no audio tracks...
-
Also in the winmm.ini all lines beginning with "#" are commented out. So in this case you have "#volume=20" which will be ignored since it is commented out. And in the end you have "volume=100" which is the one that will be used.
-
Try adding the line: emulatecdaux=1 in winmm.ini If that does not work also set: emulatecdmixer=1 P.S. @ghotik You should probably add emulatecdaux=1 in the default winmm.ini since it is missing.
-
It's fairly understandable design for the original bchunk considering it originates from Unix/Linux systems where file naming is case sensitive. E.g. you could have "file.txt" and "file.TXT" in the same folder and both would be considered a separate file.
-
Just came to my mind that a CAD program dating from 2014 might very well be 64-bit. If that's the case then Dxwnd and all the mentioned OpenGL wrappers are useless since they work only with 32-bit apps.
-
It might not be as simple as lying that no extensions are supported as we are dealing with a relatively modern (2014) OpenGL software. In between OpenGL 4.0 and 4.6 there are quite a number of core extensions that have become available. However the program might still need some of the earlier extensions to function properly. See: https://www.khronos.org/opengl/wiki/History_of_OpenGL It might also be that we are on a wild goose chase. It seems odd that a 2014 OpenGL application would suffer from newer...
-
It might not be as simple as lying that no extensions are supported as we are dealing with a relatively modern (2014) OpenGL software. In between OpenGL 4.0 and 4.6 there are quite a number of core extensions that have become available. However the program might still need some of the earlier extensions to function properly. See: https://www.khronos.org/opengl/wiki/History_of_OpenGL It might also be that we are on a wild goose chase. It seems odd that a 2014 OpenGL application would suffer from newer...
-
It might not be as simple as lying that no extensions are supported as we are dealing with a relatively modern (2014) OpenGL software. In between OpenGL 4.0 and 4.6 there are quite a number of core extensions that have become available. However the program might still need some of the earlier extensions to function properly. See: https://www.khronos.org/opengl/wiki/History_of_OpenGL It might also be that we are on a wild goose chase. It seems odd that a 2014 OpenGL application would suffer from newer...
-
is it possible to force the app to use OpenGL 4.0 istead of 4.6? Not exactly. But you could force a limit on the number of OpenGL extensions the app sees. You could try QeffectsGL: https://github.com/crystice-softworks/QeffectsGL And cofigure the .ini file with the line: ExtensionLimit=4000 Play around with different numbers to find a possible sweet spot. Assuming of course QeffectsGL even works with the app. There is also GLIntercept: https://github.com/dtrebilco/glintercept Which might help in...
-
The executable could help to tell the technology, but I would bet that it's based on OpenGL, so it's not necessary. I'm not 100% sure about that. Lukasz said: The support of Parallels told me to use a special parameter of "video.gl3=2". Which just tells us that Parallels (which is a Windows on MAC emulator if I understood correcly) needed that setting to render the CAD app properly. That could mean that the CAD app also uses OpenGL or just that Parallers was having issues with the host GPU. As for...
-
As blind test you could also try the Directx(2) tabs "Capabilities" options. Particularly the "Set minimal caps" option might help. There is also the more generic "Compat." tab option "Limit available resources". You need to have enabled the "Expert mode" to see these settings and additionally you may need to configure an early hook like "Inject suspended process" for these options to take effect. Edit: If it uses OpenGL then the "OpenGL" tab "Hook OpenGL" together with "OpenGL extensions lie" and/or...
-
As blind test you could also try the Directx(2) tabs "Capabilities" options. Particularly the "Set minimal caps" option might help. There is also the more generic "Compat." tab option "Limit available resources". You need to have enabled the "Expert mode" to see these settings and additionally you may need to configure an early hook like "Inject suspended process" for these options to take effect.
-
I tested the "encoder_example.c" and it compiled producing a console application that depends on libogg.dll, libvorbis.dll and libvorbisenc.dll. I used MinGW with the following compile command: gcc -o ogg-enctest.exe encoder_example.c -lvorbisfile -lvorbisenc -lvorbis -logg -static-libgcc But I imagine it compiles with MSVC also as long as you configure the needed libraries. The example app is quite rudimentary and requires the following piped command to convert a .wav file: ogg-enctest <input.wav...
-
@huh If you are interested in all the command prompt stuff there is an interesting pdf document available from Microsoft that lists most (if not all of them) here: https://download.microsoft.com/download/5/8/9/58911986-D4AD-4695-BF63-F734CD4DF8F2/ws-commands.pdf
-
On a 64-bit Windows the 64-bit stuff goes in "C:\Windows\System32" and the 32-bit stuff goes in "C:\Windows\SysWOW64". The WOW64 subsystem isolates 32-bit binaries from 64-bit binaries by redirecting registry calls and some file system calls. The WOW64 subsystem isolates the binaries to prevent a 32-bit binary from accidentally accessing data from a 64-bit binary. For example, a 32-bit binary that runs a .dll file from the %systemroot%\System32 folder might accidentally try to access a 64-bit .dll...
-
On a 64-bit Windows the 64-bit stuff goes in "C:\Windows\System32" and the 32-bit stuff goes in "C:\Windows\SysWOW64". The WOW64 subsystem isolates 32-bit binaries from 64-bit binaries by redirecting registry calls and some file system calls. The WOW64 subsystem isolates the binaries to prevent a 32-bit binary from accidentally accessing data from a 64-bit binary. For example, a 32-bit binary that runs a .dll file from the %systemroot%\System32 folder might accidentally try to access a 64-bit .dll...
-
You do know that custom path variables can be defined in Windows? So you can have for example a folder named "C:\Tools" and add it using the "System Properties" -> "Environment Variables..." or from the command prompt using the commands "setx TOOLSPATH C:\Tools". https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/setx
-
On a side note I tested with win9x (Windows Millenium Edition) and it would appear that even there both mciSendCommand and mciSendString open by default in "msf" time format. I don't know if this is important but it is something to keep in mind in case some game really starts by opening the device without specifying the time format.
-
Curiously when I ran some tests opening the cdaudio device using mciSendCommand and mciSendString without specifying time format both seemed to default to "msf". So either the MS documentation is wrong when it says the other defaults to tmsf or my test was somehow faulty. Next I should try with a win9x system to see if the behaviour has changed.
-
Here is a small test that opens the device using mciSendCommand and plays it using mciSendString: #include <windows.h> #pragma comment(lib, "winmm.lib") char timeformat_str[64] = ""; int _tmain(int argc, _TCHAR* argv[]) { UINT wDeviceID; MCI_OPEN_PARMS mciOpenParms; MCI_SET_PARMS mciSetParms; //SendCommand stuff: mciOpenParms.lpstrDeviceType = "cdaudio"; mciSendCommandA(NULL, MCI_OPEN, MCI_OPEN_TYPE, (DWORD)(LPVOID) &mciOpenParms); wDeviceID = mciOpenParms.wDeviceID; mciSetParms.dwTimeFormat = MCI_FORMAT_TMSF;...
-
Did you try the "Limit available resources" flag? Sometimes old games may fail when saving / loading due to reading a HDD partition size that is larger than the maximum on FAT32 of Win9x era.
-
Maybe there's an explanation, though it's really difficult to test it. We know that mciSendCommand uses TMSF by default and mciSendString uses MSF by default. But this game opens the device with mciSendCommand and THEN uses mciSendString to play the audio tracks. Maybe the mciSendCommand forces its default that remains valid also for mciSendString calls. That's correct. mciSendString is just a string parser for mciSendCommand.
-
If you have background programs unrelated to the game and these windows get moved to other monitors then it might also be some Windows "thing". Does this happen even if you run those games without Dxwnd?
-
Normally the settings are stored in dxwnd.ini which should be created and loaded from the same folder that you have dxwnd.exe running from. However depending on user permissions the dxwnd.ini file may be created in the VirtualStore when admin rights are not available. (This is due to the Windows UAC Virtualization feature.) Microsoft documentation about User Account Control (UAC): Inside Windows Vista User Account Control (link) You can also access the VirtualStore folder by typing the following...
-
Normally the settings are stored in dxwnd.ini which should be created and loaded from the same folder that you have dxwnd.exe running from. However depending on user permissions the dxwnd.ini file may be created in the VirtualStore when admin rights are not available. (This is due to the Windows UAC Virtualization feature.) Microsoft documentation about User Account Control (UAC): https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc138019(v=msdn.10) You can also access the VirtualStore...
-
Oh right so I've learned that for DOSBox, Gunmetal can actually still have timing issues in the opposite direction and even in the positive direction (yes, it can run too fast in DOSBox Even if you specify DOSBox CPU cycles manually? EDIT: I tried the game in DOSBox and on my system the game seems to run smoothly with all CPU settings set to AUTO up to 640x480 resolution. However depending on host machine CPU speed and OS (Linux vs. Windows) results may vary. At a manual CPU cycles setting of 80000...
-
Oh right so I've learned that for DOSBox, Gunmetal can actually still have timing issues in the opposite direction and even in the positive direction (yes, it can run too fast in DOSBox Even if you specify DOSBox CPU cycles manually?
-
Remember to add an entry for that "Hz" button in the help pages for the next release.
-
Just out of curiosity what is the benefit of having the FPS at exactly 60 instead of say ~58.8?
-
For now you can get the previous "v2_05_68_build.rar" from the archive: https://sourceforge.net/projects/dxwnd/files/Latest%20build/ Keeping WinXP compatibility is a challenge when new features are added all the time. My hats off to GHO for still maintaining XP compatibility. I would have given up years ago. ;-) My guess is this change broke it: add: [kernel32.cpp] added wrappers for _hread and CreateSymbolicLinkA/W calls
-
When changing the delay it is important to note that the apparent coarseness of the value may be a side effect of the game engine. After a certain amount of delay the program may suddenly jump to a very laggy state. This does not necessary mean that there is some magical floating point number that would give better results. Remember that many games have been hard coded to work at a certain framerate. Although these build-in limits may in some cases be overriden it depends on the program.
-
Seals are friendly not evil! https://www.youtube.com/watch?v=0Xv72Zw6tfA
-
Acording to those unity docs the commands are: -screen-fullscreen -screen-height -screen-width Where did you get that -window-height/width command? It does not appear to be listed there.
-
Do you know if it's possible to increase the performance for the Software mode, they lag a lot? The DirectX tab option "Suppress ZBUFFER attach" seems to improve software rendering performance but causes graphical glitches. Might be a hint though that the performance issues are caused by the Z-buffer. When I used dgVoodoo2 alone, the mouse trail problem occurs, but when I try to use DxWnd with dgVoodoo2 the game doesn't launch anymore. I did not have much success with DgVoodoo2 but in theory you...
-
RE: Mouse trails in software mode: it does in Direct3D but not in software rendering So it appears. For some reason you need to change the DirectX tab Renderer from "Primary Surface" to "gdi" or "OpenGL" if you want to run Rainbow Six in software mode without mouse trails.
-
Evidently, when I wrote that 80 I was thinking to the size of the line buffer (where 80 is far more than enough) I know what you mean. I had 40 column mode display on my Commodore 64 and it was plenty enough. ;-)
-
Yes, it seems to fix it in my testing. And I bet it was also the reason for the problems with the Program Files directory.
-
I dont know what's going wrong there. The DirectX tab option "Compensate Flip emulation" should have taken care of that issue.
-
Regarding the character limit for successful tracklen.nfo generation I found this in "player.cpp" _snprintf_s(path, sizeof path, 80, "%s\\Music%s\\Track%02d.%s", sRootPath, folderSuffix, i, ext); 80 seems a bit low considering MAX_PATH is 260.
-
Well the theoretical limit is 260 characters but that includes the full path of all folder names including the executable name. In addition it might be that the Dxwnd buffer for the path can not hold that many characters. But as a general rule you should try to avoid writing novels with your folder names.
-
Just replace "will" with "may" if there is doubt. ;-) It's been so long since I installed anything in Program Files folders that I may be biased.
-
But by all means there should be a warning about this in the help docs for Dxwnd. Maybe in the tutorial section something like this: NOTE: Do not install old games under "Program Files" or "Program Files (x86) folders. Doing so will result in the cdaudio emulation failing because the tracklen.nfo file can not be properly generated in these system protected folders.
-
Installing games in "Program Files" or "Program Files (x86)" is well known No-No from at least Windows Vista days. I did not mention it because I thought everyone and their dog already knew this. :-) Those folders are system protected and assume that the software in question places all run time generated files into the "User" folder. You can see this with all modern software that installs by default in the Program Files directories that they generate and seek all their configuration files in the...
-
So it would seem that on your system the player can find and play the music files but the files are not found when the tracklen.nfo is being generated. That is puzzling...
-
Can you try using a different sound format for the music files? It would be interesting to know if the tracklen.nfo gets successfully created with .wav files instead of .ogg for example. You can rip the tracks from the CD in .wav or .mp3 format using for example Windows Media Player.
-
Here's some food for thought: Could something be changing the working directory? I had similar reports on GitHub with a user having issues with the wrapper being ignored. We determined that we both had a valid installation of the game (it was Quake2 in that case) and all files were in the correct place and format. Nonetheless on his system the winmm wrapping was completely ignored. How something like that could happen is a complete mystery. My guess at the time was that it might be related to some...
-
Here's some food for thought: Could something be changing the working directory? I had similar reports on GitHub with a user having issues with the wrapper being ignored. We determined that we both had a valid installation of the game (it was Quake2 in that case) and all files were in the correct place and format. Nonetheless on his system the winmm wrapping was completely ignored. How something like that could happen is a complete mystery. My guess at the time was that it might be related to some...
-
At a first glance of your log file there is definitely something going wrong. See the line: dxwplay: error loading audio CD emulator And there are several lines of expected InitModuleHooks missing from the log. On my testing the log file size is over 1 megabytes but your log is tiny in comparison at only 8 kilobytes. Also it appears to be Dxwnd v.2.05.27 from September 2019. For the testing you could download the latest Dxwnd version and extract it in a new folder. EDIT The difference in log size...
-
At a first glance of your log file there is definitely something going wrong. See the line: dxwplay: error loading audio CD emulator And there are several lines of expected InitModuleHooks missing from the log. On my testing the log file size is over 1 megabytes but your log is tiny in comparison at only 8 kilobytes. Also it appears to be Dxwnd v.2.05.27 from September 2019. For the testing you could download the latest Dxwnd version and extract it in a new folder.
-
On a side note I did not see a "Rainbow Six" entry in the exports folder. This game seems to play well with Dxwnd's default settings except for a few things: I would enable the "Mouse" tab flag "Hide" for cursor visibility. Else the Windows cursor will become visible together with the rendered cursor in some cases. Secondly the "DirectX" tab flag "Compensate Flip emulation" fixes the mouse cursor that is leaving trails. Finally the game Window starts at the specified size and position but if it is...
-
On a side note I did not see a "Rainbow Six" entry in the exports folder. This game seems to play well with Dxwnd's default settings except for a few things: I would enable the "Mouse" tab flag "Hide" for cursor visibility. Else the Windows cursor will become visible together with the rendered cursor in some cases. Secondly the "DirectX" tab flag "Compensate Flip emulation" fixes the mouse cursor that is leaving trails. Finally the game Window starts at the specified size and position but if it is...
-
I have now tested Rainbow six (1998, Red Storm Entertainment) with Dxwnd's cdaudio emulation and the music seemed to work fine. I would suggest you do to the following experiment: Make sure there are no traces of winmm wrappers or any other extra libraries in the "Rainbow Six" game directory. In your Dxwnd configuration for Rainbow six make sure you have enabled the "Sound" tab option "Virtual CD audio". In the Dxwnd "Logs" tab enable the following options: Overwrite System libs Debug Sound Start...
-
if I replace the original winmm.dll in the SysWOW64 folder, the game won't run with the file. You should never replace the Microsoft provided winmm.dll file in the system folder. Doing so will break the MCI API. A winmm.dll wrapper is not the same as a real winmm.dll system library. If you have already messed with the system libraries then I suggest running a system scan and repair in order to try and fix the damage (type "sfc /scannow" in the cmd prompt): https://support.microsoft.com/en-us/top...
-
OK, it seems like all the info in those old blog posts regarding DAE audio playback are obsolete, beginning with Windows Vista. So it looks like this may be a dead end.
-
DAE seems to rely on the ntddcdrm.h header: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddcdrm/
-
The text formating is messed up but the archived MS blog posts about DAE playback for audio cd's are here: https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-7-dae-table-of-contents https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-8-simple-dae-playback https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-9-fixing-glitches It's painful to read and I did not really understand much about it.
-
The test formating is messed up but the archived MS blog posts about DAE playback for audio cd's are here: https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-7-dae-table-of-contents https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-8-simple-dae-playback https://docs.microsoft.com/en-us/archive/blogs/larryosterman/playing-audio-cds-part-9-fixing-glitches It's painful to read and I did not really understand much about it.
-
BTW maybe I spotted a problem: no matter what number I used on the file name, the CD seemed to play always the same track .... Yes, I noticed this too. It seems to me that you can only play the disc from the beginning if you try to open it using the .cda file name. I don't know if that is really a big problem since I am not aware of any game that uses that method to play cdaudio tracks apart from the example linked to by huh.
-
So the solution doesn't seem to provide much help, or not? Of course it does not make a difference if you simply use the mci api to play a cdaudio disc. That part works just fine in Windows. The problem is if the game issues a MCI_CLOSE right after the play command. On win9x this would not stop the playback but starting with Windows Vista it kills the music and on WinXP it locks the cdaudio device. With a separate winmm wrapper and a mci player we can ignore the MCI_CLOSE command. The other problem...
-
Regarding a possible implementation of direct cdaudio track playback with fixes for the MCI API flaws in Dxwnd: In the case the user has selected the Virtual CD audio option but no music folder or valid tracks are found Dxwnd could implement one of the following. A separate cdaudio player that still uses the MCI API similar to the cdaudio-winmm implementation. This is far from perfect though. Using the Windows Media Player API to play the cdaudio. This one seems interesting but appears to be already...
-
@huh That is an interesting point about MCI_WAIT. In the win9x days you could call MCI_PLAY + MCI_WAIT which would suspend the player thread until the track finished playing. However starting with Windows Vista the status never gets updated so this kind of command might result in a deadlock of the player thread. white: If you want to fix the cdaudio playback from a physical disc or a cdimage file without the need to rip the music tracks then you could also try cdaudio-winmm: https://github.com/dippy-dipper/cdaudio-winmm...
-
@huh That is an interesting point about MCI_WAIT. In the win9x days you could call MCI_PLAY + MCI_WAIT which would suspend the player thread until the track finished playing. However starting with Windows Vista the status never gets updated so this kind of command might result in a deadlock of the player thread. @white If you want to fix the cdaudio playback from a physical disc or a cdimage file without the need to rip the music tracks then you could also try cdaudio-winmm: https://github.com/dippy-dipper/cdaudio-winmm...
-
Can any of the currently available options force-play tracks from emulated CD/actual CD if a game can't do it itself? This happens sometimes on Win7 and as far I've been reading even more so on Win10. I've noticed a note of "mcihack.txt", could I ask a bit more about that and how to approach preparing it? The question here is whether or not I have to RIP and custom name the tracks for each game, it's time and space consuming. If the game supports cdaudio but does not play the tracks then there are...
-
Scary coincidence. Almost spot-on but they failed to predict the smartphone zombies. ;-)
-
It is curious that the game requires the "Sound / Ignore device id." flag, but in effect it performs a MCI_OPEN for the CD device and then doesn't use the returned id (1 in this case) and keeps using the device id 0! It could be considered a game bug? If it is a game bug then the game would have had issues with cdaudio playback on Win9x too. But I bet this whole device id mess is the result of Microsofts changes to the MCI API. Similar to how they broke other parts of the mcicda driver over the years....
-
If the game has build-in windowed mode and the problem is that the window is too small then GameStretcher might help: https://github.com/Dwedit/GameStretcher
-
If the game runs with the Windows 95/98 compatibility layer then you can do the following experiment: Make sure the game executable does not have the compatibility layers set in its properties. Start the Microsoft ACT Compatibility Administrator and create a new application fix. Select the game executable and enable the Windows 95 Compatibility mode and proceed to the next step. Here you should see the list of enabled Compatibility fixes for the Win95 comp mode. On my Win8.1 system the Windows 95...
-
The game Midtown Madness has some issues with cdaudio. Although these are fixed by the Midtown Madness Open1560 project I thought it is interesting to mention the original games behaviour. First of all if the original disc is not in the drive the game refuses to play the music. There is a jukebox in-game which allows the playback of music manually using the keyboard keys 2-5 though. Secondly the cdaudio wrappers seems to fail in playing back the music in the menu screens. One thing I noticed is that...
-
Well, my take on this is that DirectPlay will probably get deleted by Microsoft at some point. In that regard a dummy dplayx wrapper will be useful in allowing some games to continue running. As for the OLE/COM case I am not sure. One thing I noticed is that SuperBike2000 has the shims "EmulateHeap" and "IgnoreLoadLibrary" enabled. So one might want to rename the executable to make sure these are not interfering. Additionally there is the "DirectPlayEnumOrder" shim which one might try to enable....
-
To test the DirectPlay wrapper make sure you do not have the real DirectPlay enabled on your system. To do this you can visit the Control Panel and navigate to "Windows Features". From there look for "Legacy Components" and remove the check mark from "DirectPlay".
-
To test the DirectPlay wrapper make sure you do not have the real DirectPlay enabled on your system. To do this you can visit the Control Panel and navigate to "Windows Features". From there look for "Legacy Components" and remove the check mark from "DirectPlay".
-
BTW I also tried to replace the dll in system32, but the file is not there! There's a dplayx.dll in sysWOW64, where honestly I'd prefer avoid touching anything at all. The wrapper is a 32-bit file so placing it in a 64-bit dll directory is not going to work. System32 is the place for 64-bit dll files and SysWOW64 is the place for 32-bit ones. The naming convention might be confusing but that is how it is. That said I would avoid replacing any existing files in the system directories.
-
I have used the CnCNet dummy-dplayx with success on some games that required DirectPlay: https://github.com/CnCNet/dummy-dplayx
-
I have used the CnCNet dummy-dplayx with success on some games that reguired DirectPlay: https://github.com/CnCNet/dummy-dplayx
-
The game Midtown Madness has some issues with cdaudio. Although these are fixed by the Midtown Madness Open1560 project I thought it is interesting to mention the original games behaviour. First of all if the original disc is not in the drive the game refuses to play the music. There is a jukebox in-game which allows the playback of music manually using the keyboard keys 2-5 though. Secondly the cdaudio wrappers seems to fail in playing back the music in the menu screens. One thing I noticed is that...
-
Is it possible that you have a winmm.dll file in the same folder with dxwnd.exe? Dxwnd builds 2.05.57 - 2.05.59 came with a winmm.dll wrapper in the same folder as dxwnd.exe (when GHO merged the CDAudio proxy with the main Dxwnd project). This was causing a conflict with some games so the proxy dll was moved in a "vcda" sub-folder starting with the 2_05_60_build.
1 >