Dege wrote:

Maybe patching the code to check against a rect deflated by 1-2 pixels could solve the problem.

Brilliant suggestion! Patch updated.

Dege wrote:

KainXVIII wrote:

Well, i always used 480p ingame setting for Severance, but game still not feels smooth enough (despite 60 fps counter), NGlide wrapper is a little more smoother for some reason (but colors are washed out)

Doesn't fast vidmem access for Glide ('Force emulating true PCI access' on the CPL) help there too?

I did not tried glide wrapper in dgvoodoo (yet)

UCyborg wrote:

Dege wrote:

Maybe patching the code to check against a rect deflated by 1-2 pixels could solve the problem.

Brilliant suggestion! Patch updated.

Great!!!
Meanwhile I realized what the problem was: not another ReadFile but the 'poking code'.
It triggers the handler only for the first 4K page of a texture because it was enough for the cursor bitmap.
But not for other textures larger than 4K. So, I did a dirty patch again (from your latest patch) to touch the first byte of each scanline of textures, to make sure all pages get triggered. I didn't want to simply zeromem the area or jump by 4K's instead of scanlines when addressing because of the stride-thing. Also, I saw you moved the code to right after locking a surface so I changed the touching code from overwriting to OR'ing by 0 because surface locking can get called not only for ReadFile but reading and copying texture data and it shouldn't be modified in those cases.

http://dege.fw.hu/temp/Drakan_texture_fastvidmem.zip

KainXVIII wrote:

Dege wrote:

KainXVIII wrote:

Well, i always used 480p ingame setting for Severance, but game still not feels smooth enough (despite 60 fps counter), NGlide wrapper is a little more smoother for some reason (but colors are washed out)

Doesn't fast vidmem access for Glide ('Force emulating true PCI access' on the CPL) help there too?

I did not tried glide wrapper in dgvoodoo (yet)

Ah, ok. I thought you used the Glide renderer when compared to nglide.

Dege wrote:

Also, I saw you moved the code to right after locking a surface

Yes, just shortened the surrounding code so there's no need to CALL / JMP somewhere else. Even with your yesterday's modifications, I managed to squeeze everything in there. 😁

BTW, when you modified the lens flare function in Dragon.rfl, you overlooked the conditional jump a little above your CALL, which then pointed to some middle byte of the CALL instruction. I've corrected it, so all should be good now.

Found a compatibility regression as of 2.55:

Kohan: Immortal Sovereigns and Kohan: Ahriman's Gift, games using the same engine which requires 16-bit color mode, both work very well with 2.54. Occasionally right click sticks in-game. The other issue is that when you launch either, the fullscreen window is immediately minimized, so you must get back to it by alt-tabbing or clicking on the taskbar. Neither of these problems happen with WineD3D.

2.55 does not have the latter problem either--however, mouse clicks are virtually ineffectual. The buttons on the main menu detect hovering, and clicking repeatedly on them will occasionally yield a sound effect and, eventually (20+ clicks) even registers as a proper push. I did try the obvious thing of alt-tabbing out and then back in--no luck. I was able to get KAG to crash once while trying to get menu buttons to register. The error message was something pertaining to the back buffer. I've tried to get it to crash again so I could take a screenshot of the error, but no luck after 15 minutes of trying.

UCyborg wrote:

Dege wrote:

Also, I saw you moved the code to right after locking a surface

Yes, just shortened the surrounding code so there's no need to CALL / JMP somewhere else. Even with your yesterday's modifications, I managed to squeeze everything in there. 😁

BTW, when you modified the lens flare function in Dragon.rfl, you overlooked the conditional jump a little above your CALL, which then pointed to some middle byte of the CALL instruction. I've corrected it, so all should be good now.

Yes, I always did quick and dirty CALL-like patchings. Shortened code is nice, I like that.
So, I guess Drakan's rendering is placed in order now. 😀

BTW, I always forgot to ask: why do I get no sound with this game? I have music but no sound, no matter if I disable/enable EAX and such.

Tip: there's Unreal Gold free on Steam/GoG so there's no excuse now for no testing dgVoodoo2 wrapper with it 😁

Dege wrote:

BTW, I always forgot to ask: why do I get no sound with this game? I have music but no sound, no matter if I disable/enable EAX and such.

