dgVoodoo 2 for DirectX 11

General information and assistance with dgVoodoo.

Re: dgVoodoo 2 for DirectX 11

Postby willow » 2017-11-13 @ 18:36

ZellSF wrote:dgVoodoo2 has some minor rendering problems with Lands of Lore II unfortunately. You can also play it with DXGL, but that has different rendering problems and DXGL doesn't allow forcing rendering resolution yet.

What are the minor rendering problems?
willow
Newbie
 
Posts: 83
Joined: 2012-1-07 @ 22:37

Re: dgVoodoo 2 for DirectX 11

Postby ZellSF » 2017-11-13 @ 19:57

willow wrote:
ZellSF wrote:dgVoodoo2 has some minor rendering problems with Lands of Lore II unfortunately. You can also play it with DXGL, but that has different rendering problems and DXGL doesn't allow forcing rendering resolution yet.

What are the minor rendering problems?

viewtopic.php?f=59&t=34931&p=444141#p444141
ZellSF
Oldbie
 
Posts: 935
Joined: 2006-1-01 @ 18:19

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-11-14 @ 13:14

CoolGamer wrote:Dege, I have a simple request regarding pixel perfect integer scaling. Can you add a scaling mode that upscales the image using an ISF factor that is beyond the maximum display resolution and then downscales to the maximum screen resolution by bilinear interpolation while preserving aspect ratio? You can call it "MAX ISF with downscaling" or something. This will be similar to the "near pixel perfect" method of the Dosbox ECE build.

Since my laptop's maximum resolution is 1366x768, I am not even able to use 2x ISF in most of the games. If a game has 640x480 resolution, 2x ISF gives 1280x960 which is larger than the maximum 4:3 resolution of 1024x768 that my display supports. With this "Max ISF with downscaling" mode, dgVoodoo will first upscale the 640x480 game to 1280x960 using ISF (or it will force the resolution if the game engine supports it), and then downscale it to 1024x768 using bilinear interpolation. You can use another downscaling interpolation method, if you believe that it will give better results.

You can already try that. If a wrapper-scaled scaling mode is in usage ('Stretched, * ascpect ratio) then dgVoodoo always scales up or down the output image to screen size. So, if you set ImageScaleFactor to 2, you'll have an output image larger than the screen but it'll downscaled to fit into 1366x768.
But, this all (probably) won't work with 'unspecified', 'sctretched' and 'centered' modes because the scaling is up to the driver (or DXGI) for them and I think the behavior is unspecified.
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby CoolGamer » 2017-11-15 @ 00:24

Dege wrote:You can already try that. If a wrapper-scaled scaling mode is in usage ('Stretched, * ascpect ratio) then dgVoodoo always scales up or down the output image to screen size. So, if you set ImageScaleFactor to 2, you'll have an output image larger than the screen but it'll downscaled to fit into 1366x768.
But, this all (probably) won't work with 'unspecified', 'sctretched' and 'centered' modes because the scaling is up to the driver (or DXGI) for them and I think the behavior is unspecified.


I tried that with Star Wars Racer and here are the results:
1) 2x/3x/4x ISF + "Stretched, keep aspect ratio" or "Stretched, 4:3 aspect ratio" = I loose the aspect ratio. Game fills the whole screen. Graphics look very sharp and dgVoodoo logo gets smaller as I increase the scaling factor. So I know that downscaling happens. The issue is that aspect ratio gets lost. :(

2) 1280x960 / 2560x1920 + "Stretched, keep aspect ratio" or "Stretched, 4:3 aspect ratio" = I loose the aspect ratio. Game fills the whole screen. Same as case 1 above. Graphics look very sharp and dgVoodoo logo gets smaller as I increase the manual resolution. So I know that downscaling happens. The issue is that aspect ratio gets lost. :(

3) MAX + "Stretched, keep aspect ratio" or "Stretched, 4:3 aspect ratio" = This one does keep the aspect ratio. It looks sharp so I know that the engine renders at 1024x768. I am guessing that no scaling is done by the wrapper.

4) Unforced + "Stretched, keep aspect ratio" or "Stretched, 4:3 aspect ratio" = This one does keep the aspect ratio. Wrapper upscales the original 640x480 to 1024x768. Not as sharp looking as MAX resolution option as expected.

