VOGONS


First post, by stranno

User metadata
Rank Member
Rank
Member

I was excited with this "port" in Steam, released yesterday, but then i saw it was just a crappy repack of the OG Windows D3D release + dgVoodoo + Winmm. GOG style.

Dege, do you know something about this? I dont know what license you use, can a game pack dgV for commercial use?

Reply 1 of 25, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
http://dege.freeweb.hu/ wrote:

Partnership with GOG has begun!, You can expect releases of old DirectX titles being more compatible with modern Windows operating systems, powered by dgVoodoo!

So i guess legit 😀

Reply 2 of 25, by stranno

User metadata
Rank Member
Rank
Member
spiroyster wrote:

So i guess legit 😀

I know but this is a Steam-only game.

And i doubt it have Dege's support since it is packed with D3DImm.dll and D3D8.dll. And the game dont support DirectDraw or Direct3D8. It is a Direct3D 5 game.

Reply 3 of 25, by VirtuaIceMan

User metadata
Rank Oldbie
Rank
Oldbie

True, it is D3D5, but dgVoodoo2 allows it to be run in HD; here's a screenshot from my original CD version running with dgVoodoo2: http://i.imgur.com/qrqCwjA.jpg

My PC spec: Win10 64bit, i7-4970K (not overclocked), KFA2 GeForce RTX 2070 SUPER, Creative Soundblaster ZXr, 16GB RAM, Asus Z97-A motherboard, NZXT 410 case, ROG Swift GSYNC monitor

Reply 5 of 25, by Dege

User metadata
Rank l33t
Rank
l33t

It's using dgVoodoo but I have an agreement with Throwback Entertainment, so it's OK.

DDraw.dll and D3DImm.dll are needed, because D3DImm is not a standalone module, it depends and relies on DDraw.

ZellSF wrote:

If it's using dgVoodoo2, the negative review that it runs 5 FPS on a decent setup and another one complaining about geometry issues seem weird. dgVoodoo2 has neither of these problems.

Me too cannot understand that geometry issue thing, my only tip is the gamer in question has a (n over-optimised for newest AAA titles) game-ready driver which is broken for general usage.
As for the 5FPS, it's a valid phenomenon, I myself experienced it sometimes. Quote myself from Steam:

This game has a built in frame rate limiter, which caps the FPS to 30-32 by default.
Probably it all is solved by a Windows timer and when low fps's are being produced then the game is spinning in a short waiting loop. Since Windows kernel is tickless from Windows 8, I guess there is a compatibility problem with timers. When an application, like a browser or another game or anything else sets the 'global timer granularity' then timers of other programs like XG-2 behave inaccurately, that's why frame rate is limited to 5-6 FPS. A clean reboot should always solve the problem, and even it shouldn't be a problem on Windows 7.

The best would be removing all the limiter code from the game, but it's not so easy. When I experimentally did that then the game ran at solid 60 FPS (after 6) but the game logic ran way too fast and the game became unplayably fast.

I experienced this with ThreePixels demos too, their engine must use the same timing technique.
What is weird however, I always thought that an average user won't run into it. A lot of times I just killed the D3D11 processes from the debugger when working on dgVoodoo and I thought this all is related to that (the OS doesn't handle forced resource destroying properly). A reboot helped.

Reply 6 of 25, by stranno

User metadata
Rank Member
Rank
Member

Well, i imagined it once i saw your post on the Steam forums.

I guess i will change my review. I really dont like the way the game have been re-released, since everyone can do that (except your personal improvements), i dont like this kind of repacks as well as i dont like most of GOG repacks or Dotemu stuff.

But you (as well as Zeus nGlide or Gho DXWnd) totally have my respect and my support so i guess i will write it from other perspective.

Edit: I think i have used D3D 1-7 before without DDraw library, i was pretty sure it wasnt needed. Thanks for the clarification.

Reply 7 of 25, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
stranno wrote:

I really dont like the way the game have been re-released, since everyone can do that (except your personal improvements), i dont like this kind of repacks as well as i dont like most of GOG repacks or Dotemu stuff.

Isn't the game in its original format completely unusable? I suspect 90% of people interested in running the game cannot be bothered to do any kind of reconfiguration, even with simple instructions.

