VOGONS


First post, by ZellSF

User metadata
Rank l33t
Rank
l33t

First trying to play this game with resolution forcing:

gorky17 2017-02-05 23-23-43-50.jpg
Filename
gorky17 2017-02-05 23-23-43-50.jpg
File size
357.87 KiB
Views
2116 views
File license
Fair use/fair dealing exception

Hmm, maybe not, let's disable resolution forcing and AA:

aaa.jpg
Filename
aaa.jpg
File size
332.78 KiB
Views
2116 views
File license
Fair use/fair dealing exception

Much better. Except for looking horribly low resolution. During our first conversation the game zooms in on our characters:

zoom.jpg
Filename
zoom.jpg
File size
307.54 KiB
Views
2116 views
File license
Fair use/fair dealing exception

Something's wrong here.

Reply 2 of 10, by ZellSF

User metadata
Rank l33t
Rank
l33t
Dege wrote:

Hmm... I can't even get into a new game via dgVoodoo (err message 'Cannot init DX device' or sg like that).
However it runs natively, so I must check it later.

Uncheck fast video memory access, make sure compatibility modes are not enabled on the exe.

Reply 3 of 10, by CoolGamer

User metadata
Rank Member
Rank
Member
Dege wrote:

Hmm... I can't even get into a new game via dgVoodoo (err message 'Cannot init DX device' or sg like that).
However it runs natively, so I must check it later.

Dege,

I also couldn't star a new game with default dgVoodoo WIP29 settings on my GT 230M, Windows 7 Ultimate 64bit laptop. I realized that Gorky 17 has the same "Fast Video Memory Access" bug that I reported for Star Wars Episode 1 Racer (Pod Racer). I wrote the details below:

1) When I choose Direct3D 11 Feature Level 10.1 (or Best Available One), I must check "Fast Video Memory Access". If I uncheck "Fast Video Memory Access", new game fails to launch.
2) When I choose Direct3D 11 Feature Level 10.0, game works with "Fast Video Memory Access" unchecked or checked.

See if you are able to launch a new game on your machine by checking "Fast Video Memory Access" or by using "Direct3D 11 Feature Level 10.0".

After the new game started, I also experienced the exact same graphical glitches that ZellSF reported.

Update: I realized that choosing Direct3D 11 Feature Level 10.0 as the output API took care of the "Hardware zoom - disappearing characters" glitch. But the boat glitch caused by resolution forcing remains. I have the GOG version of the game. I have not played the whole game yet.

Last edited by CoolGamer on 2017-02-06, 15:19. Edited 3 times in total.

Reply 6 of 10, by liqmat

User metadata
Rank l33t
Rank
l33t

I had similar issues with Wizards and Warriors where using 10.1 and 10.0 with fast vid mem disabled had dramatic different results in the end. Using 10.0 ended solving interface problems in the game where as 10.1 broke the interface. This was due to external forces outside of dgVoodoo in the end. It was an external unofficial, but necessary DirectX patch for the game that changed how dgVoodoo affected the game. Maybe something similar here? At least W&W works perfectly now. dgVoodoo is just simply an amazing piece of work! Link to my findings so far and waiting to see if Dege can figure out what is going on there.

Wizards and Warriors

Reply 7 of 10, by Dege

User metadata
Rank l33t
Rank
l33t

Yet another game uploading z-buffer image of the background by CPU (shouldn't be a problem though).

Indeed, fast vidmem access works for me, both with 10.0 and 10.1 (without forcing MSAA or resolution).
I only had a quick look to what the difference between fast/nonfast vidmem cases but for the time being, I don't know.
On dgVoodoo side nothing error happens.

FL 10.0 is more enigmatic because if no MSAA is forced then it handles z-buffers in the same way as 10.1.
The only difference between the two is the MS D3D11 implementation.

Reply 8 of 10, by Dege

User metadata
Rank l33t
Rank
l33t

This game was very tough.

What I came to is:

1) discovered (at least, for me it was new) the rendering technique of this game, but I guess it's established custom for all ones working with static background with z-buffers.
Depth map of the background isn't a real depth buffer that the game artist(s) pre-baked somehow. Instead, the particular regions (on per pixel basis) of the background are just classified into a few depth-categories: say, very near, near, middle, far and very far.
When the real z-buffers are generated then those "classifying indices" are replaced (from a lookup table) with a real z-buffer value.
Well, the interesting part is: Where do those real z-values come from? The game doesn't leave it to chance. Instead, at startup, it renders some (or various) scanlines into the z-buffer by the 3D hw itself then reads back the concrete values for later usage (content of the lookup table).
In other words, mapping of an abstract z-value in the [0..1] domain to a 16 bit z-buffer value is done by the GPU itself.

The game does some trivial checkings for the values read back, to see if accessing z-buffer is really working and make sure that not just some waste values it got back.
If the checks don't pass then 'DX initialization error' message comes.

2) I found an ugly copy-paste bug in dgVoodoo, that's why it didn't worked at all without fast vidmem access (independently on output API).
Also, I encountered another one when the DX debug layer broke the game: ironically, it affected only the most common and simple case: FL10.1 without resolution and MSAA forcing. I fixed it too.

3) However, due to the technique used for generating the z-buffer values, the game is very very sensitive to forced resolution and MSAA.
If any of them is forced then none of the rendered scanlines will be per-pixel accurate and so the game will work with corrupted z-values.

I patched the game to try to make it compatible with forced res and MSAA.
For forced res, I modified the lookup-table-filler game code to read from the z-buffer from a location of 1-2 pixels away. This seems to work.
For MSAA I modified the scanline drawer code to use pixel coordinates offseted by -0.5 to avoid blurring neighbored lines, but it doesn't work. The game stomach 2x MSAA but not higher.
For FL 10.0, forced MSAA doesn't work at all ('DX init failed' error message) because dgVoodoo cannot provide CPU-access for a z-buffer at this level, so that's normal.

Also, when resolution is forced then there are some glitches around the animated characters. So, the game can only be rendered perfectly if none of the resolution and MSAA is forced. 🙁

Gorky17_Glitches.png

Now I guess that Drunna Morbus Gravis suffers from the same problem.