5) MAX FHD/QHD ISF + "Stretched, keep aspect ratio" or "Stretched, 4:3 aspect ratio" = This one does keep the aspect ratio but it looks the same as the above (Unforced with Streched AR). I suspect that it does not do any downscaling. I think the wrapper just upscales the original 640x480 to 1024x768. If there was any downscaling MAX QHD ISF should have looked as sharp as test cases 1 and 2, but it is not even close.

Is it possible to fix cases 1 and 2, so that aspect ratio stays the same? Downscaling really looks very good in cases 1 and 2, but aspect ratio gets lost.
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-11-20 @ 12:53

OK, I fixed case 1) and 2). There was a logic in dgVoodoo for cases when larger image output is requested than the display supports: request was passed to the driver unchanged to bypass dgVoodoo's internal scaling (and the driver seems to do the scaling but with simple stretching).
I can't remember why I did that but now I removed.
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby mnii » 2017-11-20 @ 13:37

Hi, I'm first visit here.:) First of all thank you for the great works for old d3d and glide games.

The reason I'd written here is I'd like to know how to work well Mig Alley by Rowan sofware company. I tried it with dgvoodoo2 when dgvoodoo2 came to support dx7 games. However the game screen is not that good for playing due to the below game screen I attached. The version of Mig Alley is 1.23 or BDG patch 0.85f or 0.85f2, it seems to happen regardless of any version, and occured in all both modes which are d3d and software mode.

The loading screen(big black rectangle on the below pic) is supposed to be disappeared when getting into 3d world, but still there and blocks the playing screen. I guess it is well known issue before.

I'm using win8.1 laptop(intel hd5500 & nvidia840m optimus).

I just hope this issue could be fixed. Thank you. :happy:
Attachments
MA_error1.jpg
Last edited by mnii on 2017-11-21 @ 04:35, edited 2 times in total.
mnii
Newbie
 
Posts: 1
Joined: 2017-11-20 @ 13:11

Re: dgVoodoo 2 for DirectX 11

Postby Glurak » 2017-11-21 @ 03:30

i Tested the DDRAW wrapper today with Dune 2000 and man and workd like a charm even the Resolution Forcing DGVoodoo is such a wonderfull tool.

I did a test with Emporer Battle for Dune aswell and here we have some UI Black skin errors but only on 2 buttons. And the Resolution Force works GREAT.
Glurak
Newbie
 
Posts: 18
Joined: 2015-1-06 @ 15:51

Re: dgVoodoo 2 for DirectX 11

Postby Glurak » 2017-11-23 @ 13:40

Hi i tryed today Divine Divinity and it has very strange colors. I tryed it with the D3D Wrapper because on newer systems it has extrem performance issues
Glurak
Newbie
 
Posts: 18
Joined: 2015-1-06 @ 15:51

Re: dgVoodoo 2 for DirectX 11

Postby masterotaku » 2017-11-24 @ 21:31

I have some questions, related to the 3D Vision fixes I've been doing (using 3Dmigoto, the DX11 shader modification tool):

1- 3Dmigoto includes a "d3dcompiler_46.dll", and I'm not using any d3dcompiler files from the dgVoodoo website. Still, DX8 games work perfectly. I assume dgVoodoo is using that file, right? bo3b (one of the main 3Dmigoto developers) wanted me to ask if there is a way to specify the compiler and force it. Like, if "d3dcompiler_46.dll" is present in the game folder, does dgVoodoo forcefuly use that one, or the Windows 10 "d3dcompiler_47.dll"?

2- Related to the previous question, bo3b (using Windows 7) is having issues to use my 3D Vision fixes (made in Windows 10). For example, Hitman: Codename 47: http://helixmod.blogspot.com.es/2017/11/hitman-codename-47.html
The shader overrides of the fix where I apply different code in a vertex shader depending on the affected pixel shader aren't working for him. He is getting different pixel shader hashes, but vertex shaders are the same for both of us. Can compiled shaders be different depending on the Windows version? Or is it a per person or per drivers thing? He also gets two "Direct3D 11 MS (feature level 10.1)" instead of "Direct3D 11 MS (feature level 10.0)" and "Direct3D 11 MS (feature level 10.1)". He will try my fixes on Windows 10 later today. I hope they will work. If not, part of my work would be only useful for myself.