Reply 8 of 25, by stranno

User metadata
Rank Member
Rank
Member
Jorpho wrote:

Isn't the game in its original format completely unusable? I suspect 90% of people interested in running the game cannot be bothered to do any kind of reconfiguration, even with simple instructions.

No. It can be installed in Windows 10 64-bit and you can use both Winmm and dgVoodoo.

I havent ever seen, and i have lots of games, a GOG/Dotemu game with any special fix at all. All i have seen can be repacked by anyone with some experience. From extracting the registry entries, to use 16-bit installers workarounds, to use any kind of wrapper, etc.

The only fixed game i have seen so far is The Saboteur, GOG fixed a classic problem, the map was totally messed up in resolutions above 720p.

There are probably more fixed games, but most of them are just repacked.

Reply 9 of 25, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
stranno wrote:
Jorpho wrote:

Isn't the game in its original format completely unusable? I suspect 90% of people interested in running the game cannot be bothered to do any kind of reconfiguration, even with simple instructions.

No. It can be installed in Windows 10 64-bit and you can use both Winmm and dgVoodoo.

That's exactly what I mean. You can't expect Steam or GOG to offer the game in its original format with instructions for the end-user to manually configure Winmm and dgVoodoo.

I havent ever seen, and i have lots of games, a GOG/Dotemu game with any special fix at all.

Do you mean without any special fix?

All i have seen can be repacked by anyone with some experience.

Then that would exclude the significant proportion of the audience with no experience. It's bad business.

Reply 10 of 25, by stranno

User metadata
Rank Member
Rank
Member
Jorpho wrote:

Do you mean without any special fix?

I mean all games are straight repacks, without any workaround, aside dosbox, wrappers, patches, cracks, etc. Except The Saboteur, and i am very happy with that because it is a Pandemic Studios masterpiece, but partially unplayable in PC because of the map.

Reply 11 of 25, by UCyborg

User metadata
Rank Member
Rank
Member

Out of curiosity, what is this strange timing technique? It seems common with multimedia applications to bump timer granularity to 1 ms, which should result in timing functions to report more accurate times, default being around 16 ms. If the application doesn't do it explicitly, it may be done by the underlying framework.

And then I've read some things about some people messing with HPET setting in BIOS and turning on useplatformclock with bcdedit to supposedly fix certain performance issues in games.

Windows 8+ also default to hybrid shutdown so if there are resource leaks or similar issues, this feature would pronounce the problem since there could be weeks since last clean boot.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 12 of 25, by Dege

User metadata
Rank l33t
Rank
l33t

I don't know it yet because I never tried to check out the reason, only experienced it.
Maybe I'm wrong and the issue isn't strictly related to timers. But Arklay reported similar behavior with Dino Crisis 2:

Re: dgVoodoo 2 for DirectX 11

+

Dino Crisis (Again!)
This is unbelievable! I tried dgvoodoo 2.42 only for another test and nothing was changed, for no reason I opened power archiver and restarted the game. The game was running at 30 fps! I closed power archiver and the fps dropped at 12 fps, I reopened power archiver and the games was at 30 fps again!

So, I still have the feeling it has to do something with tickless Windows kernel. 😁

Reply 13 of 25, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I was looking at https://en.wikipedia.org/wiki/DirectMusic just now and noticed this. Related?

On Microsoft Windows Vista, DirectMusic uses only software synthesis. Also, the DirectMusic kernel mode synthesizer that supplies the DirectMusic components with a high-resolution timer has been removed.

I can't seem to find what happened to the MSKB article, but it's on archive.org .
https://web-beta.archive.org/web/200904171849 … t.com/kb/943253

When the synthesizer was removed, no other kernel mode component supported a DirectMusic clock. Therefore, Windows Vista uses the clock that is provided by the WinMM component.

Reply 14 of 25, by Dege

User metadata
Rank l33t
Rank
l33t

The mystery is solved!

When I did a clean boot then XG-2 always ran at ~30 FPS, as expected. I experimented with global Windows resolution timer without avail, XG-2 still ran fine.
(I tried XG-2 with the 15.6ms default system timer resolution, then, knowing that WPF sometimes sets it to 1ms, launching a compile in Visual Studio was enough to force it to 1ms, I always checked it.)

