lowenz wrote:

It's some z-fighting with textures over other textures.

It's there any workaorund for this?

About splinter cell.

I've seen a explanation on gamedev.net from one of the game developers about the shadow buffer issue.

As it explains, the problem is that, on most cards, its not possible to set a multisampled depth\stencil surface as the z bufffer of a non multisampled rendertarget. Now i ask, out of simple curiosity...

What would happen if dgVoodoo just returned a non-multisampled depth\stencil surface when the game tried to create a multisampled one, would it avoid the current bugs, or just make them worst ?

Tropico Gold 1.51 with dgVoodoo2 2.53 works fine in software mode, but hardware mode looks like it's not properly accounting for image stride. Curiously, Tropico 2 v. 1.2 doesn't have this issue in hardware mode with dgVoodoo2 2.53, despite being based on the same engine as the original Tropico and still using a version of DirectX prior to DX8 (contrary to the listed system requirements).

Software:

Hardware:

lowenz wrote:

It's some z-fighting with textures over other textures.

Yes, it is.

daniel_u wrote:

lowenz wrote:

It's some z-fighting with textures over other textures.

It's there any workaorund for this?

Unfortunately not, I'll have to finetune z-biasing further, in the next version.

Peixoto wrote:

About splinter cell. […]
Show full quote

About splinter cell.

I've seen a explanation on gamedev.net from one of the game developers about the shadow buffer issue.

As it explains, the problem is that, on most cards, its not possible to set a multisampled depth\stencil surface as the z bufffer of a non multisampled rendertarget. Now i ask, out of simple curiosity...

What would happen if dgVoodoo just returned a non-multisampled depth\stencil surface when the game tried to create a multisampled one, would it avoid the current bugs, or just make them worst ?

It could be an explanation for why the game itself didn't support MSAA (but buffers with different MSAA-level cannot be bound into the pipeline output even on modern hw), but not for the lack of shadows itself. That's not about that.
((But..., the game doesn't use the main z-buffer for shadow rendering, ...so it shouldn't have been a problem. The shadows themself shouldn't have been MSAA'ed.))
But what's the point? MSAA and shadow buffering is solved in dgVoodoo.

Expack3 wrote:

Tropico Gold 1.51 with dgVoodoo2 2.53 works fine in software mode, but hardware mode looks like it's not properly accounting for […]
Show full quote

Tropico Gold 1.51 with dgVoodoo2 2.53 works fine in software mode, but hardware mode looks like it's not properly accounting for image stride. Curiously, Tropico 2 v. 1.2 doesn't have this issue in hardware mode with dgVoodoo2 2.53, despite being based on the same engine as the original Tropico and still using a version of DirectX prior to DX8 (contrary to the listed system requirements).

Software:

Hardware:

Hmm... it's interesting, the same happened with SnowWave Avalanche.

Hi Dege,

just to know, are you planning INDEO support for next versions? I know this is not a very top priority since I am sure you are focusing on other more important topics, but knowing if you are going to add can help me.

Many thanks for all your help and for DGVoodoo in general (I am a big retrogamer...)

Lone Killer

Uhm, anisotropic filtering IS working in SC2.....maybe the effect is so subtle due to some anomalies in texture mipmaps?
Take a look (maximizing the image) to the wood on the floor, AF is applied!

lowenz wrote:

Uhm, anisotropic filtering IS working in SC2.....maybe the effect is so subtle due to some anomalies in texture mipmaps? Take a […]
Show full quote

Uhm, anisotropic filtering IS working in SC2.....maybe the effect is so subtle due to some anomalies in texture mipmaps?
Take a look (maximizing the image) to the wood on the floor, AF is applied!

I wonder if this related to the heat haze effect bug. It behaves something like this.The higher the resolution the less effect you'll see.
Reduce the resolution down to 640x480 and try to see if you have more AF.

I think not, but about the haze maybe it's a good thing (less distorsion but not null!).

Corrupted menu in the ultra-rare japanese port of Playstation's Warhawk (Air Assault). It is available on Shooter Legends thanks to myloch.

Not sure about the render distance, too many dark areas. It could be related to detail and resolution options, it is hard to change them with this menu.

Videos dont play either (intel indeo).

Tested latest version of the dgVoodoo with my NFS3 Modern Patch. dx6 renderer + dgvoodo's ddraw.dll has some problems.

Download: http://veg.by/files/nfs3/nfs3_modern_patch_dgbeta.7z

Problem 1. Run the game, try to minimize it using the Win key. For some reason it can't minimize, but it seems that the window loses focus. Sometimes you will see even system cursor.
Problem 2. Open nfs3.ini, change WindowedMode to 1. Run the game, start gameplay. You'll see some deadlock.