Edit: 3- What is the chance of shaders changing with different dgVoodoo versions? When I went from WIP 36 to WIP 37, from all my fixed games only one of the pixel shaders I was using in Legacy of Kain: Soul Reaver changed. Of course, I don't know if shaders I don't uses changed or not.

Late edit: 4- Why do games have a tendency to crash at boot if the chosen ingame resolution is high, like 2560x1440? Thankfully I can use dgVoodoo's forced resolution on top of the ingame lower resolution (ingame resolution usually works up to 1920x1200 or 1920x1440).

Late edit: 5- Is there anything I can do about cutscenes not playing in some games? The Trails in the Sky games don't play the videos (nor their audio). It's just a skippable black screen. I think they use the xvid codec.

Also, dgVoodoo is making my life happier and easier, about being able to play classic games in stereoscopic 3D :). Thanks a lot for this great tool.
User avatar
masterotaku
Newbie
 
Posts: 7
Joined: 2017-8-31 @ 18:55

Re: dgVoodoo 2 for DirectX 11

Postby DerTodIstEinDandy » 2017-11-25 @ 21:44

Hello, thanks for all the work on this project!

Is there any chance of the issue with lava/poison in dx mode in Blade of Darkness will be resolved, if I may ask? Other than this bug, dx dgVoodoo wrapper seems to work perfectly fine in this game, with good framerate even in areas with multiple light sources. On GTX 750Ti I never have below 40 fps in 1024x768, which is up to 10 fps better comparing to 3dfx wrapper. The game also seems to be more stable in dx mode, and the colors on the help screen aren't inverted.
DerTodIstEinDandy
Newbie
 
Posts: 4
Joined: 2017-5-09 @ 20:50

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-11-27 @ 11:02

DerTodIstEinDandy wrote:Hello, thanks for all the work on this project!

Is there any chance of the issue with lava/poison in dx mode in Blade of Darkness will be resolved, if I may ask? Other than this bug, dx dgVoodoo wrapper seems to work perfectly fine in this game, with good framerate even in areas with multiple light sources. On GTX 750Ti I never have below 40 fps in 1024x768, which is up to 10 fps better comparing to 3dfx wrapper. The game also seems to be more stable in dx mode, and the colors on the help screen aren't inverted.