Everything was fine, so gave up and started to work on other things. Then later I re-tried XG-2 and it ran at 13 FPS!! I had no a clue why because I didn't do anything special inbetween.

I worked myself up into debugging to see what the f*ck was going on but all I saw that the game timing heavily relied on timeGetTime.
When low FPS' were produced it was just spinning in a loop, decreasing a very high counter towards zero.
Ok, so that was the cause but why was the counter so high? It came from a global that the game constantly updated and its value was ~10 or so when the game was starting up. But later, it went up to ~17000000.
All in all, debugging out where that global is updated, it turned out that XG-2 calls timeGetTime to query the current time. Need to know, that timeGetTime returns the time that has elapsed since Windows was started, in ms.
XG-2 divided it by 30 (the hardwired frame rate), to get how many frame would have been rendered if XG-2 were launched along with Windows (absolute frame number instead of relative). A bit weird, but it's ok after all.
The problem itself was that time value was stored into a global 32 bit float and that has only 23 bit precision, so, if one calculates it all it turns out that the float loses its precision after Windows is been running for about 3 days without rebooting.
Later in the spinning loop, it tried to substract 1.0 from that precision-loss float in each iteration but the counter remained the same (because the lowest bit of the integer couldn't be stored in the float). So, it always resulted in tons of iterations, hence the low fps. 😵
What is also very nice, is that the more time is Windows running for, the less fps you get because the float loses more and more precision. So I guess if I run my windows a few more days I'll only get 5-6 FPS's instead of 13.

Since rewriting the code by changing the float in question to a double would take too much time, I experimented with a stub WINMM.DLL where timeGetTime returns a value having the highest 8 bits masked out, to keep only the lower 24.
And voila, XG-2 ran at 34 FPS again.
😎

I also experimented with time dilating by scaling the value of timeGetTime and the game speed indeed changed. The only problem is, FPS changes too. Game logic and render speed are tied together in XG-2.

Reply 16 of 25, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

That sounds strangely familiar.

A quick search reveals that similar problems were reported with UT99.
Re: How do you fix the timing glitch on Unreal Tournament '99?

Will this fix be pushed to the Steam version?

Reply 17 of 25, by VicRattlehead

User metadata
Rank Newbie
Rank
Newbie

I noticed something similar with MechWarrior 3 where the game would seemingly randomly start showing some problems such as emplaced turrets refusing to fire, the reticle going haywire, or everything being jittery which would then go away after a proper reboot (rather than just the fake shutdown that Windows 8 does). I think bugs that have to do with physics such as inadequate jumpjet thrust and the infamous bouncing APCs are a CPU issue though.

Reply 18 of 25, by UCyborg

User metadata
Rank Member
Rank
Member

So it is a game timing bug after all. Nice find, I thought it was strange that it would be connected to Windows.

VicRattlehead wrote:

I think bugs that have to do with physics such as inadequate jumpjet thrust and the infamous bouncing APCs are a CPU issue though.

Have you tried limiting the game FPS? I know Interstate '76 has to run at 20 FPS (30 works, but 20 is better for accuracy), otherwise physics is totally off; wobbly wheels, cars being significantly slowed down by the slightest slope and not accelerating properly, weapons not firing and sounding properly.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 19 of 25, by VicRattlehead

User metadata
Rank Newbie
Rank
Newbie
UCyborg wrote:
VicRattlehead wrote:

I think bugs that have to do with physics such as inadequate jumpjet thrust and the infamous bouncing APCs are a CPU issue though.

Have you tried limiting the game FPS? I know Interstate '76 has to run at 20 FPS (30 works, but 20 is better for accuracy), otherwise physics is totally off; wobbly wheels, cars being significantly slowed down by the slightest slope and not accelerating properly, weapons not firing and sounding properly.

Limiting the FPS alleviates those issues in MW3 for sure, but I think they're nonetheless tied to CPU speed. I haven't done any tests in MW3 throttling CPU speed yet, but my experience in Prince of Persia 3D leads me to believe that that is the case in MW3. In Prince of Persia 3D, limiting the FPS to 30 can alleviate timing issues with elevators and moving platforms whereas throttling the CPU speed with a program such as Battle Encoder Shirase eliminates the problem even at 60 FPS.