I'm up to my neck in non-dgVoodoo works nowadays, unfortunately, so can't be too active.
But, recently I surveyed what to do next. The list is not really about new features but some existing problems and revising some internals (for example, crash with SpaceBunnies pointed out some things).
KainXVIII wrote:I don't get it how to achieve fullscreen image with dgvoodoo in MDK (gog version), il always stays windowed in top left corner of the screen...
UPD - ok, so i somehow solve this problem, but there is another - how to get rid of blinking lines around edges of screen?
I could only try the original version and it was ok. But, I only played the first level.
ed_barber wrote:Your wrapper is probably the best thing I've come across for retro gaming on Windows 10 as I've gotten every game I tested on it to work! I have one game called Delta Force 2 and it has support for both software rendering and semi-hardware rendering. The thing is that in hardware mode the objects being rendered using Direct3D (I believe uses DirectX 6) get shown through the terrain (rendered in software mode even if the renderer is set to full-screen hardware) even when they are behind it. If I use dgVoodoo 2 to try and fix it it will actually make everything that's rendering in Direct3D disappear so only the terrain is in the scene with the fonts on the characters that represent their friendly tag. It would be cool if you could look into this. I would love to see the day I can finally play this lost treasure while making use of its 3d acceleration on modern hardware.
Thanks!
I tried this game, and yes, I got the same through both dgVoodoo and natively, wrong z-order. Didn't yet checked what's going on (the rendering technique) though, but it's on the list. 😀
ed_barber wrote:
I even heard that the chipsets listed such as the nVidia TNT 2 had issues with the game too. I even got a GeForce 7600 GS using drivers from around June 2008 to render everything correctly in hardware mode but at a lower than anticipated framerate. Your work is very great and you should consider contacting game companies with your fixes. Many people would love to see certain retro games able to play once again!
Would game companies re-release their old stuff with new fixes? 😀
I think they don't care and release them to Steam or Gog.
But, yeah, would be nice, for example, if Splinter Cell (or any other fixed game) could be available as a simple drm-free release with modern installer, all patches, texture packs, and so on, gog-like.
ed_barber wrote:
PS. It would be nice if there was an option to use either hard or soft shadows in when the game is using shadow buffer mode such as in Splinter Cell 😀
I'm not against it but I wouldn't like to have an option for this on the GUI.
An ini-file config would be better, exclusively for experts, where everything could be finetuned.
VirtuaIceMan wrote:Any chance of getting table fog in Shadows Of The Empire? As far as I know, the GOG version has fog, and whilst this site recommends DXGL I didn't have any luck with it: http://www.play-old-pc-games.com/2015/02/10/w … shadows-empire/
It's particularly noticeable on level 2, Escape from Echo Base, this video shows it with and without. On my 980 whether I use it's own D3D or dgVoodoo 2.53, there's no fog 🙁 https://www.youtube.com/watch?v=WdkbC3iOsD8
Yes, I hope. I'll check it.
gameragodzilla wrote:I haven't been able to recreate them so far, so I will when I can. […]
Show full quote
daniel_u wrote:Post some pics and hope Dege will look into the problems. 😀
I haven't been able to recreate them so far, so I will when I can.
The big issue is still the stutter, though. It's annoying that every time I reload a save, I get a brief stutter for everything. Would like to play this way with 100% smooth gameplay like I could normally without dgVoodoo 2.
Especially since dgVoodoo 2 seems to be the only wrapper that actually fixes buffer shadows.
EDIT: Also, I was perfectly content with just playing with projector shadows, but recently, the level Vselka Infiltration glitches out at the end if I use them. Basically, the guards would not spawn properly and thus run into each other and get stuck on the stairs. So no one would actually go into the room and I'd be stuck as the doors are locked.
Is there a way to fix this? It literally only happens with projector shadows. Anytime I switch to buffer, it works perfectly fine.
Hmmm..... I never experienced this. Couldn't it be a driver problem? I have bad experiences with AMD drivers, for example, ATI tech demo Island2 doesn't run properly on my R7 360, flashing polygons and screen parts, etc. On other hw, it runs fine.
You could try the WARP rendererer with a low resolution (640x480) and without extras (like MSAA) in windowed mode, to see if stuttering is caused by the video card.
VEG wrote:Dege wrote:The polygon glitch is strange because I don't think that there is any difference between DX6 and DX7.
Is transparency solved wit […]
Show full quote
The polygon glitch is strange because I don't think that there is any difference between DX6 and DX7.
Is transparency solved with textures with alpha channel or legacy colorkeying?
If alphaed textures then DX6 and DX7 should be equivalent but the thrash driver may configure the fixed function pipeline in some other way for DX7, for some reason.
If colorkey then it's MAYBE renderstate D3DRENDERSTATE_COLORKEYBLENDENABLE, it's DX7-only and if it's enabled then colorkeyed pixels forced to 0 without discarding the pixel.
But, it all should be debugged.
I've found the difference between the DX6 and DX7 thrash drivers which causes the problem. DX6 thrash driver reports to the game that it supports textures from 8×8 to 256×256 (it's hardcoded). DX7 uses actual device capabilities and reports that it supports textures from 1×1 to 8192×8192. The game doesn't like when minimal texture size is less than 4×4. That invisible tree uses a 2×2 transparent texture. When minimal size is larger than a texture size, the game stretches the texture before using. If I set minimal texture size of DX6 to 1×1, it causes the same problem. So, some code in the renderer or in the game don't like when too small textures are used. So, I have a good workaround for this problem (treat every minimal texture size below 4×4 as 4×4), but the root of the problem why something doesn't like too small textures is still mysterious 😀 Maybe later I'll try to understand it better. At least the problem is workarounded.
Maybe the stretching code is wrong in the trash drivers?
If it's done by Blt then the RECT parameters can be wrong (RECT is exclusive as for right and bottom) so one row and column may remain unblitted. Or sg like that. 😀