I don't understand how this program works.

I start w7ddpatcher.exe, browse to the game .exe in question, select it, the game starts, looking like rainbows as usual, quit the game, get back to desktop.

w7ddpatcher.exe window says found blabla.exe for the game in question but seems to do nothing with it????

What am I doing wrong?

the "Microsoft\DirectDraw\MostRecentApplication" registry key is not updated consistently... this causes a silent fail?

keep trying until the Name under the MostRecentApplication key matches the name of your target application (see the manual instructions in the link I've previously provided)

Miki Maus wrote:

Try using D3DWindower.

Using one last XP system that still has the display problem I had to copy D3dHook.dll the Torment folder. Then I tried different options and found that DDraw Emulate corrected it.

Since it's now displayed in a window, using the mouse to scroll off the edges doesn't work. If it could be set to go full screen it would be a much better solution.

I think the height and width labels are reversed in the one I downloaded since a window 950 high by 1250 wide turned out to be really tall and narrow.

off topic now

I whipped up a "fix" for Torment's cursor trail problem

http://www.shsforums.net/topic/48732-cursor-trail-fix/
enjoy

Can I ask how you made that, exactly? Did you use a debugger?

Jorpho wrote:

Can I ask how you made that, exactly? Did you use a debugger?

Used a debugger

Here is exactly how I made it

Problem Description:
Cursor artifacts occur when using fully emulated directdraw and running fullscreen
they don't occur when using fully emulated directdraw and running windowed

so to find a cure:
Make sure DirectDrawCreate is passed the DDCREATE_EMULATIONONLY flag
(so we have mouse trails)

Find what accesses the string "Full Screen"
Find the address where the obligatory 'IsFullScreen' value is stored
Log each instance where the IsFullScreen value is accessed.

For each instance patch the code so false is used instead of true.
launch the game and see if the problem is fixed
repeat until it is. 😁

There already is a Cursor_Trail_Workaround posted there.
http://www.shsforums.net/topic/43616-how-to-d … other-ie-games/
What sets this one apart from that one?

trying to use D3dWindower to run fake full screen is a pain (and not perfect)

I haven't reversed far enough to know what the ultimate problem is.
What side effect of D3DWindower is fixing this?
(using GDI for rendering? not creating surfaces in video memory?)

my solution could be dropped into one of the tweak packs and people wouldn't ever have to deal with this issue.
(or D3DWindower, or Shiftwindow, or NvidiaFix, or MS ACT, or update their video drivers, or the HW acceleration slider, or fake desktop resolutions)
In fact, that entire thread could be deleted.

aqrit wrote:

Jorpho wrote:

Can I ask how you made that, exactly? Did you use a debugger?

Used a debugger

Which one? IDAFree?

...
I used:
IDAFree as a disassembler
OllyDbg (v1.10 and v2.0) as a debugger
Cheat Engine to log what accessed the IsFullScreen value
CFF Explorer for examining/altering the PE header
Dependency Walker for viewing imports
MSVC Express 2008 for compiling my api hooks/code injection test stuff
dx7sdk for directdraw documentation
Hxd as a hex-editor

back on topic...

The DirectDraw\\MostRecentApplication value almost never updates (for me)

but a quick google shows that the "ID" value is just the TimeDateStamp in the PE header of the target executable

So this program could be greatly simplified/improved...

Okay,
I stopped making this ever since Sol_HSA made the proper ddhack emulator/hack, but what exactly do you want done.

I might get off my ass to fix, or update this. If I am motivated enough. 😦

something like this?
http://users.cjb.net/aqrit/ddraw_color_fixer.zip (includes source)
*** not tested on x64 ***

aqrit wrote:

something like this?
http://users.cjb.net/aqrit/ddraw_color_fixer.zip (includes source)
*** not tested on x64 ***

As far as I know, this does the exact same thing as the program in the OP.

It gets the 'ID' value in a way less prone to failure.
Though the program itself is probably less reliable. (because it was written in a hurry)

Good Ol' TarviS wrote:

As far as I know, this does the exact same thing as the program in the OP.

Did you read the posts in your own thread?

specifically these three:
mudlord's Windows 7 DDraw Compatability Fix (Fixes Garbled Colors)
mudlord's Windows 7 DDraw Compatability Fix (Fixes Garbled Colors)
mudlord's Windows 7 DDraw Compatability Fix (Fixes Garbled Colors)

Generic hook for emulation_only:
http://pastebin.com/Ns5b3t6P

1) App gets HWND/process IDs of application being run.
2) App runs the application.
3) It kills its threads as soon as a HWND and thread ID is gathered.
4) From there, the most recent DirectDraw application ID is gathered. Since it was the app to be patched, it copies it to a variable.
5) This variable, along with the needed flags makes a compatibility profile in the Registry for Windows Vista/7 to use with that application, only. It won't affect other parts of your registry. The key name used comes from the application's window class name/IDs.

Read my comments in this thread... seriously

the first 4 steps are not optimal ->
and almost never work for me (and others)

a better method:

1) Get TimeDateStamp from target executable
2) Add key to registry (the key name can be anything)

Both ddraw color fixes given in this thread work only partially with UFO Defense collector's edition. The colors are correct for everything except the intro movie which still looks like a tie-dye.

They both work well with TFTD, though (except the initial language selection screen, but that's not a problem).

Thank you to both fixers.

For some (many?) games that have color palette problems there is a very simple fix that doesn't require any extra files, manual editing of the registry or tinkering with the Application Compatibility Toolkit:

Disabling Desktop Composition (Aero) in a programs Compatibility Settings might very well be enough. At least on my Win7/32.

So if you use a 32bit Windows, before trying anything else, try this. Works quite often. In general for everything that works with the infamous "open the Screen Resolution window" workaround.