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:external software like bandicam usually fix the problem (you can even select how many frames/second)
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.
Liandri wrote: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?
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)
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
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.
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".
There are too many complaints about this game on its official GOG forums. It seems like most people are not able to get it to work.
https://www.gog.com/forum/still_life_se ... tart/page1
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.
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?
awgamer wrote:With Rivatuner you can set the frame rate limit to anything.
MrEWhite wrote:awgamer wrote:With Rivatuner you can set the frame rate limit to anything.
Doesn't mean the physics will work right. They're pretty sensitive.
Users browsing this forum: No registered users and 4 guests