LoneKiller wrote:

Hi Dege, […]
Show full quote

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

Yes, I'm planning. I hope I won't run into any unresolvable problem with that.

ZellSF wrote:

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 😜

I don't know what would be more misleading: renaming the wrapper to someting else or keep dgVoodoo. 😁
(I too noticed, that some people still think that it all is fully tied to 3Dfx technology somehow. I mean, the DX part.)

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.

Did increasing the amount of VRAM (as Expack recommended) solve the problem?
I haven't yet tested this game.

VEG wrote:

Tested latest version of the dgVoodoo with my NFS3 Modern Patch. dx6 renderer + dgvoodo's ddraw.dll has some problems. […]
Show full quote

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:

Copy code to clipboard

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:

Copy code to clipboard

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.

So, the old problems are still present...
I hoped it would get fixed somehow like with Commandos 3 did. 😁 😁 😁

Yes, if I remember correctly, Glide has pixel center at .5 positions, while DX<=9 has it at .0 (integer).
So, if Trash driver accepts TL vertices then applying and offset on x and y with +0.5 should do the trick.
Changing texture coordinates is the more complicated way because tex coords are normalized to texture size, so the offset depends on texture size. As for the result, it doesn't matter which one is changed (vertex or tex coord), the point is that they do be in correct matching. That is, center of the texels match the center of the pixels.

BTW, thanks for the new reports!!

Dege wrote:

Did increasing the amount of VRAM (as Expack recommended) solve the problem?
I haven't yet tested this game.

Thanks for the suggestion, but i already set the amount of VRAM to max. I have HD6870 with 1GB VRAM. I tested the game at 640x480 resolution too, played with dgvoodoo settings... nothing helps. And is that possible your wrapper made frame-times better? The game feels much smoother with dgvoodoo. Didn't feel this with previous versions, only with V2.53.

Dege wrote:

LoneKiller wrote:

I hoped it would get fixed somehow like with Commandos 3 did. 😁 😁 😁

It's perfect now (Commandos 3) ! No more (image) ghosting with 3D lights.

Dege wrote:

Yes, if I remember correctly, Glide has pixel center at .5 positions, while DX<=9 has it at .0 (integer).
So, if Trash driver accepts TL vertices then applying and offset on x and y with +0.5 should do the trick.
Changing texture coordinates is the more complicated way because tex coords are normalized to texture size, so the offset depends on texture size. As for the result, it doesn't matter which one is changed (vertex or tex coord), the point is that they do be in correct matching. That is, center of the texels match the center of the pixels.

Thanks for this valuable information. But which variant is ideologically better for your opinion? Now I know how to get the size of the current texture, so it is easy to calculate 0.5/texture_width and 0.5/texture_height one time when current texture is changed, and it almost doesn't complicate the task.

UPD. Ok, it seems that with u and v I have to do something else than just do u = u + 0.5/texture_width and v = v + 0.5/texture_height, because it works in the menu, but it is a bit buggy during gameplay (or maybe my code which gets current texture's height and width is wrong). So, I have simplified my code and now it's just doing x = x - 0.5 and y = y - 0.5, and it seems that it works very nice, exactly like when Glide API is used =) The code is simple, so I'll port it to some other thrash D3D renderers. Thank you for your suggestion.

UPD2. The last problem with DX7 renderer which affects both NFS3 and NFS4. This strange thing:

All other renderers, inclusive DX5, DX6, DX8 and Glide3x, don't have this ugly thing. I had seen the model of the track and it seems that there is placed a tree with fully transparent texture. But I wouldn't like to modify the game data files. Maybe DX7 uses some different default value for some state or flag, and it causes this effect for such "invisible" trees. Do you have some quick ideas which flag it could be? 😊

This is hard, beginning from the game 😁

Codename: Outbreak (STALKER series dad!)

Why the configurator can't see the other 32 bit resolutions through dgVoodoo2?
Is it a limit of the *GAME* configurator utility?

i just tested myself and it enumerated up to 1152x864x32 in the configurator for me. but setting the game at 1024x768x32 but having dgVoodoo force upscale to 1440xx1080 looks nice.

I can force the resolution directly in the config file.
The problem is why the CO configurator can't see the other resolutions. Maybe there's a limit number and it's not a dgVoodoo2 issue.

XCOM: Enforcer runs fine with dgVoodoo2 2.53 when using the software renderer as well as using the 3dfx Glide renderer with Glide 2x. However, when running in D3D mode, I get the following message:

1---------------------------
2Critical Error
3---------------------------
4Ran out of virtual memory. To prevent this condition, you must free up more space on your primary hard disk.
5
6
7
8History: FMallocWindows::Malloc <- UD3DRenderDevice::CreateVideoTexture <- AllocTextures <- UD3DRenderDevice::SetRes <- UD3DRenderDevice::Init <- UWindowsViewport::TryRenderDevice <- UWindowsViewport::OpenWindow <- UGameEngine::Init <- InitEngine

Yay; Delta Force Land Warrior is finally working with forced resolution!