That's a good question actually. Is there anything special about your sound setup? Custom drivers for sound card, software that may be loading their DLLs into game or anything similar? You could try IndirectSound to see if it makes a difference, though generally it isn't strictly required since the engine doesn't mind if it doesn't detect hardware acceleration and will do 3D mixing if asked. Creative ALchemy would still be needed for EAX, but plain effect-less sound should normally still work without any sound wrapper. This problem has been asked about occasionally on Arokh's Lair forums, but never been answered and I've never got it myself neither.

Also, you should have the Editor folder with Level Editor.exe. Can you open any .lvl file with it, then select Window->Databases->Sounds and see if sounds play there by double-clicking them?

BTW, I wanted to ask this some time ago, but forgot...do you still have any issues with Mafia's Water Shader Mod and anisotropic filtering? I haven't seen anisotropic filtering impacting image quality in negative way with the mod, unless I'm missing some small detail?

Thanks!

UCyborg wrote:

BTW, I wanted to ask this some time ago, but forgot...do you still have any issues with Mafia's Water Shader Mod and anisotropic filtering? I haven't seen anisotropic filtering impacting image quality in negative way with the mod, unless I'm missing some small detail?

Interestingly I don't. 😕
How can that be? What changed?

Dege wrote:

Thanks!

Nice that it worked. Curious, though. I wonder if logging DirectSound calls would reveal why it doesn't work correctly out-of-the-box on some machines. I'd suggest API Monitor, but for DIrectSound, nothing beyond DirectSoundCreate was logged on my end.

Dege wrote:

Interestingly I don't. 😕
How can that be? What changed?

Besides the usual stuff; drivers, Windows build/patches; who knows. I recall one strange unrelated problem that doesn't make any sense, especially since the game in question just crashes in case of lack of write permissions over its folder. Computer quirks?

Dege wrote:

I cannot workaround this on nVidia, no matter what I do. Pixel shader(s) run erroneously. I disabled alpha testing in the game, that seems to be a good workaround. 😀
http://dege.fw.hu/temp/RoadWars_NoAlphatest.zip

That exe works just fine without the errors previously mentioned when using dgvoodoo2, but it is the version 1.0 exe which works differently. I was wondering if you would be willing to patch the version 1.1 exe so that it works the same without the 1.0 exe limitations?

Thanks 😀

Have you had a look at FF8 Dege?

So, Rayman 3: Hoodlum Havoc has an issue with NVIDIA cards on modern systems when hardware vertex processing is enabled where certain graphical effects (usually particle effects) are either missing or delayed (and when they are delayed, they are displayed tinted bright orange once they do show up). This doesn't occur with software vertex processing, nor does it occur when you edit the game to not use D3DUSAGE_DYNAMIC on that vertex buffer. It happens with just D3D8, with D3D8to9, with dgVoodoo and with WineD3D (which can sometimes crash shortly after the issue occurs). This can be tested within the first few seconds of gameplay, after collecting the three red orbs, particle effects will be missing on the last two. Any ideas on how this could be fixed and what could be causing it? If it helps, using dgVoodoo + DXVK makes the issue disappear.

V15UAL K3YS wrote:

Dege wrote:

I cannot workaround this on nVidia, no matter what I do. Pixel shader(s) run erroneously. I disabled alpha testing in the game, that seems to be a good workaround. 😀
http://dege.fw.hu/temp/RoadWars_NoAlphatest.zip

That exe works just fine without the errors previously mentioned when using dgvoodoo2, but it is the version 1.0 exe which works differently. I was wondering if you would be willing to patch the version 1.1 exe so that it works the same without the 1.0 exe limitations?

Thanks 😀

Yes, here it is http://dege.fw.hu/temp/RoadWars1.1_NoAlphaTest.zip

Squall Leonhart wrote:

Have you had a look at FF8 Dege?

Well, not... I realized I'd need to login into the game in the same way as for FFXI. But, if it's a 8 bit paletted game, doesn't 'Reduced color mode' with 8 bit 256 color helps for that? I encountered 2 other games with the same problem.

RibShark wrote:

So, Rayman 3: Hoodlum Havoc has an issue with NVIDIA cards on modern systems when hardware vertex processing is enabled where certain graphical effects (usually particle effects) are either missing or delayed (and when they are delayed, they are displayed tinted bright orange once they do show up). This doesn't occur with software vertex processing, nor does it occur when you edit the game to not use D3DUSAGE_DYNAMIC on that vertex buffer. It happens with just D3D8, with D3D8to9, with dgVoodoo and with WineD3D (which can sometimes crash shortly after the issue occurs). This can be tested within the first few seconds of gameplay, after collecting the three red orbs, particle effects will be missing on the last two. Any ideas on how this could be fixed and what could be causing it? If it helps, using dgVoodoo + DXVK makes the issue disappear.

Seems to be weird but I don't get this issue on nVidia. Or I just don't know what is expected to see. If disabling D3DUSAGE_DYNAMIC helps then that suggest some synchronization problem for dynamic buffer in the driver, but that feature is so common and basic that it'd cause problems for many other games.

galneon wrote:

Found a compatibility regression as of 2.55:

Kohan: Immortal Sovereigns and Kohan: Ahriman's Gift, games using the same engine which requires 16-bit color mode, both work very well with 2.54. Occasionally right click sticks in-game. The other issue is that when you launch either, the fullscreen window is immediately minimized, so you must get back to it by alt-tabbing or clicking on the taskbar. Neither of these problems happen with WineD3D.

2.55 does not have the latter problem either--however, mouse clicks are virtually ineffectual. The buttons on the main menu detect hovering, and clicking repeatedly on them will occasionally yield a sound effect and, eventually (20+ clicks) even registers as a proper push. I did try the obvious thing of alt-tabbing out and then back in--no luck. I was able to get KAG to crash once while trying to get menu buttons to register. The error message was something pertaining to the back buffer. I've tried to get it to crash again so I could take a screenshot of the error, but no luck after 15 minutes of trying.

Indeed. It doesn't work perfectly for me with 2.54 either but somewhat better. Didn't yet figure out the reason.

Dege wrote:

Squall Leonhart wrote:

Have you had a look at FF8 Dege?

Well, not... I realized I'd need to login into the game in the same way as for FFXI. But, if it's a 8 bit paletted game, doesn't 'Reduced color mode' with 8 bit 256 color helps for that? I encountered 2 other games with the same problem.