dx8 + d3d8.dll also still has the problem that I had reported earlier. But as you said, it is very hard to debug, so I'm not expecting that this will be solved.

I have a question for you, because you know programming using 3D API's well. NFS3 and NFS4 have the problem with Texel Alignment when D3D is used.

DX5/DX6/DX7/DX8:

Glide2x/Glide3x (dgVoodoo or nGlide):

On the first screenshot fonts are blurry. On the second one they are sharp. It seems that the game was developed for the texel alignment of the Glide API, but D3D uses other texel alignment, as the result we have such blurry image. I would like to fix it, but I'm not sure what exactly I have to change 😀

I'm going to fix it inside the thrash drivers. As I understand, it is needed to substract 0.5 from some values of every vertex. Thrash API uses this struct for vertices:

1/* matches DirectX7's D3DTLVERTEX */
2struct Vertex {
3    /* Vertex coordinates */
4    float x, y, z;
5    /* Reciprocal of homogeneous */
6    float rhw;
7    /* Vertex colour */
8    uint32_t color;
9    /* Specular colour */
10    uint32_t specular;
11    /* Texture coordinates */
12    float u, v;
13};

MSDN recommends to use such code:

1//adjust all the vertices to correctly line up texels with pixels 
2for (int i=0; i<6; i++)
3{
4    vertices[i].x -= 0.5f;
5    vertices[i].y -= 0.5f;
6}

But I'm not sure if it is exactly what I need. Maybe I have to fix texture coordinates, u and v (-0.5/texture_width and -0.5/texture_height, but I'm not sure how to get size of the current texture here).

I'm planning to add a code that will do such fix for every vertex that Thrash Driver accepts from the game. Is it a right way? Or maybe there are some pitfalls?

Sorry if this question is stupid. I'm still an absolute newbie in such things.

Digital Foundry recommending dgVoodoo for MDK 😀

https://www.youtube.com/watch?v=_LbIJdGNQfA

stranno wrote:

Digital Foundry recommending dgVoodoo for MDK 😀

https://www.youtube.com/watch?v=_LbIJdGNQfA

Also says to use dgVoodoo2 because it emulates a Voodoo card for Direct3D, which I don't think is correct? Got to stop with the misleading names, Dege 😜

ZellSF wrote:

Also says to use dgVoodoo2 because it emulates a Voodoo card for Direct3D, which I don't think is correct? Got to stop with the misleading names, Dege 😜

Yes, i noticed that too. But i think John knows dgv is also a d3d wrapper.

Tried Battlefield 1942 and the game is crashing if the map has too many high resolution textures loaded (1024x1024). Well, i'm not 100% sure about what causing it, but some maps with less hi-res textures are working fine and if i mod them with new textures (2048x2048 or higher) the game is crashing already at loading the level. Without dgVoodoo it's fine.

Shing wrote:

Tried Battlefield 1942 and the game is crashing if the map has too many high resolution textures loaded (1024x1024). Well, i'm not 100% sure about what causing it, but some maps with less hi-res textures are working fine and if i mod them with new textures (2048x2048 or higher) the game is crashing already at loading the level. Without dgVoodoo it's fine.

Is this the Origin freeware release, or is this a retail release? Also, just because this thread is massive as-is, what version of dgVoodoo2 are you using?

Battlefield 1942 used D3D9 i belive.

Anyway, it works perfectly fine in Windows 10 64-bit, 1080, window, WS, etc. I think dgV wont improve anything.

stranno wrote:

Battlefield 1942 used D3D9 i belive.

BF1942 used d3d 8.1.

Expack3 wrote:

Is this the Origin freeware release, or is this a retail release? Also, just because this thread is massive as-is, what version of dgVoodoo2 are you using?

Retail with gamespy patch. dgVoodoo started to work with 2.51 release if i remember well, each new final release, 2.52, 2.53 has the same errors.

stranno, as dx8gamer said it's not a DX9 game. I want to use dgVoodoo for ReShade shaders. Which is actually working perfectly, the only problem is the crashing.

Shing wrote:

Retail with gamespy patch. dgVoodoo started to work with 2.51 release if i remember well, each new final release, 2.52, 2.53 has the same errors.

Maybe you need to tweak the available VRAM for the virtual GPU (you'll need to run dgVoodoo2Setup.exe for that)? I admit, it's strange you'd suddenly need to do that now, but it's the one thing I can think to try off the top of my head since you're using a high-res texture mod.

For some reason, after you get out of water, the hud becomes discolored in WinQuake. Getting damaged fixes this.
Edit: Happens in Engoo too.