Activity for UCyborg
-
UCyborg posted a comment on discussion General Discussion
That makes sense. But is this relevant to win32 apps under any circumstance? Manipulating that block seems like something you'd do when running under DOS. Old code that should have been purged when porting to Windows? What are you trying to accomplish with catching writes there? You want to have your own mechanism for handling those?
-
I noticed that thing with MCI_CLOSE not stopping playback on older OS too. I guess those few games that I've played that play CD audio always do MCI_CLOSE at the very end, so music doesn't just stop when using real CD audio or older DxWnd's virtual CD audio on modern Windows versions. So to prevent locking the device in case of app crash on older OS, you have to close the device after every command and re-open it again when you need to issue another command? Crazy! Is there a story behind the memory...
-
You're right, I checked the statistics with Process Hacker 2 and the GDI handles count does keep rising. The game seems to leak them either way, but the number rises about 4 times faster with 'primary buffer' option.
-
Using DxWnd version 2.05.24. I use this option on DirectX tab to get rid of the issue on Windows 10 (probably happens on 8.x too) that makes menu screen go black under certain circumstances, usually happens on its own when transitioning from gameplay to menus, but it can always be reproduced if you use Aero Peek, easy to invoke from the main taskbar from another monitor. The problem is some weird usage of DirectDraw for menus when I76.EXE is invoked with -glide parameter (to enable rendering via...
-
Using DxWnd version 2.05.24. I use this option on DirectX tab to get rid of the issue on Windows 10 (probably happens on 8.x too) that makes menu screen go black under certain circumstances, usually happens on its own when transitioning from gameplay to menus, but it can always be reproduced if you use Aero Peek, easy to invoke from the main taskbar from another monitor. The problem is some weird usage of DirectDraw for menus when I76.EXE is invoked with -glide parameter (to enable rendering via...
-
Using latest official version at the time of this writing. I use this option on DirectX tab to get rid of the issue on Windows 10 (probably happens on 8.x too) that makes menu screen go black under certain circumstances, usually happens on its own when transitioning from gameplay to menus, but it can always be reproduced if you use Aero Peek, easy to invoke from the main taskbar from another monitor. The problem is some weird usage of DirectDraw for menus when I76.EXE is invoked with -glide parameter...
-
No, because there are separate entries for actual compatibility shims, which are left as is.
-
The problem is some stubborn cache being kept somewhere after you've already launched the game at least once before applying the registry settings.
-
Right-click on the game .exe or its shortcut, select Compatibility tab and click OK. I ran the query on the database with Compatibility Administrator to get the GUIDs.
-
I know a better fix.
-
The logs are puzzling. Making a diff compare, you see that the only difference (apart the tracing of the added call auxGetNumDevs) is the replacement of the fake id 0xBEEF with the id 0x0 (which is correct!) until the end where ... the mciSendCommandA(MCI_PLAY) call is not performed. Maybe because real MCI returns ID value of 1 for the first opened device, then each subsequently opened device gets an ID incremented by one (or the first free ID if one of the devices were closed). Maybe that game doesn't...
-
The logs are puzzling. Making a diff compare, you see that the only difference (apart the tracing of the added call auxGetNumDevs) is the replacement of the fake id 0xBEEF with the id 0x0 (which is correct!) until the end where ... the mciSendCommandA(MCI_PLAY) call is not performed. Maybe because real MCI returns ID value of 1 for the first opened device, then each subsequently opened device gets an ID incremented by one (or the first free ID if one of the devices were closed). Maybe that game doesn't...
-
Thanks, I seem to remeber trying that checkbox recently. Maybe I accidentally clicked Cancel in the game's profile dialog or something. Anyway, works as intended. Edit: There is better way to deal with multiple CD drives using MCI, see this. Hm, I'll try it using mciSendString. But then there's gotta be a mciSendCommand equivalent. Edit: Got it figured out. This snippet opens and closes the door of CD drive E: Error checking intentionally omitted. int main(int argc, char **argv) { MCI_OPEN_PARMS...
-
Thanks, I seem to remeber trying that checkbox recently. Maybe I accidentally clicked Cancel in the game's profile dialog or something. Anyway, works as intended. Edit: there is apparently another way to deal with multiple CD drives using MCI, see this. Hm, I'll try it using mciSendString. But then there's gotta be a mciSendCommand equivalent. Edit: Got it figured out. This snippet opens and closes the door of CD drive E: Error checking intentionally omitted. int main(int argc, char **argv) { MCI_OPEN_PARMS...
-
Thanks, I seem to remeber trying that checkbox recently. Maybe I accidentally clicked Cancel in the game's profile dialog or something. Anyway, works as intended. Edit: there is apparently another way to deal with multiple CD drives using MCI, see this. Hm, I'll try it using mciSendString. But then there's gotta be a mciSendCommand equivalent. Edit: Got it figured out. This snippet opens and closes the door of CD drive E: Error checking intentionally omitted. int main(int argc, char **argv) { MCI_OPEN_PARMS...
-
Thanks, I seem to remeber trying that checkbox recently. Maybe I accidentally clicked Cancel in the game's profile dialog or something. Anyway, works as intended. Edit: there is apparently another way to deal with multiple CD drives using MCI, see this. Hm, I'll try it using mciSendString. But then there's gotta be a mciSendCommand equivalent.
-
Thanks, I seem to remeber trying that checkbox recently. Maybe I accidentally clicked Cancel in the game's profile dialog or something. Anyway, works as intended.
-
The game passes volume value of 32760 for each channel when you set it to max in menus. Just the formula is wrong. Easy to fix. I use ogg format. DeviceIOControl is not used. It uses the combination of GetLogicalDrives, GetDriveTypeA and GetVolumeInformationA to determine in which drive the game CD with label I76_CD2 is. It iterates through the volumes, increasing the count for each CD drive found, then stops when it encounters the CD drive with correct label or if there's no volumes left, whichever...
-
It does work with Interstate '76! Is it possible that the game's max volume isn't actually 100%? It's a bit quiet, even with music volume set to max in menus. I'll inspect the parameters it passes to auxSetVolume some time later. There is another quirk with this game. It uses some calls from kernel32.dll to determine if the computer has an actual CD drive before even bothering with mciSendCommand calls. So the original executable still doesn't play anything if computer doesn't have a CD drive. I...
-
Hey, no need to rush! I don't think that change is radical enough to break something. If it worked so far. :) The only scenario I can imagine when IDs would change would be if devices were added/removed while the system running. Are other devices that can be queried via these APIs Plug and Play? Reading about what auxGetDevCapsA returns, it mentions internal CD-ROM drive and auxillary input jacks.
-
Sorry for my posts lacking some crucial infos and also being a tiny bit misleading in the way when it comes to aux functions. I really only took a quick glance at the disassembled code in DxWnd while messing with Interstate '76, didn't realize there was a bit more code there than just debugging/tracing output... Anyway, is the Winmm wrapper in DxWnd inspired by hifi's winmm-ogg? Because this one is breaking one very basic and very simple documented rule. Device IDs are supposed to go from 0 to total...
-
Sorry for my posts lacking some crucial infos and also being a tiny bit misleading in the way when it comes to aux functions. I really only took a quick glance at the disassembled code in DxWnd while messing with Interstate '76, didn't realize there was a bit more code there than just debugging/tracing output... Anyway, is the Winmm wrapper in DxWnd inspired by hifi's winmm-ogg? Because this one is breaking one very basic and very simple documented rule. Device IDs are supposed to go from 0 to total...
-
Sorry for my posts lacking some crucial infos and also being a tiny bit misleading in the way when it comes to aux functions. I really only took a quick glance at the disassembled code in DxWnd while messing with Interstate '76, didn't realize there was a bit more code there than just debugging/tracing output... Anyway, is the Winmm wrapper in DxWnd inspired by hifi's winmm-ogg? Because this one is breaking one very basic and very simple documented rule. Device IDs are supposed to go from 0 to total...
-
I meant to say to be able to take advantage of the slider that you find in games to control music volume. Winmm wrapper in DxWnd is the only one that i'm aware of that doesn't handle calls to auxGetNumDevs/auxGetDevCapsA/ auxGetVolume/auxSetVolume. Yes, there's a Set emulated volume checkbox on the Sound tab in DxWnd, though IMHO this one should serve as an override only and not as a general music volume setting since games should have their own setting for that. I mentioned Windows XP's CD Audio...
-
What about the ability to control music volume using the game's volume slider? Some use auxSetVolume, though I guess this is for old PCs that have analog audio cable connected from optical unit to the sound card. There is another way I think. At least on Windows XP, there's a CD Audio slider in the volume mixer. I guess there's an API for that too. I heard when some games try to use that particular API on Windows 7 (sorry, I don't know which one is it), it changes volume of all sounds by default...
-
I just checked the description in the latest stable build and noticed you got some facts wrong. The function Direct3D8EnableMaximizedWindowedModeShim in d3d8.dll is supposed to restore a real fullscreen mode. It's the other way around, hence the function is effectively NOP due to changed default state of the global variable. Existence of Direct3D8EnableMaximizedWindowedModeShim function isn't really that important to the end user, so I'd just re-write the whole thing like this: On Windows 10, all...
-
I just checked the description in the latest stable build and noticed you got some facts wrong. The function Direct3D8EnableMaximizedWindowedModeShim in d3d8.dll is supposed to restore a real fullscreen mode. It's the other way around, hence the function is effectively NOP due to changed default state of the global variable. Existence of Direct3D8EnableMaximizedWindowedModeShim function isn't really that important to the end user, so I'd just re-write the whole thing like this: On Win10, all Direct3D8...
-
This option doesn't actually do anything since Win10 Build 17763 because the exclusive fullscreen functionality has been removed from d3d8.dll, just the phantom variable is still there. So you actually need a DLL from Build 17134, which could become incompatible with future builds. There's my topic on VOGONS from 2016 where I share modified DLLs for stable builds from 10586 to 17134 that behave as intended; maximized windowed mode is only activated when Direct3D8EnableMaximizedWindowedModeShim is...
-
The initial addresses put in there, like the one you highlighted, are valid if DLL can be loaded at its preferred address. If it can't be, the OS goes through DLL's relocation table, which records all places in DLL containing absolute addresses and corrects them. The article I linked mentions JMP and CALL instructions. Note that there's also a variant of those instructions that use relative addressing for changing the code flow within the module; nothing needs to be done for those. I made some small...
-
Seems to work as advertised. As long as you're dereferncing whatever pointer you get in the instruction, it's fine. You're probably seeing different address due to the fact that DLL might be re-located at runtime. When you open the DLL directly in OllyDbg, no other DLLs except core system DLLs get loaded so there's no conflicts. Many DLLs you encounter will be relocated at runtime since Microsoft's linker defaults to setting DLL's base address to 0x10000000 and probably not many devs bothered with...
-
You should change both the immediate constant and the variable pointed to by the pointer in the instruction that sets the variable. The latter is changed to change the default behavior while the former is changed only to prevent default compatibility settings in Windows from overridding what the user set in DxWnd. Direct3D8EnableMaximizedWindowedModeShim is only ever called for a handful of games, not all of them on that list even use d3d8.dll: If DXMaximizedWindowedMode is active, the function is...
-
You should change both the immediate constant and the variable pointed to by the pointer in the instruction that sets the variable. The latter is changed to change the default behavior while the former is changed only to prevent default compatibility settings in Windows from overridding what the user set in DxWnd. Direct3D8EnableMaximizedWindowedModeShim is only ever called for a handful of games, not all of them on that list even use d3d8.dll: The setting is (re)applied every time IDirect3DDevice8::Reset...
-
If I got it right, the behavior of windowed programs should not change, while fullscreen D3D8 programs by setting this flag could run in real fullscreen mode, while now they are always running in maximized window mode? Yes, you got it right. Do you mean that DxWnd already has a feature to tweak this flag? Or, if it doesn't have it, would it be useful to add such a tweak for ddraw as well? Yes, it's already implemented for DDraw (Disable Maximized Windowed Mode checkbox in Compat. tab). All that's...
-
On Windows 10, Direct3D 8 applications always run in fake fullscreen by default. Those that don't set WS_POPUP style for their window even have borders visible. Normally you can set the window style the same you'd like to have in windowed mode and D3D8 handles this transparently without having to worry about it; the borders disappear when going fullscreen, except in this fake fullscreen mode, which by default, also prevents gamma from being tweaked. Look at the exported function Direct3D8EnableMaximizedWindowedModeShim...
-
If I got it right, the behavior of windowed programs should not change, while fullscreen D3D8 programs by setting this flag could run in real fullscreen mode, while now they are always running in maximized window mode? Yes, you got it right. Do you mean that DxWnd already has a feature to tweak this flag? Or, if it doesn't have it, would it be useful to add such a tweak for ddraw as well? Yes, it's already implemented for DDraw (Disable Maximized Windowed Mode checkbox in Compat. tab). All that's...
-
On Windows 10, Direct3D 8 applications always run in fake fullscreen by default. Those that don't set WS_POPUP style for their window even have borders visible. Normall you can set the window style the same you'd like to have in windowed mode and D3D8 handles this transparently without having to worry about it; the borders disappear when going fullscreen, except in this fake fullscreen mode, which by default, also prevents gamma from being tweaked. Look at the exported function Direct3D8EnableMaximizedWindowedModeShim...
-
Glad you found the bug. Yeah, there exists 10th Anniversary Mod. Resolution hack seems to work as it should. I just couldn't test Soulbringer, the game just closes after intro cinematics. I use these binaries if this has anything to do with it: https://community.pcgamingwiki.com/files/file/844-soulbringer-better-directx-compatibility-patch/ Will check logs next time. I mentioned Drakan being slow in one of previous posts, it seems it only happened because I cleared Run in window option and some other...
-
Glad you found the bug. Yeah, there exists 10th Anniversary Mod. Resolution hack seems to work as it should. I just couldn't test Soulbringer, the game just closes after intro cinematics. I use these binaries if this has anything to do with it: https://community.pcgamingwiki.com/files/file/844-soulbringer-better-directx-compatibility-patch/ I mentioned Drakan being slow in one of previous posts, it seems it only happened because I cleared Run in window option and some other options were set so forced...
-
Glad you found the bug. Yeah, there exists 10th Anniversary Mod. Resolution hack seems to work as it should. I just couldn't test Soulbringer, the game just closes after intro cinematics. I use these binaries if this has anything to do with it: https://community.pcgamingwiki.com/files/file/844-soulbringer-better-directx-compatibility-patch/ I mentioned Drakan being slow in one of previous posts, it seems it only happened because I cleared Run in window option and some other options were set so forced...
-
Glad you found the bug. Yeah, there exists 10th Anniversary Mod. Resolution hack seems to work as it should. I just couldn't test Soulbringer, the game just closes after intro cinematics. I use these binaries if this has anything to do with it: https://community.pcgamingwiki.com/files/file/844-soulbringer-better-directx-compatibility-patch/ I mentioned Drakan being slow in one of previous posts, it seems it only happened because I cleared Run in window option and some other options were set so forced...
-
Glad you found the bug. Yeah, there exists 10th Anniversary Mod.
-
Weird, must be why I didn't see the value of 2048 changed into -1 when I tried DxWnd, because it may have changed something else. About the sequence of interest, all released DLLs have those 2 instances in common, and the first one is always the correct one. With new Win10 builds, the DLLs are very likely just re-compiled and it seems regular updates don't touch them at all. It seems to me that the current patching method is unlikely to break any time soon, if ever.
-
The Windows 7 installation I have on a virtual machine was installed from the image that was updated on June 2015, even after installing all updates, the modification date on d3dim DLLs is 14.7.2009 3:15, version is 6.1.7600.16385. It has only 2 instances of that sequence. I wonder what strange DLLs you encountered. While indeed MS can change something any time, legacy DirectX is not something they'll spend a lot of time on. So far, I messed with Drakan a bit, the option Primary Surface that was...
-
A bit busy IRL, hence a bit late response. I also had this idea of finding a pattern with only one match, but the problem is that it differentiates between different Windows versions. The byte sequence you proposed is only valid for Windows Vista and 7, it begins with 0x75 0xED on newer systems. Windows XP version has long 5-byte jump instruction before MOV EAX, 800. I picked that byte sequence because it seems universal, works all way back to Win98. :D But I don't know how you managed to find 3...
-
A bit busy IRL, hence a bit late response. I also had this idea of finding a pattern with only one match, but the problem is that it differentiates between different WIndows versions. The byte sequence you proposed is only valid for Windows Vista and 7, it begins with 0x75 0xED on newer systems. Windows XP version has long 5-byte jump instruction before MOV EAX, 800. I picked that byte sequence because it seems universal, works all way back to Win98. :D But I don't know how you managed to find 3...
-
https://github.com/UCyborg/LegacyD3DResolutionHack I see that my little project was noticed around here. So, I never bothered to expand it any further due to the fact that there is plenty of tools tackling legacy DirectDraw/Direct3D issues so it could be included with any of them. Proxy DLL isn't always picked up because in some cases, the full path is specified when LoadLibrary is called internally. About the second occurence of the pattern, I'm aware of it, I just didn't touch it because we don't...
1