You don't need to login, here's a demo (and you want the demo since it drops you right into somewhere you can see the issue(s):
https://archive.org/details/FinalFantasyViiiDemo
Edit: oh and no, 256 color compatibility does not help.

XI and XIV are the only online Final Fantasy titles haha.

On the subject of demos, did you look at any of these three yet Dege?

https://www.moddb.com/games/nexus-the-jupiter … ngleplayer-demo
https://archive.org/details/RedlineDemo
https://archive.org/details/STRATDemo
https://www.fileplanet.com/87003/80000/filein … nsterville-Demo

Nexus The Jupiter Incident crashes when accessing the menu (ESC) after going ingame.
Redline crashes when initializing renderer if mipmapping is on.
Stratosphere Conquest of the Skies has spiky polygon syndrome.
Universal Monsters Monsterville has really broken rendering that for some reason gets better with higher resolution/MSAA.

I've told you about these before, I just retested them with 2.55.1 and they're still broken. I've also retested Gran Prix Evolution, but it's apparently a DllMain game.

Also, the first three Harry Potter games all unsurprisingly (they're all Unreal engine) work well:

They all natively have limited resolution support and bad UI scaling (text). The next games are DX9+. There's also Quidditch World Cup:

Pool of Radiance: Ruins of Myth Drannor works, but forced resolution, antialiasing and texture filtering all cause artifacts:

The buggy shadow and fire effect is because of forced resolution and the broken seams in the background texture is because of texture filtering. Natively the game is 800x600 only 🙁.

ZellSF wrote:

You don't need to login, here's a demo (and you want the demo since it drops you right into somewhere you can see the issue(s): […]
Show full quote

Dege wrote:

Squall Leonhart wrote:

Have you had a look at FF8 Dege?

Well, not... I realized I'd need to login into the game in the same way as for FFXI. But, if it's a 8 bit paletted game, doesn't 'Reduced color mode' with 8 bit 256 color helps for that? I encountered 2 other games with the same problem.

You don't need to login, here's a demo (and you want the demo since it drops you right into somewhere you can see the issue(s):
https://archive.org/details/FinalFantasyViiiDemo
Edit: oh and no, 256 color compatibility does not help.

Squall Leonhart wrote:

XI and XIV are the only online Final Fantasy titles haha.

So... I must have looked at some wrong place or don't know...
But thanks for that! I've just fixed it.

ZellSF wrote:

https://www.moddb.com/games/nexus-the-j ... layer-demo https://archive.org/details/RedlineDemo https://archive.org/details/STRAT […]
Show full quote

https://www.moddb.com/games/nexus-the-j ... layer-demo
https://archive.org/details/RedlineDemo
https://archive.org/details/STRATDemo
https://www.fileplanet.com/87003/80000/ ... ville-Demo

Nexus The Jupiter Incident crashes when accessing the menu (ESC) after going ingame.
Redline crashes when initializing renderer if mipmapping is on.
Stratosphere Conquest of the Skies has spiky polygon syndrome.
Universal Monsters Monsterville has really broken rendering that for some reason gets better with higher resolution/MSAA.

I've told you about these before, I just retested them with 2.55.1 and they're still broken. I've also retested Gran Prix Evolution, but it's apparently a DllMain game.

Not yet, but I'll to (try to) make some fixes for a new patch-release.

ZellSF wrote:

Also, the first three Harry Potter games all unsurprisingly (they're all Unreal engine) work well:

Yeah, except that Unreal engine games generally need 'FreeMouse' enabled in dgVoodoo config to prevent the usual game lock-up. The other way is to force only resolutions that aren't larger than twice the game-resolution.

Dege wrote:

ZellSF wrote:

Also, the first three Harry Potter games all unsurprisingly (they're all Unreal engine) work well:

Yeah, except that Unreal engine games generally need 'FreeMouse' enabled in dgVoodoo config to prevent the usual game lock-up. The other way is to force only resolutions that aren't larger than twice the game-resolution.

Or use the "unemulated" scaling modes? I played through the first level of Deus Ex at 640x480 forced to 1920x1440 and it worked fine. I know the mouse goes crazy if I set dgVoodoo2 to do AR correction and FreeMouse fixes that though.

Motor Mash works but has a sort of familiar issue, if you change from software to hardware rendering it pops up a windows dialog box with instructions on what to do if hardware rendering doesn't work. Unfortunately, it's impossible to click "OK" on this box and so it's impossible to set hardware rendering. Strangely it seems pretty irrelevant as resolution forcing works in the game's "software" rendering:

State of Emergency is another DllMain game, so not working in dgVoodoo2.

I gave Codename Eagle a try. I used version 1.36 (with 1.33 level 1 fix). Version 1.41 (latest official version) broke singleplayer (random floating point error crash) so 1.33/1.36 seems to be the latest working patch. I also used the following game settings:

Sound channels: 16
Detail: Max
GraphicFX: Max

My system configuration:

Windows 10 64-bit version 1703 with DirectPlay selected under legacy components
Intel i7-3770 @ 3.4 GHz
Radeon HD 7900 series GPU with driver version 18.4.1
dgVoodoo2 version 2.55.1

Results:

* Stock, Direct3D: Starts up ok, new game, first mission, crash to desktop with "InitD3D fails" message box.

* Stock, 3Dfx (640x480x16): Starts up ok, new game, first mission, crash to desktop with "glide not found" message box.

* dgVoodoo, Direct3D (800x600x32, 1920x1080x32): The main menu seems oddly low quality, kinda pixelated I suppose? Otherwise the game seems to work fine aside from the occasional crash. Fortunately game loading times are short on a modern system so restarting and reloading the game after a crash - while annoying - wasn't intolerably bad. I managed to finish the singleplayer campaign. CE was kinda buggy even back in the day when it ran on a 800 MHz Pentium III so this may or may not have anything to do with dgVoodoo.

* dgVoodoo, 3Dfx (640x480x16): Low quality menu, starts up ok, new game, first mission, game exists fullscreen mode and ends up in a small window on the upper left of the monitor. It seems to work but is unplayable due to the small size of the window and because it doesn't capture the mouse.

* nGlide 2.00, 3Dfx (640x480x16/1920x1080): High quality menu. I managed to play through a mission. Unfortunately, after winning or when attempting to enter the main menu (using ESC-key), the game crashes to desktop with "MenuApp() break 1" message box.