Yes, I've already fixed that + half-blank background pictures with the Glide renderer too, will be included in the next WIP.
BTW, this game is locking the backbuffer during rendering here and there (I don't know why), so I got better frame rates with fast vidmem access enabled.

masterotaku wrote:1- 3Dmigoto includes a "d3dcompiler_46.dll", and I'm not using any d3dcompiler files from the dgVoodoo website. Still, DX8 games work perfectly. I assume dgVoodoo is using that file, right? bo3b (one of the main 3Dmigoto developers) wanted me to ask if there is a way to specify the compiler and force it. Like, if "d3dcompiler_46.dll" is present in the game folder, does dgVoodoo forcefuly use that one, or the Windows 10 "d3dcompiler_47.dll"?

No, dgVoodoo can only use _43 or _47. It checks for _47 first and if it's not found then it looks for _43. If none of them is found then it falls back to precompiled shaders which implies poorer performance and that there is no support for DX8 vertex and pixel shaders, along with DX8-level fixed function pixel pipeline (for example, ternal operations like D3DTOP_LERP and temporary register).
The reason for _43 is that was the first one I used in dgVoodoo and recommended for users.
But later I discovered that _47 is included in Win10 by default. And now I prefer that one since _47 is the first (AFAIK) that supports SM5.1 (DX12 level). Ok, it's not needed for dgVoodoo currenty, but who knows...

masterotaku wrote:2- Related to the previous question, bo3b (using Windows 7) is having issues to use my 3D Vision fixes (made in Windows 10). For example, Hitman: Codename 47: http://helixmod.blogspot.com.es/2017/11 ... me-47.html
The shader overrides of the fix where I apply different code in a vertex shader depending on the affected pixel shader aren't working for him. He is getting different pixel shader hashes, but vertex shaders are the same for both of us. Can compiled shaders be different depending on the Windows version? Or is it a per person or per drivers thing? He also gets two "Direct3D 11 MS (feature level 10.1)" instead of "Direct3D 11 MS (feature level 10.0)" and "Direct3D 11 MS (feature level 10.1)". He will try my fixes on Windows 10 later today. I hope they will work. If not, part of my work would be only useful for myself.

Maybe I'm wrong but I think compiled shader binary depends only on the compiler version. The binary header itself contains some kind of a hash value (magic number :) ) though that is generated by the compiler somehow.
Isn't dgVoodoo working with precompiled pixel shaders for bo3b while with dynamically compiled ones for you? Vertex shaders are the same for both of you by a good chance because D3D fixed function vertex pipeline is usually just mapped to a precompiled one. This gave me an idea, I'm going to add info entries about that into the debug layer.
Two 10.1's in the CPL is weird though... I should look at that.

masterotaku wrote:Edit: 3- What is the chance of shaders changing with different dgVoodoo versions? When I went from WIP 36 to WIP 37, from all my fixed games only one of the pixel shaders I was using in Legacy of Kain: Soul Reaver changed. Of course, I don't know if shaders I don't uses changed or not.

They are rarely modified, but occassionally they are. By now, I mostly modify them because of bug fixing. Like recently, I found a bug in fog calculations so it'll change a little in the next WIP.
But unfortunately there are a lot of shaders in dgVoodoo: precompiled vertex, precompiled pixel, precompiled postprocess, runtime compiled vertex and pixel ones... :(

masterotaku wrote:Late edit: 4- Why do games have a tendency to crash at boot if the chosen ingame resolution is high, like 2560x1440? Thankfully I can use dgVoodoo's forced resolution on top of the ingame lower resolution (ingame resolution usually works up to 1920x1200 or 1920x1440).

Check out the virtual VRAM size set for DirectX rendering. Higher resolution eats up more VRAM and 64MB or 128MB can be too low for high resolutions, as opposed to low-res the games were coded for. :)
(The debug layer in the spec release gives an error for those situations.)

masterotaku wrote:Late edit: 5- Is there anything I can do about cutscenes not playing in some games? The Trails in the Sky games don't play the videos (nor their audio). It's just a skippable black screen. I think they use the xvid codec.

If the video player renders through GDI instead of DDraw then all you got a blank screen. It's a problem that needs to be resolved. On the other hand, no audio seems to be another problem. Does it work natively?

BTW, I think I should try your 3D mods, seem to be too cool! :cool:
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby CoolGamer » 2017-11-27 @ 14:48

Dege wrote:
masterotaku wrote:Late edit: 4- Why do games have a tendency to crash at boot if the chosen ingame resolution is high, like 2560x1440? Thankfully I can use dgVoodoo's forced resolution on top of the ingame lower resolution (ingame resolution usually works up to 1920x1200 or 1920x1440).

Check out the virtual VRAM size set for DirectX rendering. Higher resolution eats up more VRAM and 64MB or 128MB can be too low for high resolutions, as opposed to low-res the games were coded for. :)
(The debug layer in the spec release gives an error for those situations.)



I also experienced something similar to what Masterotaku reported. I think most people did not notice it because it is very difficult to replicate this error. Most of the games hide natively unsupported resolutions in their internal settings. And most of the new GPUs support almost all resolutions natively. I noticed this error in ScummVM and Star Wars Episode 1 Racer.

In short, the situation is the following:

1) If a game's internal resolution setting is set at a value which does not allow it to run/start on my system natively, I am unable to run it via dgVoodoo no matter which resolution/scaling settings I choose through dgVoodoo control panel. dgVoodoo does not help it to start/run.

