After quitting from full screen mode(run program from dxwnd with "run in window" flag unchecked), windows on the desktop which originally located at the screen center(e.g dxwnd window) will move to the screen edge or screen corner(if you have other program windows on the desktop they also get moved).
I know it is caused by the program had set the screen resolution....after quitting the windows on the desktop can not move back to their original position. It's more likely win7 did not handle this well......but if i run the game directly(the game also set the resolution), after quitting, the windows wont change their position.
I am quite curious....I remembered dxwnd unwindowed mode had already leave all the actions to the program, why the windows behaviored differently?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for the message.
I would have blamed the resolution change as well, but I didn't notice that things go differently with and without DxWnd. For sure, it's something to investigate and possibly fix.
Help would be welcome.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems you can not reproduce? weird.... I can produce on several machines, win7 32/64.I tried every flag but nothing helped, please let me know if i can help any.
Some more information:
I switch the task(alt+tab) to the desktop while the game running, i found the window position is still correct! However if i use "EXIT" from the game the window position would reset to the wrong place...
I found this issue when i was testing the new dll you just released, i was really happy! ! Faint.... Why i always encounter some new issue on testings ....I'm really unlucky :'( After all, the only lucky thing is this is a minor issue.
Last edit: gsky916 2014-06-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I didn't mean I can't reproduce the problem, I just meant I didn't notice this correlation between DxWnd and scrambled windows on the desktop.
Actually, I haven't had time to try to reproduce the problem, but it's now on my list ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since these are really very minor issues...(just like last time i reported the banner didnt show up), these wont affect dxwnd run games!
I know there are tons of issues are waiting to solve.. i just think i should not preserve my findings...so i decide to share the information, that means at least let you...and other users know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I almost forgotten! I still don't know if you can reproduce the desktop issue.
I would very appreciate it if you can let me know...(of course when your time are available).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, not really....
I remember having seen something like what you described, but as soon as I tried to replicate the problem intentionally (it's not difficult at all to cause a game crash with dxwnd!) the windows duly got back at their proper place.
It must be a quantum mechanics based experiment: if you observe it, you interfere and it doesn't happen ;)
And then I got absorbed by tons of other issues.... but a help to replicate the problem would be appreciated.
Last edit: gho 2014-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Run Game with Dxwnd ("run in window" flag UNchecked) :
windows duly got back at their proper place, if
1)game crashed
2)switch back to the desktop, use dxwnd "kill task"
windows scrambled, if
Exit the game normally by using the EXIT Button in the game menu(e.g. The EXIT on wfsp title page)
I made the following test:
Run game with Dxwnd ("run in window" flag UNchecked, "Hook enabled" flag Checked)
Using the EXIT Button from game title page, windows scrambled.
Run game with Dxwnd("run in window" flag UNchecked, "Hook enabled" flag UNchecked)
Using the EXIT Button from game title page, windows got back at their proper place.
So I confirmed the scrambled windows was introduced by the Hooking, not the game self issue. Or in other words, the "win7 resize desktop action" was triggered by the hooking.
I looked into the log, found dxwnd set screen size twice!
DXWND: Initial display mode WxH=(1366x768) BitsPerPel=32
DXWND: set screen size=(800,600)
InitScreenParameters: RGBBitCount=32
SetBltTransformations: color transformation 32->32
SethWnd: setting main win=502b2 hdc=31010204 pos=(0,0)-(1366,768)
SetDisplayMode: version=1 dwWidth=640 dwHeight=480 dwBPP=16
DXWND: set screen size=(640,480)
Very interesting...Why dxwnd did this ;)
Sadly it' not a quantum mechanics for me, i can reproduce this on several PCs, either xp or win7, every time.
Last edit: gsky916 2014-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made some modifications to the above clarification, plese take a look.
Hope i made it clearly, sigh. Please let me know if you are still under quantum mode :D based on the above statement?
I'm not urge to get a solution, however i'd like to know if the issue is reproduceable for you and if i made the statement clearly. Thanks!
Last edit: gsky916 2014-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I promise this one will be the next one in my personal list!
Hopefully, if the weekend and the family (that hold some priority upon development fun...) don'interfere, I'll give you an answer soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it does reproduce, exactly as you described. The only thing is that it happens with Wind Fantasy SP, but it does NOT happen with other games (I tested it with Diablo, so far). So, is it something more that Diablo does? Or something less?
This is food for the next step, I'm afraid a little tougher.
But no quantum problems, at least!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting, i test another game, just like you said, it just happens with Wind Fantasy SP. Sorry for the lacking of tested cases.
However, the only thing i can confirm is the problem does not come from the game itself. It only occur when hooking enabled. We had a similar situation before--a potential general time API hooking bug only happened on WFSP, so far... Is WFSP becoming the unlucky one again? I can not draw an easy conclusion...
I don't know if Diablo and wfsp use the same or similar full screen strategy, the first thing is to know whether they are comparable. And as a last resort, maybe you can analyze wfsp default full screen strategy, then see if dxwnd altered any...Since the game wont trigger the resize action by default.
Last edit: gsky916 2014-07-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another piece of information. It seems that the problem take birth when hooking the DirectDraw methods: if you uncheck windowizing and set DirectDraw version hooking to "none" the windows seem to stay at their place.
For what concerns the Wind Fantasy addicted, this may be as well the final solution (the game is playable, and time stretching is working), but I wish to know more about this ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weird.... it's not the conclusion I remember I saw. At least, time acceleration was working, while special keys to control the time ratio require to be properly configured and yesterday night I had no time for them. This evening I'll repeat tests. About FPS control, this unfortunately is reasonable: if DxWnd doesn't hook d3d, it has no way to insert delays or screen display between frames.
I'll continue the hunting: there must be something wrong I do when the d3d session is closed in hooked mode that has to be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FPS control is one of the majority reasons to use dxwnd hooking wfsp.
The game is over fast by default.(1500fps on my pc)
The most interesting thing is FPS control can control the role movement speed meanwhile time stretching can control the role action(attack/magic etc.) speed. These two methods can not instead each other, that means time stretching can NOT control the role movement same as FPS control to the role actions.
I have to use both methods to deal with the game, wfps is the most tough game i had ever seen!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A Suggestion： Maybe you can take a look at aqrit's ddwraper(http://bitpatch.com/ddwrapper.html)
It can hook a fullscreen wfsp(at least show fps on overlay), and exit without the windows scrambled!
See how it deal with the d3d session closing!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately it's not so easy....
I've started to comment / uncomment piece by piece the DxWnd logic, and got focus on ddraw handling (not a big surprise, but anyway....).
The problem is that on session closing I do in practice nothing, and, even commenting out that little I do, the problem still is in place. Likely, it's something I do in the middle of the session that causes the problem in the end.
What's really weird, then, is the fact that not all windows get affected, but apparently just a few that are positioned in a particular way on the screen.... puzzling, isn't it?
But, proceeding step by step, there's no doubt I'll catch it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the windows are located in the position of the game display area, they will not get effected.
Wfsp display area is 640 x480 (initial position x:0 y:0), windows located in that area will not get effected.
Sorry for let you doing that debugging steps... it always works but it's also a heavy and repetitive work, again and again... :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The murderer has been captured.
The responsible of all this mess was an extra reference to the DIRECTDRAW session (see ddraw.cpp line 2854) introduced to make almost playable "Warhammer 40K Rites Of War". Unfortunately this wasn't good enough (the game crashes a few screens later) and produced this unpredicted effect on Wind Fantasy SP and maybe who knows how many others.
You can replace this attached dll and acknowledge the fix. On my PC it behaves quite ok. If everything is fine, as usual the fix will be included in next release.
So many thanks! It works! I will do some further testing when i back home.
David beat down Goliath AGAIN!
I cant believe my eyes, when i read ddraw.cpp line 2854 i find the hack is for ddraw1![if(dxw.dwDDVersion==1)] Does that mean Wfsp is a DX1 game?! It is a 2000 production. Gho you are very experienced with large amount of old diretdraw games, did you see many cases like this(use DX1 when DX7 is already out)?
PS. I find [keymapping] settings did not added in dxwnd.ini in 0.83 release.
Maybe adding something default may avoid some confusion?(I noticed you had released a new unfinished manual, may you have some extra considerations? I don't know, just a suggestion)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is WFSP a ddraw1 game?
Well, actually no and yes at the same time ....
The curious thing is that D3D7 methods are internally referencing ddraw methods, sometimes using unsupported flags to activate the required D3D7 extensions.
This is quite strange and not at all a good practice, in my opinion, but it is undoubtfully demonstrated by the logs, where you can read for instance a CreateDevice begin trace, a huge lot of ddraw traces and finally the CreateDevice ending trace: it means that the D3D7 method is internally calling the ddraw methods!
And, of course, this fact holds for EVERY SINGLE D3D7 game, there's no way to avoid D3D7 games to reference ddraw.
This uglyness had an end with D3D8 and later, where you see no inner ddraw calls, but if you want to know the whole story, I saw that the current D3D10 / D3D11 implementation is internally calling D3D9 methods, and this is why sometimes I smile when I read articles about the supposed superiority of the latest MS D3D releases....
Last edit: gho 2014-07-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After quitting from full screen mode(run program from dxwnd with "run in window" flag unchecked), windows on the desktop which originally located at the screen center(e.g dxwnd window) will move to the screen edge or screen corner(if you have other program windows on the desktop they also get moved).
I know it is caused by the program had set the screen resolution....after quitting the windows on the desktop can not move back to their original position. It's more likely win7 did not handle this well......but if i run the game directly(the game also set the resolution), after quitting, the windows wont change their position.
I am quite curious....I remembered dxwnd unwindowed mode had already leave all the actions to the program, why the windows behaviored differently?
thank you for the message.
I would have blamed the resolution change as well, but I didn't notice that things go differently with and without DxWnd. For sure, it's something to investigate and possibly fix.
Help would be welcome.....
Seems you can not reproduce? weird.... I can produce on several machines, win7 32/64.I tried every flag but nothing helped, please let me know if i can help any.
Some more information:
I switch the task(alt+tab) to the desktop while the game running, i found the window position is still correct! However if i use "EXIT" from the game the window position would reset to the wrong place...
I found this issue when i was testing the new dll you just released, i was really happy! ! Faint.... Why i always encounter some new issue on testings ....I'm really unlucky :'( After all, the only lucky thing is this is a minor issue.
Last edit: gsky916 2014-06-15
No, I didn't mean I can't reproduce the problem, I just meant I didn't notice this correlation between DxWnd and scrambled windows on the desktop.
Actually, I haven't had time to try to reproduce the problem, but it's now on my list ...
Hope my posts didn't bother you that much....
Since these are really very minor issues...(just like last time i reported the banner didnt show up), these wont affect dxwnd run games!
I know there are tons of issues are waiting to solve.. i just think i should not preserve my findings...so i decide to share the information, that means at least let you...and other users know.
I almost forgotten! I still don't know if you can reproduce the desktop issue.
I would very appreciate it if you can let me know...(of course when your time are available).
No, not really....
I remember having seen something like what you described, but as soon as I tried to replicate the problem intentionally (it's not difficult at all to cause a game crash with dxwnd!) the windows duly got back at their proper place.
It must be a quantum mechanics based experiment: if you observe it, you interfere and it doesn't happen ;)
And then I got absorbed by tons of other issues.... but a help to replicate the problem would be appreciated.
Last edit: gho 2014-06-30
Oh... I need make some clarification.
Run Game with Dxwnd ("run in window" flag UNchecked) :
windows duly got back at their proper place, if
1)game crashed
2)switch back to the desktop, use dxwnd "kill task"
windows scrambled, if
Exit the game normally by using the EXIT Button in the game menu(e.g. The EXIT on wfsp title page)
I made the following test:
Run game with Dxwnd ("run in window" flag UNchecked, "Hook enabled" flag Checked)
Using the EXIT Button from game title page, windows scrambled.
Run game with Dxwnd("run in window" flag UNchecked, "Hook enabled" flag UNchecked)
Using the EXIT Button from game title page, windows got back at their proper place.
So I confirmed the scrambled windows was introduced by the Hooking, not the game self issue. Or in other words, the "win7 resize desktop action" was triggered by the hooking.
I looked into the log, found dxwnd set screen size twice!
Very interesting...Why dxwnd did this ;)
Sadly it' not a quantum mechanics for me, i can reproduce this on several PCs, either xp or win7, every time.
Last edit: gsky916 2014-07-04
I made some modifications to the above clarification, plese take a look.
Hope i made it clearly, sigh. Please let me know if you are still under quantum mode :D based on the above statement?
I'm not urge to get a solution, however i'd like to know if the issue is reproduceable for you and if i made the statement clearly. Thanks!
Last edit: gsky916 2014-07-04
I promise this one will be the next one in my personal list!
Hopefully, if the weekend and the family (that hold some priority upon development fun...) don'interfere, I'll give you an answer soon.
Step 1: problem reproduction
Yes, it does reproduce, exactly as you described. The only thing is that it happens with Wind Fantasy SP, but it does NOT happen with other games (I tested it with Diablo, so far). So, is it something more that Diablo does? Or something less?
This is food for the next step, I'm afraid a little tougher.
But no quantum problems, at least!
Interesting, i test another game, just like you said, it just happens with Wind Fantasy SP. Sorry for the lacking of tested cases.
However, the only thing i can confirm is the problem does not come from the game itself. It only occur when hooking enabled. We had a similar situation before--a potential general time API hooking bug only happened on WFSP, so far... Is WFSP becoming the unlucky one again? I can not draw an easy conclusion...
I don't know if Diablo and wfsp use the same or similar full screen strategy, the first thing is to know whether they are comparable. And as a last resort, maybe you can analyze wfsp default full screen strategy, then see if dxwnd altered any...Since the game wont trigger the resize action by default.
Last edit: gsky916 2014-07-05
Step 1.1
Another piece of information. It seems that the problem take birth when hooking the DirectDraw methods: if you uncheck windowizing and set DirectDraw version hooking to "none" the windows seem to stay at their place.
For what concerns the Wind Fantasy addicted, this may be as well the final solution (the game is playable, and time stretching is working), but I wish to know more about this ...
If set DirectX version hooking to "none" :
1.time stretching is not working
2.mouse correction is not working
3.FPS control is not working
Weird.... it's not the conclusion I remember I saw. At least, time acceleration was working, while special keys to control the time ratio require to be properly configured and yesterday night I had no time for them. This evening I'll repeat tests. About FPS control, this unfortunately is reasonable: if DxWnd doesn't hook d3d, it has no way to insert delays or screen display between frames.
I'll continue the hunting: there must be something wrong I do when the d3d session is closed in hooked mode that has to be fixed.
Thank you for your effort, gho!
FPS control is one of the majority reasons to use dxwnd hooking wfsp.
The game is over fast by default.(1500fps on my pc)
The most interesting thing is FPS control can control the role movement speed meanwhile time stretching can control the role action(attack/magic etc.) speed. These two methods can not instead each other, that means time stretching can NOT control the role movement same as FPS control to the role actions.
I have to use both methods to deal with the game, wfps is the most tough game i had ever seen!
A Suggestion： Maybe you can take a look at aqrit's ddwraper(http://bitpatch.com/ddwrapper.html)
It can hook a fullscreen wfsp(at least show fps on overlay), and exit without the windows scrambled!
See how it deal with the d3d session closing!
Unfortunately it's not so easy....
I've started to comment / uncomment piece by piece the DxWnd logic, and got focus on ddraw handling (not a big surprise, but anyway....).
The problem is that on session closing I do in practice nothing, and, even commenting out that little I do, the problem still is in place. Likely, it's something I do in the middle of the session that causes the problem in the end.
What's really weird, then, is the fact that not all windows get affected, but apparently just a few that are positioned in a particular way on the screen.... puzzling, isn't it?
But, proceeding step by step, there's no doubt I'll catch it!
If the windows are located in the position of the game display area, they will not get effected.
Wfsp display area is 640 x480 (initial position x:0 y:0), windows located in that area will not get effected.
Sorry for let you doing that debugging steps... it always works but it's also a heavy and repetitive work, again and again... :(
The murderer has been captured.
The responsible of all this mess was an extra reference to the DIRECTDRAW session (see ddraw.cpp line 2854) introduced to make almost playable "Warhammer 40K Rites Of War". Unfortunately this wasn't good enough (the game crashes a few screens later) and produced this unpredicted effect on Wind Fantasy SP and maybe who knows how many others.
You can replace this attached dll and acknowledge the fix. On my PC it behaves quite ok. If everything is fine, as usual the fix will be included in next release.
So many thanks! It works! I will do some further testing when i back home.
David beat down Goliath AGAIN!
I cant believe my eyes, when i read ddraw.cpp line 2854 i find the hack is for ddraw1![if(dxw.dwDDVersion==1)] Does that mean Wfsp is a DX1 game?! It is a 2000 production. Gho you are very experienced with large amount of old diretdraw games, did you see many cases like this(use DX1 when DX7 is already out)?
PS. I find [keymapping] settings did not added in dxwnd.ini in 0.83 release.
Maybe adding something default may avoid some confusion?(I noticed you had released a new unfinished manual, may you have some extra considerations? I don't know, just a suggestion)
Is WFSP a ddraw1 game?
Well, actually no and yes at the same time ....
The curious thing is that D3D7 methods are internally referencing ddraw methods, sometimes using unsupported flags to activate the required D3D7 extensions.
This is quite strange and not at all a good practice, in my opinion, but it is undoubtfully demonstrated by the logs, where you can read for instance a CreateDevice begin trace, a huge lot of ddraw traces and finally the CreateDevice ending trace: it means that the D3D7 method is internally calling the ddraw methods!
And, of course, this fact holds for EVERY SINGLE D3D7 game, there's no way to avoid D3D7 games to reference ddraw.
This uglyness had an end with D3D8 and later, where you see no inner ddraw calls, but if you want to know the whole story, I saw that the current D3D10 / D3D11 implementation is internally calling D3D9 methods, and this is why sometimes I smile when I read articles about the supposed superiority of the latest MS D3D releases....
Last edit: gho 2014-07-10
Fix uploaded in release v2.02.84.