Reply 3020 of 3949, by lowenz
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.
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.
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"
Yes, but in dgVoodoo2 you can (theoretically, now it's a non-working feature) enter a custom value to act as a FPS limiter or so Dege once said.
wrote:external software like bandicam usually fix the problem (you can even select how many frames/second)
MSI Afterburner + RTSS is a good alternative.
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.
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?
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.
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
wrote: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.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).
wrote:Weird as shit glitches for pc Mistake95 and Nichibutsu Mahjong Collection without use of wrapper (dgvoodoo2 not hooking...gdi?) […]
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.
Well, yes, dgVoodoo doesn't hook GDI (yet).
That's why some movie scenes produces black screen in some games, wrong palettes in DDraw+GDI mode old games, etc. 😐
Those palette problems happen with win8.1 vanilla drivers, not dgvoodoo, apparently nVidia has some problems with ancient graphic modes. It reminds me of win7 dreaded rainbow palette glitch
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
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.
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.
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
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_series/b … _on_start/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.
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 😎
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.
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.
wrote:I got Still Life GOG version to work with Windows 7 64bit via dgVoodoo WIP 34. I used "Microsoft Application Compatibility Tool […]
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.1I 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_series/b … _on_start/page1The 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.
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?
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.
With Rivatuner you can set the frame rate limit to anything.
wrote:With Rivatuner you can set the frame rate limit to anything.
Doesn't mean the physics will work right. They're pretty sensitive.
wrote:wrote:With Rivatuner you can set the frame rate limit to anything.
Doesn't mean the physics will work right. They're pretty sensitive.
Don't the psp games have 60fps patches for ppsspp? if it's anything like re4 the pc / psp ports will share code and the same values as the ps2.