2) If a game's internal resolution setting is set at a value which runs/starts on my system natively, it is possible to run it via dgVoodoo and modify resolution/scaling through dgVoodoo. In this case it is possible to force all resolutions and aspect ratios through dgVoodoo, even the ones unsupported natively.



The Details are the following:

My laptop's maximum supported resolution is 1366x768. When I set in game resolution to 1366x768 (or lower values supported by my GPU) through the game's internal settings, and force unsupported resolutions such as 2560×1440 through dgVoodoo control panel, the game works. The game renders at 2560x1440 and dgVoodoo downscales the image to 1366x768.

When I set the resolution to 2560×1440 (or any other value unsupported by my display) through the game's internal settings, the game crashes at boot. I would expect dgVoodoo to help the game to run and just scale the image, but it doesn't. Is it possible to fix this?

You can test this using Star Wars Episode 1 Racer and the custom resolution launcher included in the third party installer linked below. Just install the game using the third party installer and run the custom launcher (SWEP1RC_Res_Fix_CD.exe). Set the resolution to values which are not natively supported by your display and run the game.
https://www.letsplayforum.de/index.php/ ... d-Patches/

For example I get crashes with the following resolutions: 640x360, 800x450, 1152x648, 1600x900, 1920x1080, 2560x1440, etc. These are resolutions which are not listed on my GPU panel's screen resolution list. It is natural for them not to work natively, but it would be awesome if they worked through dgVoodoo. Playing with dgVoodoo's resolution and scaling settings do not make a difference when I set the resolution to these "natively unsupported values" through the game launcher. I still get the crash at boot.

When I set the resolution to a value supported by my display (such as 640x480, 800x600, 1024x768, 1280x720, 1366x768) through the launcher (SWEP1RC_Res_Fix_CD.exe) and set higher or lower resolution through dgVoodoo's control panel (such as 800x450 or 2560x1440), the game works. The game runs at the resolution set through dgVoodoo control panel in this case.

I attached two log files that I created for Star Wars Racer using the debug build:
1) In the crash case, I set the game's internal resolution to 1920x1080 through the launcher and set dgVoodoo's forced resolution to 1920x1080.

2) In the no crash case, I set the game's internal resolution to 1280x720 through the launcher and set dgVoodoo's forced resolution to 1920x1080.

