Dege wrote:

I'm planning to get a HD7730 for that purpose.

If it isn't a secret, when are you planning to do it? 😀

VEG wrote:

Dege wrote:

I'm planning to get a HD7730 for that purpose.

If it isn't a secret, when are you planning to do it? 😀

Soon. 😀
I have other things to do for now but I'm going to order the card.

Dege, about the video scaling problem, you can take a look here: https://www.dxgl.info/Downloads (source)

lowenz wrote:

Dege, about the video scaling problem, you can take a look here: https://www.dxgl.info/Downloads (source)

Technically he cannot, DXGL is licensed GPL 2.1, while dgVoodoo2 is closed source. To actually use code from a GPL-licensed source in a closed-source project would be a license violation.

lowenz wrote:

Dege, about the video scaling problem, you can take a look here: https://www.dxgl.info/Downloads (source)

DXGL wraps to OpenGL so, it works right automatically (like DX<=9) AFAIK. At least I guess, never tried DXGL.

Stiletto wrote:

lowenz wrote:

Dege, about the video scaling problem, you can take a look here: https://www.dxgl.info/Downloads (source)

Technically he cannot, DXGL is licensed GPL 2.1, while dgVoodoo2 is closed source. To actually use code from a GPL-licensed source in a closed-source project would be a license violation.

You're right! But maybe some form of "inspiration" for a workaround 😁

From what I read earlier it's not really a scaling problem, but a input handling one (if he scales the image, he'll also have to scale mouse input) and then I think DxWnd would be more interesting to look at. That's not released under any license though.

Off-topic, but DXGL just had another release that adds support for windows and borderless fullscreen which supposedly is better for dealing with GDI interaction.

Dege: have you considered adding an option for borderless fullscreen and an option for changing desktop resolution to match game resolution? That would probably work for AMD users, at the cost of more options you don't want.

ZellSF wrote:

From what I read earlier it's not really a scaling problem, but a input handling one (if he scales the image, he'll also have to scale mouse input) and then I think DxWnd would be more interesting to look at. That's not released under any license though.

Off-topic, but DXGL just had another release that adds support for windows and borderless fullscreen which supposedly is better for dealing with GDI interaction.

Yes, stretching the output with proper aspect ratio itself is not a big deal: let's set the display to fullscreen in native resolution (it's the only one that can be trusted) and output the properly stretched image to that. dgVoodoo already has this cap inside but can't be reached through the setup.
It's the same, in the aspect of the image appearance, as if one overrides the display mode to 'stretched with aspect ratio' on the driver control panel.
However, in other respects, it's not the same at all.
For example, if a game sets its display mode to 640x480 then it expects that size of its window is 640x480 too, that's the area where the mouse can move (the side black bars are not even parts of the desktop since the scaling is done on the GPU).
But when the native resolution is used then its window has to be stretched to, say, 1920x1080 so the extent of mouse area stretched too, the cursor can even be moved to the blank areas.
So it all needs mouse emulation, scaling and excluding the cursor from the blank area. As for the perfect solution, it doesn't only mean overriding some mouse messages (altough it would sure work for most games) but some winapi hooking too (which can even conflict with the application). So I feel this solution is not a 'sterling one', not equivalent to GPU-scaling available on nVidias.

ZellSF wrote:

Dege: have you considered adding an option for borderless fullscreen

As for borderless fullscreen, I was planning it: once this native-resolution-fullscreen solution is available then the only difference between that and the borderless case is not switching to 'true fullscreen' through DXGI.

ZellSF wrote:

and an option for changing desktop resolution to match game resolution? That would probably work for AMD users, at the cost of more options you don't want.

Desktop resolution is already changed to game resolution. The problem is that if it doesn't match the native resolution of the monitor then its appearance is either stretched or centered (but logically it appears correctly as part of the desktop. On a two-monitor system, if you switch one display to say 800x600, and look at the display layout on the Windows system dialog on another monitor then you'll see that monitor area as 800x600. Shortly, a logical display layout and its appearance can be different).

Tested with UT2004 and Unreal2 on a Win10 64 system. dgVoodoo is litterally *necessary*, 'cause without it the 2 games can run (ReduceMouseLag=false) but the gamma management is wrong.
Thanks Dege, you're really a legacy gaming hero 😁

PS: NPatches suppport will ever come to dgVoodoo? Unreal Engine games use it and it would be interesting to test :p

Thanks! 😀

Would be nice but I'm not going to give a high priority to that. Unfortunately there are more important issues to handle. 🙁
Like that stretching disaster.

Desktop resolution is already changed to game resolution. The problem is that if it doesn't match the native resolution of the monitor then its appearance is either stretched or centered (but logically it appears correctly as part of the desktop. On a two-monitor system, if you switch one display to say 800x600, and look at the display layout on the Windows system dialog on another monitor then you'll see that monitor area as 800x600. Shortly, a logical display layout and its appearance can be different).

What I mean is actually change desktop resolution from a non-D3D11 API and just render in a borderless window.

