Isn't Vsync supposed to limit fps to monitor's value? (it's 60, usually). Some old games have no framecap and they go ultrafast, even at 60fps. Limiting them to 30 or lower with external software like bandicam usually fix the problem (you can even select how many frames/second)

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Liandri wrote:Ricochet Xtreme:Mouse clicks not always registering properly when in main menu. E.g., I'm clicking through Options -> About Ricochet -> Close -> About Ricochet -> Close etc. and in 50% cases I have to click twice or more to really get the button working.With DDrawCompat wrapper: there is no such problem.

Liandri wrote:I'm playing Ricochet Xtreme for now. Here is a major issue I've found: Lag. I've realized that mouse clicks problem (described in my previous post) is part of this issue. The lag is there from the very start, even though the rendering is at 60 FPS. The mouse cursor itself somewhat lags too. But the most visible issue with this is how ship moves when controlled. Normally, its movement should be silky smooth. With dgVoodoo 2 it's laggy, almost feels like 58-59 FPS. If I use Alt+Tab and switch back to game, it's silky smooth but only for a mere minutes, I don't know what exactly triggers it again. With DDrawCompat, there is no such problem.

So I've discovered that version 2.50 does not have this lag problem. 2.51 introduced it. Is it a known issue yet?

Liandri wrote:Ricochet Xtreme:Mouse clicks not always registering properly when in main menu. E.g., I'm clicking through Options -> About Ricochet -> Close -> About Ricochet -> Close etc. and in 50% cases I have to click twice or more to really get the button working.With DDrawCompat wrapper: there is no such problem.

Liandri wrote:I'm playing Ricochet Xtreme for now. Here is a major issue I've found: Lag. I've realized that mouse clicks problem (described in my previous post) is part of this issue. The lag is there from the very start, even though the rendering is at 60 FPS. The mouse cursor itself somewhat lags too. But the most visible issue with this is how ship moves when controlled. Normally, its movement should be silky smooth. With dgVoodoo 2 it's laggy, almost feels like 58-59 FPS. If I use Alt+Tab and switch back to game, it's silky smooth but only for a mere minutes, I don't know what exactly triggers it again. With DDrawCompat, there is no such problem.

So I've discovered that version 2.50 does not have this lag problem. 2.51 introduced it. Is it a known issue yet?

What about the lates WIP version?I fixed input lagging and engorgement, should work for that game too (altough I don't have it).

Myloch wrote:Weird as shit glitches for pc Mistake95 and Nichibutsu Mahjong Collection without use of wrapper (dgvoodoo2 not hooking...gdi?)Taken from win8.1 x64 pc with 9600m gt nvidia card.

Got a bug report for another crap game: Pax Corpus. Tested using current WIP version. I can't test this on any old hardware, but I don't believe it's rendering correctly. Except for some instability the game seems to work okay in accelerated D3D mode (it crashes in software mode) except that the draw distance is about two inches in front of the character. It doesn't really work natively on Windows 10.

lowenz wrote:Dege already said that VSync acts as a limiter entering a custom value for the refresh rate, but it's not working in DX.....now.Maybe a simple solution would be to choose between VSync and VSync/2.

Myloch wrote:Isn't Vsync supposed to limit fps to monitor's value? (it's 60, usually). Some old games have no framecap and they go ultrafast, even at 60fps. Limiting them to 30 or lower with external software like bandicam usually fix the problem (you can even select how many frames/second)

Yes, try the following for a Glide application: enable 'Enumerate refresh rates' on General tab, and type, say, '1280x1024, 12' into the resolution selector combo box on Glide tab. Run the Glide app and it will cap to 12 FPS at 1280x1024.The same should work for the DX part, but it doesn't do for some reason, it'll cap to the nearest supported monitor freq instead.

Did a look at Still Life under XP with dependancy walker it and uses a bunch of dll files from system32 folder but nothing that I could see relating to DirectX or Direct Draw, I did however see it using gdiplus.dll http://www.microids.com/EN/store/still-life,74 says it needs Direct X 8.1

kevsmudge wrote:Did a look at Still Life under XP with dependancy walker it and uses a bunch of dll files from system32 folder but nothing that I could see relating to DirectX or Direct Draw, I did however see it using gdiplus.dll http://www.microids.com/EN/store/still-life,74 says it needs Direct X 8.1

I got Still Life GOG version to work with Windows 7 64bit via dgVoodoo WIP 34. I used "Microsoft Application Compatibility Toolkit" and used the "Windows NT" compatibility mode through it. I could not get the game to work without the Microsoft Application Compatibility Toolkit (with or without dgVoodoo).

It seems like the main compatibility setting which makes the game start is "EmulateHeap".

The game looks gorgeous via dgVoodoo when you force high resolution, anisotropic filtering, vsync and bilinear blit stretch. It seems like forcing MSAA causes the game to sometimes stutter during speeches. Increasing the level of MSAA increases the amount of stuttering.

Dege, if you can get this game to work via dgVoodoo without compatibility mode and also fix MSAA stuttering, it will be great. It is not a very old game. It was made in 2005. I don't see why it needs EmulateHeap.

Thanks i'll give MACT a try, in XP SP3 VM I got a few bugs too and the videos where out of sync playing too fast.

1. Just before the Junkyard down the lane with the double doors you get this mirrored effect of your character walking on top of it's self, probably a glitch of the mirroring effect it gives you in water puddles.2. Odd line / pole artifact in the office carpark.3. Major slowdown in the section with the dingy and after you cross the water, walking around near the waterwheel is like 20fps.

Using "Windows NT" compatibility mode just caused it to hang and reduce colours to windows basic for me, I set it none instead with just EmulateHeap and it's working

Silanda wrote:Got a bug report for another crap game: Pax Corpus. Tested using current WIP version. I can't test this on any old hardware, but I don't believe it's rendering correctly. Except for some instability the game seems to work okay in accelerated D3D mode (it crashes in software mode) except that the draw distance is about two inches in front of the character. It doesn't really work natively on Windows 10.

Pax 2017-04-18 02-38-40-32.png

Ok, thanks!Pre-DX6 interfaces always have some surprises, I had to re-work some of the fog calculation code but it's fixed now.

CoolGamer wrote:

kevsmudge wrote:Did a look at Still Life under XP with dependancy walker it and uses a bunch of dll files from system32 folder but nothing that I could see relating to DirectX or Direct Draw, I did however see it using gdiplus.dll http://www.microids.com/EN/store/still-life,74 says it needs Direct X 8.1

I got Still Life GOG version to work with Windows 7 64bit via dgVoodoo WIP 34. I used "Microsoft Application Compatibility Toolkit" and used the "Windows NT" compatibility mode through it. I could not get the game to work without the Microsoft Application Compatibility Toolkit (with or without dgVoodoo).

It seems like the main compatibility setting which makes the game start is "EmulateHeap".

The game looks gorgeous via dgVoodoo when you force high resolution, anisotropic filtering, vsync and bilinear blit stretch. It seems like forcing MSAA causes the game to sometimes stutter during speeches. Increasing the level of MSAA increases the amount of stuttering.

Dege, if you can get this game to work via dgVoodoo without compatibility mode and also fix MSAA stuttering, it will be great. It is not a very old game. It was made in 2005. I don't see why it needs EmulateHeap.

It's great, I'm going to try it (altough I guess the game engine is (basically) the same as the ones used in Syberia1/2 which work fine for me through dgVoodoo).I can't do anything about EmulateHeap though: the game probably has memory overwrite bugs at some points which corrupts the heap descriptor blocks.

Thanks, just wish there was a better way to upscale the backgrounds and hud text, anything other than force point sampled creates tiling / seam lines, same with msaa at 2x or above, the game does have it's own on/off anti-aliasing menu option.In-game v-sync should be 60fps I think but sometimes it dips below it like on the robot spider laser puzzle going down to 30fps, mostly in-game it runs at 60-90fps for me ands shoots up to 300fps on menus and video, radtools states the videos as 25fps.Good news is the junkward reflection bug isn't there with dgvoodoo but the office carpark one remains.

Edit: Just checked CIN16205-01.bik fmv and it's not a bug in the office carpark it's just a massive car aerial.

Last edited by kevsmudge on 2017-4-22 @ 12:31, edited 1 time in total.

I have a question not strictly related to dgvoodoo (because DirectX 9). It's about GTA San Andreas (and it also applies to GTA 3 and GTA Vice City). It's about the Frame Limiter. The game gets a couple of glitches with car physics and stuff like that when the frame limiter is turned off. Sadly, the frame limiter is set to around 25 to 30 fps depending on the game. Do you think there is a smart way to fix this? For example, through hex-editing the executable after finding the addresses where time offsets or frame times are stored? Or is it likely that all those physics are hardcoded in an impossible-to-reverse-engineer way, like, spread over hundreds of places with hardcoded (not relative to a general value) values. Or worse, stuff like vel=vel*0.9?

TomArrow wrote:I have a question not strictly related to dgvoodoo (because DirectX 9). It's about GTA San Andreas (and it also applies to GTA 3 and GTA Vice City). It's about the Frame Limiter. The game gets a couple of glitches with car physics and stuff like that when the frame limiter is turned off. Sadly, the frame limiter is set to around 25 to 30 fps depending on the game. Do you think there is a smart way to fix this? For example, through hex-editing the executable after finding the addresses where time offsets or frame times are stored? Or is it likely that all those physics are hardcoded in an impossible-to-reverse-engineer way, like, spread over hundreds of places with hardcoded (not relative to a general value) values. Or worse, stuff like vel=vel*0.9?

Use SilentPatch to make the framelimiter correctly 30 FPS in San Andreas, which you should be using anyway at this point for GTA 3 - SA (by default 25). And yeah, all physics in the game are coded to work at 30 FPS, so don't turn the limiter off.