Line number 85 is interesting in the crash case. It says "SetDisplayMode: Display mode 512x384, 8 bit, 60 Hz is set", eventhough 512x384 was not specified anywhere. (By the way, 512x384 resolution works, when I set the game's internal resolution to 512x384.)
Attachments
NoCrash_GameInternalRes1280x720_dgVoodooForcedRes1920x1080.LOG
Star Wars Racer, NO Crash Case with 1280x720 internal game resolution
(839.61 KiB) Downloaded 5 times
Crash_GameInternalRes1920x1080_dgVoodooForcedRes1920x1080.LOG
Star Wars Racer, Crash Case with 1920x1080 internal game resolution
(660.81 KiB) Downloaded 3 times
Last edited by CoolGamer on 2017-11-27 @ 20:14, edited 1 time in total.
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: dgVoodoo 2 for DirectX 11

Postby DerTodIstEinDandy » 2017-11-27 @ 16:35

Dege wrote:Yes, I've already fixed that + half-blank background pictures with the Glide renderer too, will be included in the next WIP.
BTW, this game is locking the backbuffer during rendering here and there (I don't know why), so I got better frame rates with fast vidmem access enabled.


Thanks! Yes, I should have mentioned I was using fast memory access too, since it doesn't seem to cause any negative effects and gives a large fps boost.
DerTodIstEinDandy
Newbie
 
Posts: 4
Joined: 2017-5-09 @ 20:50

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-11-28 @ 19:38

CoolGamer wrote:I also experienced something similar to what Masterotaku reported. I think most people did not notice it because it is very difficult to replicate this error. Most of the games hide natively unsupported resolutions in their internal settings. And most of the new GPUs support almost all resolutions natively. I noticed this error in ScummVM and Star Wars Episode 1 Racer.


Yes, but that's not so simple... There are 2 things that should be distincted:
- The GPU can render at any resolution (into an offscreen buffer with any size), it's true
- But the display output, that displays the image, doesn't support arbitrary resolutions with arbitrary refresh rates

That's why all of the DirectX versions enumerates the display-supported resolutions to the applications, from which the app can pick up one and set the display mode to that.
What changed from DX10 (DXGI) is that the enumeration mechanism still exists but DXGI allows the app to set arbirtray resolution with arbitrary refresh rate for a given display output.
BUT, display modes unsupported by the display output are virtual and not optimal, kind of emulated. DXGI does some extra work for them in the background.
(BTW, Soldier of Light, the guy who I discussed the FCU DXGI problem with, published an interesting detailed description on how DXGI resolves those non-optimal cases but I cannot find it now.)

So, as dgVoodoo follows the behavior of old DirectX, it doesn't allow an app to set an arbitrary display mode, just the ones that are supported.
(The output of the debug layer should contain an error entry for such an attempt.)
Supported ones are the ones reported from your display output and the "artificial" classic ones (320x200, 320x240, 512x384, 640x480, ...) and the extra ones that can be specified in the config file.

The NoCrash log contains
Code: Select all
00000059   1.39710152   [10660] [dgVoodoo] INFO: DirectDraw (04492EF8)::SetDisplayMode: Display mode 1280x720, 16 bit, 59 Hz is set, but app rendering resolution is forced to 1920x1080

The Crash log contains
Code: Select all
00000085   29.91650391   [11616] [dgVoodoo] INFO: DirectDraw (0431AD58)::SetDisplayMode: Display mode 512x384, 8 bit, 60 Hz is set, but app rendering resolution is forced to 1920x1080   


So I cannot see problem there. But, if you try 2560x1440 as an ingame resolution, you should see something like this
Code: Select all
::SetDisplayMode: Setting display mode has failed. Reason: display mode "2560x1440, 16 bit, x Hz" is required but not supported by the output device.
Dege
Oldbie
 
Posts: 1000
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby galneon » 2017-11-29 @ 18:44

Dege,

I was just posting some wrapper information as an alternative in this thread requesting integer scaling for Nvidia GPU drivers and had to complicate my guide for dgVoodoo 2 a bit by detailing the binary vs text dgVoodoo.conf overwrite problem when using a game-local dgVoodoo.conf binary saved via the Control Panel. I know you're probably aware of this issue (some of us discussed it here shortly after the advent of the text dgVoodoo.conf), but I just wanted to remind you of the conflict just in case.

Edit: It looks like me and another user overlooked something when troubleshooting the conf overwrite issue here a few months ago. I thought the text-based .conf deferred to the binary .conf for unspecified values, but the text-based .conf actually goes with default values when not specified (as specified in the readme). I think some confusion could be avoided by renaming the binary version that the CPL saves to dgvoodoo.bin to avoid the risk of overwrites (or renaming the text version to dgvoodoo.ini which would probably be easier), and having the text version defer to it is for unspecified values. Then we could have game-specific bare bones (only the options needed) text-based INIs for advanced options which complement one's regular global CPL settings.
Last edited by galneon on 2017-11-30 @ 00:06, edited 1 time in total.
galneon
Newbie
 
Posts: 53
Joined: 2004-4-15 @ 19:31

Re: dgVoodoo 2 for DirectX 11

Postby CoolGamer » 2017-11-29 @ 23:18

Dege wrote:
So I cannot see problem there. But, if you try 2560x1440 as an ingame resolution, you should see something like this
Code: Select all
::SetDisplayMode: Setting display mode has failed. Reason: display mode "2560x1440, 16 bit, x Hz" is required but not supported by the output device.


I do not get an error like that when I set the ingame resolution to 2560x1440. What happens is the following:

When I set Star Wars Racer's ingame resolution to 2560x1440 and set dgVoodoo config panel resolution to Unforced I get:
Code: Select all
DirectDraw (002BAB48)::SetDisplayMode: Display mode 512x384, 8 bit, 60 Hz is set.


When I set Star Wars Racer's ingame resolution to 2560x1440 and set dgVoodoo config panel resolution to 2560x1440 I get:
Code: Select all
DirectDraw (04428A90)::SetDisplayMode: Display mode 512x384, 8 bit, 60 Hz is set, but app rendering resolution is forced to 2560x1440


I am not specifying 512x384 anywhere (not in game, not in dgVoodoo control panel) but the crash logs contain 512x384. That's weird isn't it. It also does not say that setting the display mode has failed.

In both cases the game gets stuck at loading and crashes. I attached both of the full log files.


EDIT:
On a separate note, I think the original feature request of Masterotaku (which I fully supported) was the following: an option to allow the game to set any arbitrary resolution and just scale it according to the chosen scaling option of dgVoodoo. I just realized that this is possible by adding "ExtraEnumeratedResolutions = 2560x1440" to the ini configuration file. Then dgVoodoo allows Star Wars Racer to start when I set the in game resolution to 2560x1440 and just scales it according to the chosen scaling option of dgVoodoo. So thanks for that Dege :). We requested something that is already in dgVoodoo LOL. I also attached the Log for the "ExtraEnumeratedResolutions = 2560x1440" No Crash case.

The weird error messages above happen when ExtraEnumeratedResolutions is empty. You just have to check why dgVoodoo is saying "SetDisplayMode: Display mode 512x384, 8 bit, 60 Hz is set" instead of "SetDisplayMode: Setting display mode has failed. Reason: display mode "2560x1440, 16 bit, x Hz" is required but not supported by the output device.".
Attachments
NoCrash_GameInternalRes2560x1440_dgVoodooForcedRes2560x1440_ExtraEnumeratedResolutions2560x1440.LOG
(834.33 KiB) Downloaded 3 times
Crash_GameInternalRes2560x1440_dgVoodooForcedResUnforced.LOG
(670.19 KiB) Downloaded 3 times
Crash_GameInternalRes2560x1440_dgVoodooForcedRes2560x1440.LOG
(658.86 KiB) Downloaded 2 times
CoolGamer
Newbie
 
Posts: 92
Joined: 2017-1-14 @ 17:22

Re: dgVoodoo 2 for DirectX 11

Postby Waltc » 2017-12-02 @ 03:37

willow wrote:I think the last version of the game (1.30) have the same graphics in direct3d and in glide mode. I didn't see any difference.
The problem at home with nglide version is that after some minutes, the game is very jerky (i have tried in win7 or 10 with differents version of dosbox same thing) 30 fps to 12-13 fps.


If you don't see any difference it's because you aren't getting 3d acceleration from your Glide wrapper--in the Lol2 game options page, hardware acceleration will be ON and all of the other "video" options will be inaccessible and grayed out because they are for d3d software support only. There's an amazing amount of difference visually. D3d is software support only and it's very pixellated compared to the accelerated Glide version. I have the same DOS version you do, 1.30, and I used to play for hours with Glide acceleration on, as I mentioned, in earlier versions of Windows10x64. I only mentioned it in case someone had some success running it in the latest builds of Win10x64--I also used to run it accelerated under nGlide 1.05 with good results, too, but prefer DG Voodoo2. But with this version of Win10x64, version 1709, build 17025, nGlide simply won't work, either. It returns errors--and just like DG Voodoo 2--after just a few minutes in accelerated mode the game crashes, hard. This never happened before with either wrapper, same version of DOSbox (I use SVN-Daum) so I think it has to be something they've done in Win10x64 D3d support in the Fall Preview 1709, and my beta version of 1709, build 17025, which is a couple of builds newer than the 16299.xx build.

The odd thing for me is that all of my D3d/OpenGL games run flawlessly under the same build--with older games than Lol2--so something's changed that doesn't affect my game compatibility--except with these wrappers...! Ah, well, such is life...;)
User avatar
Waltc
Newbie
 