Actually, there is one bothersome bug however; when moving the mouse to the right in game the aiming moves at a steady pace. Moving the mouse to the left however makes the sensitivity somehow a lot higher in that direction. That does not happen while deactivating the wrapper altogether, but then I have to play with a low resolution.

MrEWhite wrote:

http://images.akamai.steamusercontent.com/ugc/258218890813294996/085E77C70B6B30B0C159EEB44E2D4026B4DDA3B6/ For some reason, afte […]
Show full quote

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

I am going to ask a real stupid question, but I am genuinely curious. Why are we playing winQuake instead of GLQuake or one of the many source ports? Is there an actually difference in how it plays from all the other versions?

Expack3 wrote:

XCOM: Enforcer runs fine with dgVoodoo2 2.53 when using the software renderer as well as using the 3dfx Glide renderer with Glid […]
Show full quote

XCOM: Enforcer runs fine with dgVoodoo2 2.53 when using the software renderer as well as using the 3dfx Glide renderer with Glide 2x. However, when running in D3D mode, I get the following message:

Copy code to clipboard

1---------------------------
2Critical Error
3---------------------------
4Ran out of virtual memory. To prevent this condition, you must free up more space on your primary hard disk.
5
6
7
8History: FMallocWindows::Malloc <- UD3DRenderDevice::CreateVideoTexture <- AllocTextures <- UD3DRenderDevice::SetRes <- UD3DRenderDevice::Init <- UWindowsViewport::TryRenderDevice <- UWindowsViewport::OpenWindow <- UGameEngine::Init <- InitEngine

Try 128 MB of VRAM.

Hi! Thanks for your hard work on dgVoodoo. I just wanted to report a crash I had. I went to test Shadow of Destiny using the recently made fix, but it crashes on loading. I didn't seem to be able to fix it by changing VRAM size or resolution. It does load using the passthrough option, though. Aside from that, I'm not sure what to try...
Once again, thanks!

lowenz wrote:

Expack3 wrote:

XCOM: Enforcer runs fine with dgVoodoo2 2.53 when using the software renderer as well as using the 3dfx Glide renderer with Glid […]
Show full quote

XCOM: Enforcer runs fine with dgVoodoo2 2.53 when using the software renderer as well as using the 3dfx Glide renderer with Glide 2x. However, when running in D3D mode, I get the following message:

Copy code to clipboard

1---------------------------
2Critical Error
3---------------------------
4Ran out of virtual memory. To prevent this condition, you must free up more space on your primary hard disk.
5
6
7
8History: FMallocWindows::Malloc <- UD3DRenderDevice::CreateVideoTexture <- AllocTextures <- UD3DRenderDevice::SetRes <- UD3DRenderDevice::Init <- UWindowsViewport::TryRenderDevice <- UWindowsViewport::OpenWindow <- UGameEngine::Init <- InitEngine

Try 128 MB of VRAM.

i have Enforcer on steam so tried it for myself. i get the same error at 128mb, 512mb and 1024mb vram (though 1024 did pop up a "can't find file galaxy" error from the game instead once despite it being a fresh install and the fact it does work with glide). i am also finding i have to edit the ini to force it into 32bit colour for glide though.

Glide is 16bit only (but dgVoodoo2 transforms automatically to 32 bit). You don't have to force nothing.
UE1 D3D has that strange problem (the VRAM size related one), can you test with the Radeon 8500/GeForce 4 preset?

Geforce,Radeon,dgVoodoo 3D Accel Presets w/ 64mb: Works!
Geforce Preset w/ 128mb or 256mb: loads the intros then tries to precache and dies with the Virtual memory error. Tried entering 512 and 1024mb into the box and same results.
Radeon Preset (128/256mb):
Can't find file for package 'Galaxy'
History UObject::SafeLoadError <- UObject::StaticLoadClass <- UEngine:InitAudio <- UGameEngine::Init <- InitEngine

VEG wrote:

Thanks for this valuable information. But which variant is ideologically better for your opinion? Now I know how to get the size […]
Show full quote

Dege wrote:

Yes, if I remember correctly, Glide has pixel center at .5 positions, while DX<=9 has it at .0 (integer).
So, if Trash driver accepts TL vertices then applying and offset on x and y with +0.5 should do the trick.
Changing texture coordinates is the more complicated way because tex coords are normalized to texture size, so the offset depends on texture size. As for the result, it doesn't matter which one is changed (vertex or tex coord), the point is that they do be in correct matching. That is, center of the texels match the center of the pixels.

Thanks for this valuable information. But which variant is ideologically better for your opinion? Now I know how to get the size of the current texture, so it is easy to calculate 0.5/texture_width and 0.5/texture_height one time when current texture is changed, and it almost doesn't complicate the task.

UPD. Ok, it seems that with u and v I have to do something else than just do u = u + 0.5/texture_width and v = v + 0.5/texture_height, because it works in the menu, but it is a bit buggy during gameplay (or maybe my code which gets current texture's height and width is wrong). So, I have simplified my code and now it's just doing x = x - 0.5 and y = y - 0.5, and it seems that it works very nice, exactly like when Glide API is used =) The code is simple, so I'll port it to some other thrash D3D renderers. Thank you for your suggestion.

