Reply 3160 of 3949, by Dege
Isn't it a D3D9 game? Or I’m just messing 'Alien Shooter' with 'Alien Shooter Vengeance'?
Isn't it a D3D9 game? Or I’m just messing 'Alien Shooter' with 'Alien Shooter Vengeance'?
wrote:Isn't it a D3D9 game? Or I’m just messing 'Alien Shooter' with 'Alien Shooter Vengeance'?
Alien Shooter, Zombie Shooter, and Theseus: Return of the Hero and Zombie Shooter is D3D8. Every other one is D3D9 or 11.
wrote:The GOG version of Combat Mission: Beyond Overlord works pretty well with dgVoodoo2 with the exception of fog. Quite simply no fog is rendered - I don't know if fog table emulation is something that dgVoodoo can do?
Yes, I've found this too. It spoils an otherwise fantastic game. 🙁
I've tried OracleVM and using an emulated XP, but Direct3d graphics won't work for some reason with this game (Direct3d 7 problem). So, my last hope is here. 😉
The original post went unanswered. Will there ever be a fix for this 'no fog' problem please?
Thanks.
>dgVoodoo 2 wins!
vs same setup without?
Same setup, of course!
Delta Force: Black Hawk Down (DirectX8) test.
Some issues at very long distance is visible. Try to pause it at 0:04, it's the best visible. Left side is the original.
https://www.youtube.com/watch?v=n5nQLkSFkEk&feature=youtu.be
And if someone asks. I know, the game works fine on W10 too, but dgVoodoo for DX8 is great to add Reshade shaders+it might help on some games with sh1tty resolution support.
Been a while since I've used dgVoodoo 2 and was delighted to see the new-to-me integer scale factor options as a possible solution to what is so obviously missing from Nvidia and AMD's GPU drivers. However, the result is still a blurry mess when this option is used. I'm using ISF to scale a 640x480 game to 1280x960 on my display, and the text is just as blurry as if I were to allow my GPU to upscale to 1440x1080.
Is there any plan for simple nearest neighbor filtering? Nearest neighbor and integer scaling go hand in hand. This is the first time I've seen the latter implemented without the former as an option. My options for playing old DDraw/D3D games these days are: play 1:1, looking at a tiny portion of the middle of the screen, or play with blurry text, resulting in a migraine. There's actually a third option I usually have to choose: don't play at all. 😒
You can already select the filtering mode.
Delta Force 1:
https://www.youtube.com/watch?v=nsZwXQjAxHE&feature=youtu.be
Max resolution by default is 800x600. Tried max res forcing, then it rendered at 1440x1080 (my max resolution is 1920x1080). I think it definitely looks better, but i can't make screenshots/videos without using dgVoodoo. I didn't see any bugs.
wrote:Same setup, of course!
Why is dgvoodoo faster than bare metal?
'cause there's no "bare" metal, there's a really old d3d8 driver by Nvidia.
wrote:You can already select the filtering mode.
You can set texture filtering. Not scaling algorithm. The scaling seems to be the usual bilinear.
Edit: Here is an article in case anyone doesn't understand the benefit of having not only integer scaling but nearest neighbor as a (resolution) scaling option. This being VOGONS I think the vast majority of you already get it.
Edit2: Ok, I'm confused. Might and Magic 6-8 use the same engine, though each game has a more advanced version. The first is software-only, the second two both offer software or hardware accelerated renderers. 6 looks perfect with ISF enabled. The other two are blurry, even in software mode. Not sure what is going on here. 😒 Obviously nearest neighbor is indeed possible here as MM6 looks great, but why am I unable to get the same in 7 and 8? I think I recall MM6 being DX5, MM7 DX6, and MM8 DX6 or 7. Is that relevant?
wrote:'cause there's no "bare" metal, there's a really old d3d8 driver by Nvidia.
OK, so it's the d3d8 driver vs d3d11+dgvoodoo wrapper.
wrote:wrote:'cause there's no "bare" metal, there's a really old d3d8 driver by Nvidia.
OK, so it's the d3d8 driver vs d3d11+dgvoodoo wrapper.
I guess it all is due to well optimized multithreaded D3D11-drivers.
wrote:You can set texture filtering. Not scaling algorithm. The scaling seems to be the usual bilinear. […]
wrote:You can already select the filtering mode.
You can set texture filtering. Not scaling algorithm. The scaling seems to be the usual bilinear.
Edit: Here is an article in case anyone doesn't understand the benefit of having not only integer scaling but nearest neighbor as a (resolution) scaling option. This being VOGONS I think the vast majority of you already get it.
Edit2: Ok, I'm confused. Might and Magic 6-8 use the same engine, though each game has a more advanced version. The first is software-only, the second two both offer software or hardware accelerated renderers. 6 looks perfect with ISF enabled. The other two are blurry, even in software mode. Not sure what is going on here. 😒 Obviously nearest neighbor is indeed possible here as MM6 looks great, but why am I unable to get the same in 7 and 8? I think I recall MM6 being DX5, MM7 DX6, and MM8 DX6 or 7. Is that relevant?
Yes, dgVoodoo's texture filtering modes affects only the rendered 3D polygons but not the scaling (postprocessing) of the final 2D image.
The problem with this 2D scaling thing is that it's not under control of dgVoodoo. At least, not in all cases. If one of 'unspecified', 'stretched' or 'centered' scaling mode is selected then dgVoodoo itself doesn't do any 2D resizing, it just outputs the image and it's up to the driver/display output how it handles the scaling (what is more, it's true for windowed mode too!). In most cases blurry linear scaling is applied and that's the behavior what is imitated by dgVoodoo when it does its own scaling in 'stretch, keep AR' scaling modes.
dgVoodoo now has support for text based config files and I created an option for 2D postprocess filtering, but it only affects the latter 'Stretch, keep AR' scaling modes.
wrote:Delta Force: Black Hawk Down (DirectX8) test. Some issues at very long distance is visible. Try to pause it at 0:04, it's the be […]
Delta Force: Black Hawk Down (DirectX8) test.
Some issues at very long distance is visible. Try to pause it at 0:04, it's the best visible. Left side is the original.
https://www.youtube.com/watch?v=n5nQLkSFkEk&feature=youtu.beAnd if someone asks. I know, the game works fine on W10 too, but dgVoodoo for DX8 is great to add Reshade shaders+it might help on some games with sh1tty resolution support.
Thx. BTW, what's the difference? The missing green strip with dgVoodoo?
wrote:Yes, I've found this too. It spoils an otherwise fantastic game. :( […]
wrote:The GOG version of Combat Mission: Beyond Overlord works pretty well with dgVoodoo2 with the exception of fog. Quite simply no fog is rendered - I don't know if fog table emulation is something that dgVoodoo can do?
Yes, I've found this too. It spoils an otherwise fantastic game. 🙁
I've tried OracleVM and using an emulated XP, but Direct3d graphics won't work for some reason with this game (Direct3d 7 problem). So, my last hope is here. 😉
The original post went unanswered. Will there ever be a fix for this 'no fog' problem please?
Thanks.
I had a look at this game but it didn't render fog even natively. Ok, this can be because of broken D3D support but when I looked at youtube videos, I didn't see fog there too.
wrote:Thx. BTW, what's the difference? The missing green strip with dgVoodoo?
Lol. I didn't even notice that. I thought the green line supposed to be here, because i tested the multiplayer mode and thought it's part of the game mode. But i checked again and it's really a bug too.
EDIT: So it's not missing with dgVoodoo. It actually shouldn't be visible. I fuked up the video, because at the first part dgVoodoo is in the right side then at another scene it's at the left side. 😢 😒
Now i checked a single player level and it's much more noticeable.
See that bugged blank part of the sky with dgvoodoo (also the green line bug is there too):
http://i.imgur.com/LP7JZNd.jpg
without dgvoodoo:
http://i.imgur.com/BWFOEHC.jpg
@Dege
RivaTuner used to have an option to enable 'Fog Table Emulation' (that was a Direct3D tweak) but apparently later drivers just dropped support for it altogether. This is the method used by the game.
I don't know whether this can be emulated for modern drivers? If so, it would be really cool.
It probably still exists but obviously isn't supported as newer algorithms use a different method of emulating fog - vertex fog I believe?
Because of the above, most YouTube vids you see will obviously not be displaying fog!
But, a scenario had to be created where fog was set to none, light or heavy, and there isn't a lot of those to be seen on YouTube anyway.
There's a file explaining fog in Direct3D here:
https://www.google.co.uk/url?sa=t&rct=j&q=&es … Ay02h3QzXG4bz5w
Turns out Alien Shooter 2 and Zombie Shooter 2 isn't D3D8. But yeah, Alien Shooter 1 and Zombie Shooter 1 crash when using a medkit with dgVoodoo 2, but Thesus - Return of The Hero doesn't (same engine).
wrote:Yes, dgVoodoo's texture filtering modes affects only the rendered 3D polygons but not the scaling (postprocessing) of the final 2D image.
The problem with this 2D scaling thing is that it's not under control of dgVoodoo. At least, not in all cases. If one of 'unspecified', 'stretched' or 'centered' scaling mode is selected then dgVoodoo itself doesn't do any 2D resizing, it just outputs the image and it's up to the driver/display output how it handles the scaling (what is more, it's true for windowed mode too!). In most cases blurry linear scaling is applied and that's the behavior what is imitated by dgVoodoo when it does its own scaling in 'stretch, keep AR' scaling modes.
Thanks for the explanation! Would you speculate as to why the image is scaled with nearest neighbor in the case of Might and Magic 6? Is it because the game only uses DDraw? MM7 and 8 offer hardware and software renderers and both upscale with bilinear, so it can't simply be a matter of accelerated vs non-accelerated. It must be DDraw vs DX6+, right?
dgVoodoo now has support for text based config files and I created an option for 2D postprocess filtering, but it only affects the latter 'Stretch, keep AR' scaling modes.
So any of dgVoodoo 2's filtering is applied only after the GPU driver has done its work (in most cases, pre-blurring the image). Is the 2D scaling simply handled too early in the process for you to ever pre-scale the image cleanly before the driver scales it? DxWnd and DXGL achieve nearest neighbor upscaling but perhaps it's only possible for DDraw games (like MM6 where dgVoodoo 2 also succeeds)?
I know your goal is simply to reproduce faithfully the experience of older games, but one aspect of that is a sharp image on a multisync CRT where each pixel can be made out 1:1. The best we can aim for on LCDs is a tiny 1:1 image in the middle, or a pixelated, perfectly clear integer ratio image taking up most of the screen with 2:1, 3:1, 4:1, etc. pixels on each axis. But if that isn't possible with a wrapper, then I guess continuing to beg Nvidia/AMD is the only solution...
Well, the whole process can be divided into 2 phases:
1. dgVoodoo always renders the frames into an intermediate buffer. Its size is determined by the logical resolution. Say, the game wants the resolution to be 1280x1024 (or it's forced to that) then frame rendering goes into the intermediate buffer with size of 1280x1024. This phase is totally independent on the display output. (But if the resolution/MSAA is forced then it can produce rendering glitches.)
2. dgVoodoo has to output the content of that buffer to the screen somehow.
- If scaling mode 'unspecified', 'centered' or 'stretched' is selected then dgVoodoo just tells the driver to switch into full screen mode and present the content of the intermediate buffer. It's up to the driver (or the display device itself) how the intermediate buffer is mapped onto the native resolution of the output but they usually choose simple bilinear filtered scaling, resulting in blurry appearance. ('Centered' is an exception because its purpose is to present the content with 1:1 mapping on the center of the screen.) That's what DX11 (DXGI) provides. Not too much...
- If scaling modes 'Stretched, *' are selected then dgVoodoo does its own scaling. First it determines the native resolution of the output (in fact, it assumes that desktop resolution for the output in question is the same as its native resolution), and works with an output buffer with that size (similar to fake fullscreen).
In this way it's ensured that dgVoodoo's output is mapped by 1:1 to the screen and so the driver/display scaling process is omitted.
Once dgVoodoo has the output buffer then mapping the intermediate to the output one is in its hands. If the intermediate buffer fits into the output buffer and scaling is not needed (e.g. when the application resolution is the same as the native resolution) then no filtering takes place, you get 1:1 pixel mapping. Bilinear filtering is used otherwise to get conformable behavior with the display/driver method (nearest-point can also be applied but pixel mapping won't be 1:1 because of the scaling).
The main drawback of this method is the fact that it can interfere with mouse input because the game window doesn't have the size the game is prepared for, it's much larger.
So, if you want sharp output appearance then your best choose is selecting 'centered' scaling mode. Additionally, you can force the game resolution to 'Max ISF' to make the output image as large as possible.
For some sad reason 'Centered' doesn't work for me on nVidia and AMD. I always get some stretched garbage. Works perfectly on Intel though. DXGI scaling modes seem to be totally unreliable for me.
That's why I've just added a new 'Centered, keep AR' to dgVoodoo. Max ISF + Centered AR seem to work very well.
wrote:Thanks for the explanation! Would you speculate as to why the image is scaled with nearest neighbor in the case of Might and Magic V? Is it because the game only uses DDraw? MM7 and 8 offer hardware and software renderers and both upscale with bilinear, so it can't simply be a matter of accelerated vs non-accelerated. It must be DDraw vs DX6+, right?
I don't know, isn't the game itself designed to render with nearest point? What if you force the texture filtering to bilinear, or enable 'Bilinear blit stretch'?