Posts: 15
Joined: 2013-4-27 @ 19:00

Re: dgVoodoo 2 for DirectX 11

Postby willow » 2017-12-02 @ 10:39

Waltc wrote:
willow wrote:I think the last version of the game (1.30) have the same graphics in direct3d and in glide mode. I didn't see any difference.
The problem at home with nglide version is that after some minutes, the game is very jerky (i have tried in win7 or 10 with differents version of dosbox same thing) 30 fps to 12-13 fps.


If you don't see any difference it's because you aren't getting 3d acceleration from your Glide wrapper--in the Lol2 game options page, hardware acceleration will be ON and all of the other "video" options will be inaccessible and grayed out because they are for d3d software support only. There's an amazing amount of difference visually. D3d is software support only and it's very pixellated compared to the accelerated Glide version. I have the same DOS version you do, 1.30, and I used to play for hours with Glide acceleration on, as I mentioned, in earlier versions of Windows10x64. I only mentioned it in case someone had some success running it in the latest builds of Win10x64--I also used to run it accelerated under nGlide 1.05 with good results, too, but prefer DG Voodoo2. But with this version of Win10x64, version 1709, build 17025, nGlide simply won't work, either. It returns errors--and just like DG Voodoo 2--after just a few minutes in accelerated mode the game crashes, hard. This never happened before with either wrapper, same version of DOSbox (I use SVN-Daum) so I think it has to be something they've done in Win10x64 D3d support in the Fall Preview 1709, and my beta version of 1709, build 17025, which is a couple of builds newer than the 16299.xx build.

