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.

dosmax wrote:

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.

This does work sometimes, but it's less convenient and does not work for many games.

Good Ol' TarviS wrote:

This does work sometimes, but it's less convenient and does not work for many games.

My guess is, that this is highly system dependent. I have a Win7/32 desktop pc and a Win7/64 notebook. On the desktop machine this works for all games I tried so far. On the 64bit machine it doesn't work at all. Maybe some graphics cards/drivers still have the ability to do Ddraw correctly and others don't. Who knows?

Which method is more convenient is a matter of taste, isn't it? Personally I think, clicking a checkbox is much more convenient then downloading and running a program.

dosmax wrote:

Which method is more convenient is a matter of taste, isn't it? Personally I think, clicking a checkbox is much more convenient then downloading and running a program.

True, but with the latter, you only need to run it once per program, and not have to launch Screen Resolution every time.

Besides, Screen Resolution didn't work for Descent Freespace, Quake II, Hexen II, and Jedi Knight. Not for me anyways.

Good Ol' TarviS wrote:

Besides, Screen Resolution didn't work for Descent Freespace, Quake II, Hexen II, and Jedi Knight. Not for me anyways.

That only confirms that this is indeed system dependent. Besides Descent Freespace, which I don't have, everything else you mention runs fine here

Besides: I was not talking about the screen resolution workaround, which, you are right, one would have to do every time. But instead disabling desktop composition in the compatibility settings of a program.

amusingly...

all the registry garbage boils down to...

1if( SUCCEEDED( DirectDrawCreate( lpGUID, lplpDD, pUnkOuter ) )  )
2    (*((DDRAWI_DIRECTDRAW_INT**)lplpDD))->lpLcl->dwAppHackFlags |= 0x800;