A troublesome release: despite so many attempts and checks, this release is not working properly with old Diablo, the first and original one!
As a matter of fact, I start to doubt that this game has always had this sort of erratic problem that you never know whether it will pass the game menu or not!
But, putting this sad argument a little apart, here are the good news:
1) complete translation for english, chinese and (just for fun) italian.
2) support for Tetris Worlds: this funny game revealed a very peculiar behavior of D3D7 CreateDevice.
3) An (almost) complete manual!
4) Since so many complains derived from the compatibility settings of programs, I decided to embed a compatibility detector in DxWnd: whenever you'll try to run a program with compatibility settings, DxWnd will tell you!
Enjoy, and if you get more troubles, tell me and revert DxWnd to the previous release!
I'm not sure what you're asking for....
Anyway, the passage between build 72 to 73 introduced a great amount of changes, mostly for non-windowized mode, and clearing these changes is not easy.
Source code is all available anyway in the download section.
Can you describe more precisely the "speed" problem, so that maybe I can get a hint?
Can you provide a game name and DxWnd configuration file that make the problem evident to make some tests? I suspect the problem is in a change I made in VSync delay emulation, but that was meant to be an improvement, so I wish to be able to judge when things are properly set.
The game is still Total Soccer 2k, isn't it? But a dxwnd export file (or the dxwnd.ini file) will be necessary.
I did, but I get no timing problem whatsoever, so it's difficult to compare ....
Furthermore, my theory about vsync delays died before birth: I see you're not using the "Oprimize CPU (DirectX1-7)" flag, so the vsync emulation is turned off.
And browsing all code changes between release 72 and 73, there's a lot of stuff, but apparently nothing linked to game speed.
I'm going to ask you a few questions, to get some enlightment:
1) is the trouble happening always or only when time stretch is enabled?
2) you set automatic more, and that may turn either to "Primary surface" or "Locked surface". Can you try them both individually and tell me the result?
3) Can you grab a short piece of log and upload it? Logging flags should be the first four from top to botom, plus the "Debug" log flag.
I'm almost clueless, but we must not despair....
Thank you for replies and log files.
I'm sharing your optimism: we'll do it!
Even in the worst possible case (no clues whatsoever) I think I may send you a bunch of different dxwnd.dll files, each one with a single change, and see where the toy gets broken!
cloudstr: let's begin the hunt....
In attach three copies of dxwnd.dll to be replaced in the v2.02.82 dxwnd folder (renaming them to dxwnd.dll), each one integrating part of the v2.02.73 changes.
You should try each one and tell me when the timing problem happens.
More will come later. One step at a time, I should quickly insulate the problem!
Sorry for the mistake, you're right, they have to be replaced in v2.02.72 folder, as you did.
But the result is the oddest possible one. Each of the three dlls is v2.02.72 plus one different piece of v2.02.73, with no overlap in theory. So, the logical conclusion would be that also v2.02.72 has the problem!
To cross-check, here in attachment a rebuilt release v2.02.72. Is it working fine or with the same problem?
A question: do you keep different versions of dxwnd together on the same machine? I'm wondering if the problem could come from a different setting of dxwnd.ini (there are debug invisible flags that accidentally could be set without being noticed!). If so, please save the good dxwnd.ini file and then you could try to copy the configuration file from the different folders, to see if in reality the problem could depend on the configuration instead of the software.
I'm really puzzled. There are very few things updated in that code.
To cross-check please try this variation of release 73 dll that eliminates the changes. In theory (but who knows...) it should behave like release 72.
Not really, I'd say the other way round: differences between dxwnd.dll and dxwnd.hook.dll are so tiny and all of the type "if you use a flag that you are not using then do ...." that I wonder how they could possibly behave differently.
This is why I asked you to double-check by testing the dxwnd.73reduced.dll that eliminates ALL differences to see if the problem disappear or not: I'm wondering if that could depend on anything different from source code (permissions, configuration, who knows...)
Have you tried that one?
dxwnd.73reduced.dll is almost equal to dxwnd.dll release v2.02.72, but I wanted to be sure that the trouble was started by the very limited changes from dxwnd.73reduced.dll and dxwnd.hook.dll.
If that is true (that is, if I din't make any mistake in compiling stuff...) there are very few things to check, and this is really good news! So I'm going to send one dll version for each change and see what happens.
Shall we start with this modified version of v2.02.73 with ONE SINGLE LINE of potentially offending code? If we're lucky, this (and all next) release could work fine ....
Ok: forgive me if I'm skeptical, but the result I got so far is almost impossible, because the difference seems to lay in two almost identical files, so I think either me or you possibly made some mistake.
So, before we enter a cul-de-sac (a dead end...) I wish to compare again these two dlls and verify if they still show the difference between 72 and 73 release.
Also, in order to avoid possible errors, I wish you to exit and start the DxWnd.exe file between different attempts to avoid that the previous dll could be somehow cached in the system
Good. I somehow hoped they were both GOOD, because differences were so small and insignificant... maybe I made something wrong.
Next two files are meant to be more or less like the ones of the first round, but compiled with much more attention.
One of the two MUST give bad results, because almost all differences between release 72 and 73 are confined within these three files (dxhook.cpp, ddraw.cpp and user32.cpp).
I add also a third dll for d3d differences, just in case, since this game is not using d3d, at least from what I see from the logs.
Try all these again .....
Ah, a last advice: all dlls are also differentiated by the release string. Whenever you got a result, just double check it by using the help->about... menu command: the dll version will be shown on the help window.
I guess it may surprise you a little bit, gho. But the problem is from the file dxwnd.d3d73like.dll !!!
The game is not using d3d but still be affected for unknown reason. There must be something changed in that file i think.
I'm surprised, but not too much....
The game is a 3D game, after all, and the hd3d.cpp was heavily changed. But what I can't understand is the fact that apparently there are no traces in the log of any usage of d3d calls.... but it could be a logging problem.
In any case, before sending you another huge pack of dxwnd.dll versions, I wish to think a little about this oddity: the brute force attack (one dll version to test for each songle change in the file) should be the last hope.
This one is the 73 release, MINUS the hd3d.cpp that comes straight from release 72.
If this works fine, it's a proof of your theory. If it doesn't, it means we should look for something else....
You got it, gho! That file work like a charms so hd3d.cpp is indeed what you should look into.
hello gho, we should end this problem soon. Let's do it!
I've been looking at the hd3d.cpp source code, making some tests and got to the conclusion that this module is NOT REFERENCED by TS2000. So, it seems honestly impossible that it may have anything to deal with the problem.
To be more sure about it, I've built this debug release of the latest dxwnd, compiled WITHOUT hd3d.cpp.
Can you try this one? This dll requires its proper main, so you'll need to unpack both in a separate folder (don't mix with previous ones!) and configure a TS2000 entry.
Honestly, version you give seems to work a little smoother than original (build 88). But it just a 'small' different. So the original build already work better than i though,
I can 'safely' say that this thread is done. (And 430+ views.. lol, what a shity thread, right? ;(
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.