It's already possible to do this with dgVoodoo2, but requires external tools for both borderless and setting desktop resolution. A builtin option could be helpful to AMD users.

Hey uh Dege, are you going to make dgVoodoo fo DX12?

Silanda wrote:

Just another quick report.

Tender Loving Care (Windows DVD-ROM version):
This FMV game does not work on Windows 10 (or 8 I'd assume) due to graphic corruption in the game sections. Those work dgVoodoo, however, the bulk of the video plays back using MCI I believe (and in a separate, overlayed window unless an option is changed in the game's ini), and just displays as a small white window. Would I be right in thinking that's due to the lack of GDI hooking?

Just going to follow up on this. The game does actually work with dgVoodoo, but with a couple of caveats: dgVoodoo doesn't seem to get along well with Windows 10's own MPEG 2 codec, in this game at least. Installing LAV filters gets around this problem as long as they're not set to use CUDA for decoding. Secondly, the game's .exe needs to either be hacked so that it ignores a particular error (when using LAV in combination with dgVoodoo the game complains about an MCI error to do with setting the MPEG time format), or the .exe from the CD version of the game needs to be used.

The only problem I've really encountered is that the game seems to be using the desktop resolution after playing a video sequence, therefore displaying in the wrong aspect ratio. This can be mitigated by switching the desktop to a 4:3 resolution.

Incidentally, the CD version works fine natively. I guess that the DVD version's method of displaying video clashes somehow with Windows 10's own implementation of Direct Draw.

And a couple of compatibility reports:

Resident Evil: Seems to switch to low resolution and doesn't render properly. Videos display a black screen.

Resident Evil 2: Renders fine in software mode except the videos display a black screen. Complains about Direct X initialisation failure if trying to play with a hardware mode.

Btw, please fix the 128+ resolution enumerating bug 🙁

It's really annoying to have to remove half my custom resolutions each time I have a need to force a refresh rate.

Some problems with dgVoodoo and original renderer of UT and Unreal Gold (DirectDraw / D3D7? ), from Unreal Anthology (2006) + unofficial patch ( http://ego-creations.de/scripts/download.php?DownID=26 )

Unreal:

UT (no sound mode):

lowenz wrote:

Windows 7 64 / Radeon HD 7850 / Catalyst 16.1 […]
Show full quote

Windows 7 64 / Radeon HD 7850 / Catalyst 16.1

Native MS D3D8: no problem

dgVoodoo: some artifacts (1):

And look at the brightness difference (it's the Normandy Campaign first mission intro sequence)

Up for this (and Steam Aquanox not working 😁 )

lowenz wrote:

Some problems with dgVoodoo and original renderer of UT and Unreal Gold (DirectDraw / D3D7? ), from Unreal Anthology (2006) + un […]
Show full quote

Some problems with dgVoodoo and original renderer of UT and Unreal Gold (DirectDraw / D3D7? ), from Unreal Anthology (2006) + unofficial patch ( http://ego-creations.de/scripts/download.php?DownID=26 )

Unreal:

Post Scriptum: The "GeForce 4800" preset can run the game flyby (the infamous Nali Castle 😁 ) but it crashes loading a new map. With the other presets there's simply a crash at start.

Finally decided to make an account...

I've been for a while trying to figure how to make SimCity 4 run decently on modern machines (not just mine, it would be great if I could help other people too!)

I gave dgVoodoo 2 a try, and it ALMOST works.

The almost part is for two reasons:

1) The more advanced fake 3D card is great to fix the nVidia Optimus bug (nVidia Optimus drivers have a bug where they report the wrong card to DDraw, one of the reasons SC4 break on modern laptops). But, it also passes completely crazy info (like device id 0, device name 0, and so on).

If you could configure this (ie: the values that the fake device pass, at least the device id and whatnot), it already would help a lot... I know the game can also emulate a nVidia and an ATI card, but those were not the most powerful cards the game could detect.

2) lots of Z fighting 🙁 although there are other graphical glithes (like completely black buildings, like if they weren't being rendered at all), the z fighting is too obvious, stuff flickers on and off existance, beaches crap out (as the game is unsure if the sand or the water renders on top) and you see in almost every road the cars rendering on top of the buildings, it is very surreal.

Fixing those 2 issues in particular would already help a lot I guess.

EDIT: Worth noting this occurs both with and without D3DCompiler_43.dll.

Tested the DirectX 7-based Radeon's Ark tech demo v1.3, which won't run on my GeForce GTX 970 normally since it sees the OS doesn't report it as an ATI card, with dgVoodoo2 2.5. It runs so long as the videocard is set to "ATI Radeon 8500"...but then all but certain, seemingly-unlit textures are black.

I also see the following errors in the demo's error log:

1; radiATIon Error Log
2; Created Mon Feb 01 20:47:31 2016
3
4Error finding starting portal for character "coral3"! Deleting object...
5Error finding starting portal for character "rock1"! Deleting object...
6Error finding starting portal for character "rock2"! Deleting object...
7Error: Couldn't set current viewport to device in d3dViewport
8; Exiting Mon Feb 01 20:47:47 2016
9