Reply 720 of 1111, by juyao
AMD Ryzen7 1700
RTX 470 8G
Win10 pro 1803
dgVoodooWIP44——dgVoodooWIP53
all games like this
nfs5
mm8
...
AMD Ryzen7 1700
RTX 470 8G
Win10 pro 1803
dgVoodooWIP44——dgVoodooWIP53
all games like this
nfs5
mm8
...
Guessing it's related to this:
2.55.x make a game looks white
Which seems to be a bug affecting newer versions of dgVoodoo on AMD systems. I was sort of curious if that was fixed in the latest WIPs.
Rise of Legends Realtime Strategy / 2006
Not shure which shader model the game has, but works with wip53 (Shadows look weird, turning them OFF solves the problem)
Sacred 2
Lots of rendering problems. Also sort of bad performance.
dgVoodoo debug version seems to have less problems but might be just my imagination.
I posted something but it's gone.
TMNT 2003:
https://i.imgur.com/RJFMpCi.png
Just like the demo version, the retail version has texture issues. The game world looks fine.
Total Overdose:
https://i.imgur.com/CYAJKEQ.png
https://i.imgur.com/mpogarD.png
The world is green.
Does anyone know how to get thirteenag's widescreen to fix with Total Overdose? I'm using the retail version but dragging and dropping things doesn't seem to work, the game refuses to boot.
Surfs Up Cartoon surfing game (Unreal X? Engine) working good with the DX9 wrapper, including force resolution. Tested on Win7/64
Dungeon Siege 1 is working with lates Build. BUT DONT USE MSAA this breaks the ingame light 😀
Alias: The Game
Works, but complains that it can't create VMR9 instance whenever it tries to play videos (native is fine) and requires some weird modes added to ExtraEnumeratedResolutions, playing at 1280x720 i had to check the log to find this:
ERROR: Direct3D9 (0BC2E7B8): Validation of D3D9 swapchain presentation parameters failed. Reason: display mode "1276x716, 60Hz" is required but not supported by output device: 0, DeviceType : D3DDEVTYPE_HAL
Like it somehow ended up trying to compensate for window borders while setting display mode. Adding that as a supported resolution and:
Tested F.E.A.R some more, graphic glitches was misconfiguration by me, but I thought I'd show you the performance I'm getting:
https://www.youtube.com/watch?v=0UuphvZ8dfc
The game shouldn't freeze when he breaks that door open.
Yeah, that seems to be more than a single 'lag'.
I've put a lot of effort into avoiding lagging/stuttering caused by shader compositing.
It's not perfect because not every case can be handled well, but games like FEAR, Lego Star Wars, etc. are now running pretty smooth. So, we'll see.
BTW, an other thing is tending to be needed for more and more games: float textures and rendertargets. I think I'm going to implement them.
Reporting The Void (2009) to run with WIP53
OK, I've made sure I'm using a stock config for F.E.A.R now and found a glitch.
Native:
dgVoodoo2:
Think it happens with all walls.
Works great in the race sim games I care most about GTR2 and GTL. Reflection are better sky and lights looks better only the rain fog is missing so kind of clear while raning.
Race 07 got issues due to a shadow Zbuffer but the shaders can be disables.
AMS (Automobilista) kind of works the sky is black. No textures rendered
Any chance to get 2048 and 4096Mb Vram?
Larger tracks slow down quite a lot.
wrote:Any chance to get 2048 and 4096Mb Vram?
Larger tracks slow down quite a lot.
You can type in whatever value you want.
wrote:wrote:Any chance to get 2048 and 4096Mb Vram?
Larger tracks slow down quite a lot.You can type in whatever value you want.
Thanks didn't know that.
Can't get it to accept higher than 2048Mb. Got 8192Mb
Not even sure it helped but have left it at 2048Mb anyway.
Armed Forces Corp City Interactive shooter , working with WIP53 ( Many City Interactive Game crash with a black screen, if you run into that follow this
It's always the FEAR engine.....
World of Goo (Humble Bundle version 1.30), a DX7/9 game, works flawlessly with WIP53, though it doesn't truly benefit from resolution scaling.
The game uses a mix of DX9 and DX7; running without the DX7 DLLs results in a fatal error, and running with just the DX7 DLLs prevents dgVoodoo2 from hooking.
EDIT: Forgot to mention the "FreeMouse" variable must be true in either the global or local dgVoodoo2 config file; otherwise, the mouse is locked to the pre-scaled resolution.
wrote:EDIT: Forgot to mention the "FreeMouse" variable must be true in either the global or local dgVoodoo2 config file; otherwise, the mouse is locked to the pre-scaled resolution.
Good catch! But why?
wrote:wrote:EDIT: Forgot to mention the "FreeMouse" variable must be true in either the global or local dgVoodoo2 config file; otherwise, the mouse is locked to the pre-scaled resolution.
Good catch! But why?
The FreeMouse variable has to be set somewhere. If the user hasn't setup a dgVoodoo2 config file in the game's directory, then the global dgVoodoo2 config file has to be edited. The latter is woefully inefficient (what if the user has more than one game dgVoodoo2 hooks?), but I thought I'd mention it for completeness.