Tested right now (you're lucky, I had a copy installed on my laptop) and working perfectly!
Only thing to declare, the game breaks AERO compatibility causing some initial flickering, unless the DirectX(2) / Clipper flag is set to "ON".
If this doesn't fix the problem, please send me a logfile captured with usual debugging flags, see picture.
There is another problem. Switch the renderer to GDI (Options > Graphics > Settings: Ronin GDI SW), then play the mission mode and minimize the window, the game will crash.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can't change settings because of a dialog complaing about a missing S3DTKW.dll (see dialog screenshot)
Getting a copy of the file from my redist folder (I must have used it sometimes in the past...) and placing it to the game folder, it works, though the game crashed wexiting from the configuration panel. At next start, the game was configured and working with Ronin GDI SW renderer. I hope you have good reasons to use that one, because compared with default D3D renderer it is ugly!
During gameplay the mouse is locked, so I minimized with Win-M and Win-D, but in both cases the game resumed with no harm. Let me guess: should I make a test on a genuine XP?
Probably. Some hints:
+ Click the minimize button, the game will not crash but when restore it show blank screen.
+ If enable "Suspended injection mode", the title bar disappear and the window can't be minimize by Win-M or Win-D. Great way to prevent the crash I suppose.
Last edit: Dolphin 2016-12-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, new version should be more precise.... if vsync is not done, that should be because the application doesn't request it. Previous DxWnd releases probably inserted a vsync option by default, so the problem didn't show, but I wouldn't be surprised if the game in native mode had the same problem.
Anyway, it is also possible that I made a mistake, so I'll check ... thank you for the warning.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-08
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weird. I couldn't replicate your figures. On my pc, no matter if I set vsync in default mode or OFF, the frame rate is always no more than 75 FPS.
Oh, maybe you're running with SW renderer and counting every little update on screen.... try setting the Timing / "Updates bigger than 1-4 screen size" flag, that should give you a more accurate measure of the actual frame rate.
I made a test here but I get 288 FPS with SW renderer, uhm, same value with or without the 1/4 flag ....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-08
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-08
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ah, that makes sense. Ts2000 is more likely to skip vsync and make many tiny upfates on the screen. Make the measure with 1/4 screen option, that should give reasonable figures.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-08
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-10
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When set to DEFAULT, DxWnd lets the game use its own option: though not at all recommended, a game may specify NOWAIT or NOVSYNC options (the option codes vary depending on whether we're dealing with Btl or Flip operations, and even to the directx version number: see https://msdn.microsoft.com/en-us/library/windows/desktop/gg426181(v=vs.85).aspx and https://msdn.microsoft.com/en-us/library/windows/desktop/gg426188(v=vs.85).aspx). This is different from pevious releases where, no matter what the program was asking to, the final Blt operation to the primary surface / screen was always made with default options (WAIT, VSYNC).
It is an arguable choice, I just preferred to highlight the native behaviour of the program, though it is more likely to give some problems.
Of course, this holds unless I made some mess in the coding ... ;)
A reasonable compromise could be perhaps to set the default choice to ON in both fields?
Last edit: gho 2016-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-10
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not really.... before build 2_03_98, DxWnd was more rigid. Please, consider that in emulation mode, when the program performs a, let's say, Blt operation, with DxWnd if makes two operations: Blt to emulated primary surface and then Blt to the real primary.
So, if I remember correctly, this was before 2_03_98:
program ----> emulated primary -----------> real primary
.......according to program.......sync+wait
after 2_03_98:
program ----> emulated primary -----------> real primary
.......according to program.......according to flags
where according to flags is (per each vsync and wait flag):
default: ddraw default
on: force sync / wait
off: force nosync / nowait
The whole matter is complicated enough trying to explain the current release only, are you sure you want the full past story?
Last edit: gho 2016-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-11
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-11
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2016-12-12
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm a little skeptical about it, and I'm explaining why:
Time stretching requires hooking of several delicate system functions, and sometimes it has side effects. It may happen (I believe it happened, but I don't remember where) that some parts of the game are more "delicate" than others, and that you can get your goals by starting the game with no time stretching and then moving the slider a little later.
Now, the problem is that the system calls hooking has to take place as soon as possible (it is all within the HookInit procedure) because later on could be too late.
So, there are two quite different situations:
1) time stretching unchecked: you're not interested in this feature, once and for all during all process lifespan.
2) time stretching checked with timeslider set to 1x: you want the time stretching to be ready, all necessary hooking stuff done but no time alteration, this until you decide to move the slider.
So, your proposal, though ideally simplifying the interface, would require DxWnd to always hook the time stretching calls, just in case they could be used later on, but exposing to the risk of problems.
If you want, you can see traces of this prudent approach in the set of different available flags: the time slider also sets the stretching ratio for hardware clock ("Intercept RDTSC opcode" flag) and timers ("Stretch timers" flag) and there is also a further flag "Normalize Performance Counter" to set another slight variation of the recipy. Why all this? It would have been much simpler to start all features on the activation of a single flag (or the slider movement, as you suggested), but any of these options implies its own big risks and conditions, so I preferred to take them apart.
I hope you understand my concerns and agree.
P.s. nice new avatar, but I bet it doesn't resemble you very much. And then, smoking is not educative for the young followers :P
Last edit: gho 2016-12-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Holy hell, the main menu screen flickering like no tomorrow! Meanwhile D3DWindower works absolutely fine.
Taking a break in a while.
Bump
Oh my, how could I have missed this?
I'll start right away. If you don't get news in a day you're entitled to bump again and again ....
Tested right now (you're lucky, I had a copy installed on my laptop) and working perfectly!
Only thing to declare, the game breaks AERO compatibility causing some initial flickering, unless the DirectX(2) / Clipper flag is set to "ON".
If this doesn't fix the problem, please send me a logfile captured with usual debugging flags, see picture.
Last edit: gho 2016-12-01
There is another problem. Switch the renderer to GDI (Options > Graphics > Settings: Ronin GDI SW), then play the mission mode and minimize the window, the game will crash.
Can't change settings because of a dialog complaing about a missing S3DTKW.dll (see dialog screenshot)
Getting a copy of the file from my redist folder (I must have used it sometimes in the past...) and placing it to the game folder, it works, though the game crashed wexiting from the configuration panel. At next start, the game was configured and working with Ronin GDI SW renderer. I hope you have good reasons to use that one, because compared with default D3D renderer it is ugly!
During gameplay the mouse is locked, so I minimized with Win-M and Win-D, but in both cases the game resumed with no harm. Let me guess: should I make a test on a genuine XP?
Probably. Some hints:
+ Click the minimize button, the game will not crash but when restore it show blank screen.
+ If enable "Suspended injection mode", the title bar disappear and the window can't be minimize by Win-M or Win-D. Great way to prevent the crash I suppose.
Last edit: Dolphin 2016-12-01
Suspect lines at the end of log file:
ChangeDisplaySettingsA: lpDevMode=0 flags=0(NULL)
GDI.SelectPalette: hdc=2c010b0b hpal=188000b ForceBackground=0
GDI.RealizePalette: hdc=2c010b0b nEntries=0
Last edit: 2017-01-21
Last edit: 2017-01-21
Well, new version should be more precise.... if vsync is not done, that should be because the application doesn't request it. Previous DxWnd releases probably inserted a vsync option by default, so the problem didn't show, but I wouldn't be surprised if the game in native mode had the same problem.
Anyway, it is also possible that I made a mistake, so I'll check ... thank you for the warning.
Last edit: 2017-01-21
Weird. I couldn't replicate your figures. On my pc, no matter if I set vsync in default mode or OFF, the frame rate is always no more than 75 FPS.
Oh, maybe you're running with SW renderer and counting every little update on screen.... try setting the Timing / "Updates bigger than 1-4 screen size" flag, that should give you a more accurate measure of the actual frame rate.
I made a test here but I get 288 FPS with SW renderer, uhm, same value with or without the 1/4 flag ....
Last edit: 2017-01-21
Last edit: 2017-01-21
ah, that makes sense. Ts2000 is more likely to skip vsync and make many tiny upfates on the screen. Make the measure with 1/4 screen option, that should give reasonable figures.
Last edit: 2017-01-21
Last edit: 2017-01-21
When set to DEFAULT, DxWnd lets the game use its own option: though not at all recommended, a game may specify NOWAIT or NOVSYNC options (the option codes vary depending on whether we're dealing with Btl or Flip operations, and even to the directx version number: see https://msdn.microsoft.com/en-us/library/windows/desktop/gg426181(v=vs.85).aspx and https://msdn.microsoft.com/en-us/library/windows/desktop/gg426188(v=vs.85).aspx). This is different from pevious releases where, no matter what the program was asking to, the final Blt operation to the primary surface / screen was always made with default options (WAIT, VSYNC).
It is an arguable choice, I just preferred to highlight the native behaviour of the program, though it is more likely to give some problems.
Of course, this holds unless I made some mess in the coding ... ;)
A reasonable compromise could be perhaps to set the default choice to ON in both fields?
Last edit: gho 2016-12-10
Last edit: 2017-01-21
Not really.... before build 2_03_98, DxWnd was more rigid. Please, consider that in emulation mode, when the program performs a, let's say, Blt operation, with DxWnd if makes two operations: Blt to emulated primary surface and then Blt to the real primary.
So, if I remember correctly, this was before 2_03_98:
program ----> emulated primary -----------> real primary
.......according to program.......sync+wait
after 2_03_98:
program ----> emulated primary -----------> real primary
.......according to program.......according to flags
where according to flags is (per each vsync and wait flag):
default: ddraw default
on: force sync / wait
off: force nosync / nowait
The whole matter is complicated enough trying to explain the current release only, are you sure you want the full past story?
Last edit: gho 2016-12-10
Last edit: 2017-01-21
Last edit: 2017-01-21
Last edit: 2017-01-21
I'm a little skeptical about it, and I'm explaining why:
Time stretching requires hooking of several delicate system functions, and sometimes it has side effects. It may happen (I believe it happened, but I don't remember where) that some parts of the game are more "delicate" than others, and that you can get your goals by starting the game with no time stretching and then moving the slider a little later.
Now, the problem is that the system calls hooking has to take place as soon as possible (it is all within the HookInit procedure) because later on could be too late.
So, there are two quite different situations:
1) time stretching unchecked: you're not interested in this feature, once and for all during all process lifespan.
2) time stretching checked with timeslider set to 1x: you want the time stretching to be ready, all necessary hooking stuff done but no time alteration, this until you decide to move the slider.
So, your proposal, though ideally simplifying the interface, would require DxWnd to always hook the time stretching calls, just in case they could be used later on, but exposing to the risk of problems.
If you want, you can see traces of this prudent approach in the set of different available flags: the time slider also sets the stretching ratio for hardware clock ("Intercept RDTSC opcode" flag) and timers ("Stretch timers" flag) and there is also a further flag "Normalize Performance Counter" to set another slight variation of the recipy. Why all this? It would have been much simpler to start all features on the activation of a single flag (or the slider movement, as you suggested), but any of these options implies its own big risks and conditions, so I preferred to take them apart.
I hope you understand my concerns and agree.
P.s. nice new avatar, but I bet it doesn't resemble you very much. And then, smoking is not educative for the young followers :P
Last edit: gho 2016-12-12