Reply 1860 of 3949, by Dege
@Teleguy: the config file you attached is unfortunately pretty uncorrupted. I have the feeling that dgVoodoo cannot read the config file (for whatever reason) on your laptop, and because of that, it uses the default config. Such a situation fully explains the symptoms because the output API is 10.1 in the default cfg. Because dgVoodoo couldn't be used with the default cfg on a 10.0-only hardware (and it's not good at all as the wrapper should always work without any additional configuring), I introduced the term of 'Best available API' for the output API in the config.
So, I've created a new WIP,
http://dege.fw.hu/temp/dgVoodooWIP20_2.zip
in which
- 'Best available one' as an API option is appeared, and this is the default. If this one is choosed then the wrapper tries to initialize through 10.1 and if it's unavailable, then through 10.0. If any other is selected as an API then strictly that one is tried. One can see in the setup API combo that what APIs are present on his/her computer (only the available ones are added into the list).
- I managed to reproduce the resolution-getting-stuck problem with Mortyr, and fixed it (once a resolution was set, the subsequent ones were just (down)scaled to that), but didn't try it with Populous.
- Also found a minor, general texture sampling shortcoming that came from emulated texture formats. This fix put an end to some glitches present in some scene demos.
Other pendig things...: 😀
- Sky glitch in Fr-08 is unfortunately cannot be fixed. It's because the demo uses 'texture wrapping' (not to be confused with wrapping texture addressing mode) which is completely removed, starting from DX10 and up, under the aegis of the slogan 'Instead of texture wrapping, fix your geometry!'. It's so lowlevel rasterizer-feature that it cannot be emulated (like w-buffering). 😢
- DX8-thrash driver: I can stably reproduce the flashing polygon-mess, BUT, khmm, it only comes under special circumstances: real fullscreen mode with max game speed (no debug builds, debug layers and such). Under such circumstances, using even a count-based breakpoint doesn't help. The last frame before the debug-break is always rendered properly. As if the game knew that it will be broken 1-2 frames later and suddenly pull one's finger out, just to fool me. This all is like quantum physics: as if I made an effect on its wave funcion just by observing it and causing it to collapse into the right state. 😵 The Matrix never allows debugging itself.
Guys, thanks for the reports,
- MCM2: I'd try it myself, however I either cannot install my copy, even on a virtual pc with XP, or can't start the game itself because it always quits with some making-no-sense error message, can't remember which one, but didn't find any patch for that.
- Deadly Dozen: it works for me with the full game, as for the rendering ('fast vidmem access should be disabled for that'). But unfortunately, after entering the game from the menus, some controls like mouse buttons and the 'Esc' button stop working, so practically, you can't even quit the game. It's an unsolved mystery, probably something that DirectInput doesn't like. I'll try however its demo.
- Half Life: if I remember correctly, I only have its demo, and tried ages ago but I'm curious, and will try the full game to see what happens.
(There are other games too in the list, like Resident Evils, ...)