The odd thing for me is that all of my D3d/OpenGL games run flawlessly under the same build--with older games than Lol2--so something's changed that doesn't affect my game compatibility--except with these wrappers...! Ah, well, such is life...;)

I think it's you that have a problem with d3d and have only d3d software.
I have 3d acceleration with glide and whith direct3d (bilinear filtering is ony available with 3d acceleration). Graphics are similar and it's normal because with the last patch of LoL, it's the standard comportment.
willow
Newbie
 
Posts: 83
Joined: 2012-1-07 @ 22:37

Re: dgVoodoo 2 for DirectX 11

Postby Waltc » 2017-12-02 @ 22:50

Lol2-C-D3dSoftwareOptions.jpg
Lol2-B-GLIDE selection.jpg
LoL2-A-Options.jpg
DXdiag.jpg
willow wrote:I have 3d acceleration with glide and whith direct3d (bilinear filtering is ony available with 3d acceleration). Graphics are similar and it's normal because with the last patch of LoL, it's the standard comportment.


I'm not sure if you understand, quite yet, so I've included some screen shots. Main Menu shows you it is DOS 1.30--GOG version. Options Menu shows you what it looks like when GLIDE acceleration is not available--note that "Hardware acceleration" is grayed out. BiLinear filtering only shows up when Hardware acceleration is turned ON--in the absence of GLIDE acceleration, BiLinear is not available in my version of the game. THe "Video Controls" menu shows the full gamut of D3d options available--D3d software options, note. When Glide acceleration is enabled then all of these options are grayed out with the exception of bi-linear filtering which is then visible and selectable. Last is my D3d diag page to show you that D3d is enabled on my system. As I mentioned I also have D3d hardware accelerated games from that time which run accelerated fine.

Now, *if you and I have the same version* of the game then you are running the Glide emulation when the option for bilinear filtering shows up shows up. If we are not running the same version--somehow--then I'd like to know where to get a patch more recent than the 1.30 DOS version of the game....;)

Again, I'm of the opinion that this is caused by something Microsoft has done in these latest builds that is somehow interfering with both DG Voodoo2 and nGlide--because both wrappers functioned fine in earlier Win10x64 builds. If you'll read some of the earlier posts in the thread--this is what they are talking about. I was only hoping that someone could offer some advice. I can play the game all day long in D3d software mode--it just doesn't look near as nice as played hardware accelerated through the GLIDE wrapper.
User avatar
Waltc
Newbie
 
Posts: 15
Joined: 2013-4-27 @ 19:00

Re: dgVoodoo 2 for DirectX 11

Postby ZellSF » 2017-12-02 @ 22:56

Direct3D is Windows only. It is not available in the DOS version of Lands of Lore II at all.

It is available on the Windows version, which GoG does not provide, and it looks pretty much the same as the Glide renderer.
ZellSF
Oldbie
 
Posts: 935
Joined: 2006-1-01 @ 18:19

PreviousNext

Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 2 guests