UPD2. The last problem with DX7 renderer which affects both NFS3 and NFS4. This strange thing:

All other renderers, inclusive DX5, DX6, DX8 and Glide3x, don't have this ugly thing. I had seen the model of the track and it seems that there is placed a tree with fully transparent texture. But I wouldn't like to modify the game data files. Maybe DX7 uses some different default value for some state or flag, and it causes this effect for such "invisible" trees. Do you have some quick ideas which flag it could be? 😊

Yes, modifying the vertex x,y is the better way, I think, or else you have to modify every other vertex component like texcture coords, color, etc. It's not necessary a hard task for a classic TL vertex, but for TL vertices with multiple tex coords or non-fixed function vertex types with unknown vectors (coded into texcoord components) it's either hard or impossible.
I, too, offset the pixel center in dgVoodoo to map between DX<=8 and DX11.

The polygon glitch is strange because I don't think that there is any difference between DX6 and DX7.
Is transparency solved with textures with alpha channel or legacy colorkeying?
If alphaed textures then DX6 and DX7 should be equivalent but the thrash driver may configure the fixed function pipeline in some other way for DX7, for some reason.
If colorkey then it's MAYBE renderstate D3DRENDERSTATE_COLORKEYBLENDENABLE, it's DX7-only and if it's enabled then colorkeyed pixels forced to 0 without discarding the pixel.
But, it all should be debugged.

----

Out of virtual memory:
Once I debugged through Unreal Tournament to see what's going on. Texture manager of unreal engine wants to create and load more managed textures when 256MB video memory is available than with 128MB. In fact, it wanted to create tons of it: after more than 18000 textures it gave up with the out-of-memory. With 128MB approximately only half that many ones was enough for the engine to have in the texture cache.
Both dgVoodoo and the engine allocates additional memory for each texture and it causes the ~2GB virtual address space to get filled up. That's whay the error message comes.
I'd like to optimize this thing for dgVoodoo surfaces because additional memory is not needed in all cases. Hopefully that will solve the problem.

lowenz wrote:

I can force the resolution directly in the config file.
The problem is why the CO configurator can't see the other resolutions. Maybe there's a limit number and it's not a dgVoodoo2 issue.

All the other things like this, and cursor, and so on should be tested by me. I'll do it. Thx for the reports!

JJXB wrote:

Geforce,Radeon,dgVoodoo 3D Accel Presets w/ 64mb: Works! Geforce Preset w/ 128mb or 256mb: loads the intros then tries to preca […]
Show full quote

Geforce,Radeon,dgVoodoo 3D Accel Presets w/ 64mb: Works!
Geforce Preset w/ 128mb or 256mb: loads the intros then tries to precache and dies with the Virtual memory error. Tried entering 512 and 1024mb into the box and same results.
Radeon Preset (128/256mb):
Can't find file for package 'Galaxy'
History UObject::SafeLoadError <- UObject::StaticLoadClass <- UEngine:InitAudio <- UGameEngine::Init <- InitEngine

Unreal Engine 1 classic issue 😁

Dege wrote:

Out of virtual memory: Once I debugged through Unreal Tournament to see what's going on. Texture manager of unreal engine wants […]
Show full quote

Out of virtual memory:
Once I debugged through Unreal Tournament to see what's going on. Texture manager of unreal engine wants to create and load more managed textures when 256MB video memory is available than with 128MB. In fact, it wanted to create tons of it: after more than 18000 textures it gave up with the out-of-memory. With 128MB approximately only half that many ones was enough for the engine to have in the texture cache.
Both dgVoodoo and the engine allocates additional memory for each texture and it causes the ~2GB virtual address space to get filled up. That's whay the error message comes.
I'd like to optimize this thing for dgVoodoo surfaces because additional memory is not needed in all cases. Hopefully that will solve the problem.

Setting VRAM to 128 MB actually solves the problem I was having with XCOM: Enforcer!

Presbytier wrote:

MrEWhite wrote:

http://images.akamai.steamusercontent.com/ugc/258218890813294996/085E77C70B6B30B0C159EEB44E2D4026B4DDA3B6/ For some reason, afte […]
Show full quote

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

I am going to ask a real stupid question, but I am genuinely curious. Why are we playing winQuake instead of GLQuake or one of the many source ports? Is there an actually difference in how it plays from all the other versions?

Software looks superior to hardware rendered ports in my opinion. I also use a WinQuake sourceport called "QDOS" and it works really well.

MrEWhite wrote:

Presbytier wrote:

MrEWhite wrote:

http://images.akamai.steamusercontent.com/ugc/258218890813294996/085E77C70B6B30B0C159EEB44E2D4026B4DDA3B6/ For some reason, afte […]
Show full quote

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

I am going to ask a real stupid question, but I am genuinely curious. Why are we playing winQuake instead of GLQuake or one of the many source ports? Is there an actually difference in how it plays from all the other versions?

Software looks superior to hardware rendered ports in my opinion. I also use a WinQuake sourceport called "QDOS" and it works really well.

I never played anything but GLquake, but I just found out the gog version comes with winquake the exe is in the game folder, tried it and it runs flawlessly. I can definitely see the appeal definitely looks different.