@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, ...)

Downloading now 😁

A question: is there a way to use the "Microsoft Basic Render Driver" as valid GPU *without* un-loading the GPU drivers (Win 8.1/Win10)?
Is it MS WARP, right?

Yes, it's WARP but I can't remember if it's SDK-only or part of the operating system. If it is then a new API output could be added for it.

It's integrated in the OS but normally you can use it only unloading the GPU drivers (control panel -> device manager -> disable GPU).
If I force it in dgVoodoo2 (without unloading the real GPU drivers) with Unreal, I got the classic *bundled* software rendering of Epic (no D3D via WARP, the 1998 software rendering of Tim Sweeney 😁 )
I'll try it with other games 😁

SC Pandora Tomorrow color of the lights are still buggy.
You can see in the image that the color starts out as white , then yelllow then ends with red.Original rendering it's different.White and yellow beams if i remember this right.
I would love to see this fixed one day. Even more when you have the source code of the the original fix. 😁.

With the new build no more problems with my 9600M about the GPU availability in single/specific profiles 😁
Great work!

Dege wrote:

@Teleguy: the config file you attached is unfortunately pretty uncorrupted. I have the feeling that dgVoodoo cannot read the con […]
Show full quote

@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).

No change. dgVoodoo still can't initialize. 😢

Edit: This Laptop can run Fractured Space (slideshow). That game requires Directx 11 feature level 10.0 so that can't be it.

Populous The Beginning works great again now.

daniel_u wrote:

SC Pandora Tomorrow color of the lights are still buggy.

I got the same there.....it's really a strange phenomenon/behaviour, maybe related to some kind of integration/accumulation.
Turning the camera the only thing red is a little light beam part:

daniel (or somebody 😁), can you check this point with a retro-system / PS3 / Xbox ? (if you got one)

The light meter indicates a light but there's no shafts.....so the red we see maybe it's the sum of the TWO opposite windows....but one doesn't have correct shafts.

Errata corrige: Altered light colours are related to one source only. Playing with the hjstogram there are clearly 3 zones (white, yellow and red)

lowenz wrote:

I'll try it with other games 😁

OK, now I'm officially impressed.

With standard MS WARP Pandora Tomorrow can run but it crashes loading a level. Unreal Engine error of some kind.
With MS WARP+dgVoodoo2 (and no real GPU active, only the CPU with DX runtime+Dege runtime, I disabled the GPU drivers) the game works.....I can load a level and play (1 FPS but it runs correctly).

Dege owned MS with its own sw reference rasterizer.....kinda total pwning from a one-man army 😁

As for Deadly Dozen - indeed, after changing settings it's finally working, but like you said, Dege, controls are messed up, so it's unplayable (i tried to paste dinput.dll from original dx7, but that didn't helped):(
My problem with this game is that I have laptop with nvidia optimus and there is no way to force it to use dedicated card with DD (and many other older titles as well), so I must play on intel gpu which can't handle it well. Besides, capture softwares just don't want to cooperate:/

Half Life is still not working for me, maybe settings tweaking is needed, but I don't know which of them.

Anyway, thanks:)

Edit:

Deadly Dozen 2: the same problem with controls + blinking mouse arrow + strange foliage streaking.
Performance is just terrible on default ms dx, drops even below 10. On dgvoodoo2 it's between 40 and 60.

De-M-oN wrote:

I just would wish a bit more stable 60fps. its swapping between 57 and 60. but the 3fps swapping feels a bit stronger than the number difference may guess you. But thats crying at big niveau. I'm happy. But maybe you have a tip to make it more stable 60fps? Using less MSAA didnt help. And the game apparently uses vsync/framelimit too.

This turned out to be a bigger problem than first thought.

Dege wrote:

As for the FPS drop, what about slightly smaller resolution? If it's still jumping between 57/60 fps then the issue probably is not reolution related.

Definitely not.

I could make out where the drops come from. It's the effects like tire smoke, dust/sand clouds, and such.

You especially notice it when you drive with traffic and drive behind of a water truck.
I mean this one:

The water it produces on its backside reduces fps to 30 to 40 fps - the closer you are in the water cloud, the worse the fps gets.

Any chance to fix it?

lowenz wrote:

Errata corrige: Altered light colours are related to one source only. Playing with the hjstogram there are clearly 3 zones (whit […]
Show full quote

Errata corrige: Altered light colours are related to one source only. Playing with the hjstogram there are clearly 3 zones (white, yellow and red)

Original rendering it's different. White and yellow beams if i remember this right. Not beams made from 3 colors. 😀

SC PT behaves different on Xbox, PS3 and PC.
For the PC(port of xbox) there are some game bugs which is related to mouse movement. But the color of the lights is a wrapper thing. Komat wrapper had this also but i've seen it only in 3 places.
Funny thing is Xbox lighting is superior to the PC.
I see you play with PS3 HD textures. Try without them. Last i saw these remove some details which is why i dont use them.(i'll post an example later in SC PT thread)

Edit:
Here is Komat comment on theproblem of the color of the light and more 😉
Edit: The color problem seems to be related to precision of the color buffer. The beams are created by many additive layers so even 1/256 delta in one color component will after many additions accumulate to visible difference. Older cards did support HW dithering although I am not sure that it was applicable to 32 bit mode.

The game also has some bug and it is sometimes selecting incorrect lights when generating shadowmaps. I noticed the problem when debugging the colored lighs. That light is spot light so the shadowmap should be always generated from the same location however depending on angle of the view, when generating the shadowmap for rendering of the beams, the game sometimes uses projection from entirely different place. When it tries to use it, it will provide proper light as well as when rendering shadowmap for the floor. The strange thing is that it does not happen with the period-correct HW so maybe it is some uninitialized variable or something else depending on the capabilities features reported by the GPU.

I have no clue what this means. 😀 The last part of the comment, the way he put it sounds like SC1 problem. 🤣.

I know very well the "HW dithering" problem (nonexistent in pre-DX10 GPU era) BUT Dege wrapper solved that problem ages ago (you can see it very well in MechWarrior 3 terrain textures: the only "real" GPUs not affected are the Intel ones, this is why this wrapper is SO precious for a retrogamer 😁).

Wow! 😎
I was very curious and quickly added support for D3D11 MS Warp as API output.
This renderer is way faster than I ever thought. First, when I tried it with a Farbrausch demo (ok, at a low resolution, 640x480 or 800x600) then it went so smooth that I thought there was a bug in the code and the wrapper drove a hw renderer. 🤣

I did some experiments on a Core i7-2600 CPU (3.4GHz). The Warp renderer scales very good for the available CPU cores: it is swearing at 70-80% for me when it has to render many complex things.

1280x1024 with 4x MSAA:

- Pandora Tomorrow: 7-8 fps at the first level, looking to the waving sea
- BloodRayne2: first level, ~10 fps (altough the black bars on the walls are present, as they were with earlier versions of dgVoodoo, seems to be a problem with cube texture sampling emulation)
- Giants - Citizen Kabuto: 15 fps, quite playable (!)
- Zanzarah - Hidden Portal: 20 fps, quite playable (!)
- Tomb Raider Chronicles: constant 30 fps, fully playable

I bet MS wrote and built in a "shader bytecode->x86/x64 bytecode" compiler in the Warp renderer because these results are pretty above my expectations.
(They did that back in DX8(!) for the cases when vertex processing was set to software mode, that is, vertex shader bytecode had to be executed on the CPU.)

It has some issues though: Quartz redirection doesn't work for some reason and it seems to always handle Alt-Enter itself, while I disable it to no avail.

daniel_u wrote:

Original rendering it's different. White and yellow beams if i remember this right. Not beams made from 3 colors. :) […]
Show full quote

lowenz wrote:

Errata corrige: Altered light colours are related to one source only. Playing with the hjstogram there are clearly 3 zones (whit […]
Show full quote

Errata corrige: Altered light colours are related to one source only. Playing with the hjstogram there are clearly 3 zones (white, yellow and red)

Original rendering it's different. White and yellow beams if i remember this right. Not beams made from 3 colors. 😀

SC PT behaves different on Xbox, PS3 and PC.
For the PC(port of xbox) there are some game bugs which is related to mouse movement. But the color of the lights is a wrapper thing. Komat wrapper had this also but i've seen it only in 3 places.
Funny thing is Xbox lighting is superior to the PC.
I see you play with PS3 HD textures. Try without them. Last i saw these remove some details which is why i dont use them.(i'll post an example later in SC PT thread)

Edit:
Here is Komat comment on theproblem of the color of the light and more 😉
Edit: The color problem seems to be related to precision of the color buffer. The beams are created by many additive layers so even 1/256 delta in one color component will after many additions accumulate to visible difference. Older cards did support HW dithering although I am not sure that it was applicable to 32 bit mode.

The game also has some bug and it is sometimes selecting incorrect lights when generating shadowmaps. I noticed the problem when debugging the colored lighs. That light is spot light so the shadowmap should be always generated from the same location however depending on angle of the view, when generating the shadowmap for rendering of the beams, the game sometimes uses projection from entirely different place. When it tries to use it, it will provide proper light as well as when rendering shadowmap for the floor. The strange thing is that it does not happen with the period-correct HW so maybe it is some uninitialized variable or something else depending on the capabilities features reported by the GPU.

I have no clue what this means. 😀 The last part of the comment, the way he put it sounds like SC1 problem. 🤣.

Could you upload a savegame for exactly that position, plz? Once I went through the jerusalem level but couldn't see that issue (or just my display was too dark...😁).
Dithering shouldn't be a problem because dgVoodoo always renders at 32bit.

teleguy wrote:

No change. dgVoodoo still can't initialize. 😢

Edit: This Laptop can run Fractured Space (slideshow). That game requires Directx 11 feature level 10.0 so that can't be it.

Do resolutions appear in the setup app when 10.0 is selected? Because if they do then D3D11 can be initialized and the dll side has something else problem.

About the Pandora Tomorrow save, you can simply add to SplinterCell2User.ini the command "mission win" (with the space) binding it to a free key, complete the first missions (pressing the key 😁) and unlock the Jerusalem level. Few steps after the intro area you got that window alley (where the 2 first encountered policemen are patroling).

Dege wrote:

Could you upload a savegame for exactly that position, plz? Once I went through the jerusalem level but couldn't see that issue (or just my display was too dark...😁).
Dithering shouldn't be a problem because dgVoodoo always renders at 32bit.

I will post several saves with different spots where the issue appears once i get home. And yes i recommend to adjust your brightness a few notches up. It tends to be dark.
I do not play with night vision on because i enjoy the shadows very much. 😀 Thank you.

But if you are in hurry, 😀, it 's the first window, after the opened door, in the jerusalem level after the stairs/starting of the level . 😀 A 7-8 seconds walk from the start.

Dege wrote:

Wow! :cool: I was very curious and quickly added support for D3D11 MS Warp as API output. This renderer is way faster than I e […]
Show full quote

Wow! 😎
I was very curious and quickly added support for D3D11 MS Warp as API output.
This renderer is way faster than I ever thought. First, when I tried it with a Farbrausch demo (ok, at a low resolution, 640x480 or 800x600) then it went so smooth that I thought there was a bug in the code and the wrapper drove a hw renderer. 🤣

I did some experiments on a Core i7-2600 CPU (3.4GHz). The Warp renderer scales very good for the available CPU cores: it is swearing at 70-80% for me when it has to render many complex things.

1280x1024 with 4x MSAA:

- Pandora Tomorrow: 7-8 fps at the first level, looking to the waving sea
- BloodRayne2: first level, ~10 fps (altough the black bars on the walls are present, as they were with earlier versions of dgVoodoo, seems to be a problem with cube texture sampling emulation)
- Giants - Citizen Kabuto: 15 fps, quite playable (!)
- Zanzarah - Hidden Portal: 20 fps, quite playable (!)
- Tomb Raider Chronicles: constant 30 fps, fully playable

I bet MS wrote and built in a "shader bytecode->x86/x64 bytecode" compiler in the Warp renderer because these results are pretty above my expectations.
(They did that back in DX8(!) for the cases when vertex processing was set to software mode, that is, vertex shader bytecode had to be executed on the CPU.)

It has some issues though: Quartz redirection doesn't work for some reason and it seems to always handle Alt-Enter itself, while I disable it to no avail.

Yes, it's well multi-threaded and it must run very well on last Intel processors (AVX/AVX2 optimisations, etc. like LLVMPipe, that is *great* ).
But your wrapper is an essential tool nonetheless 😁

Now that we got a the Output API (without killing GPU drivers?) entry we'll still get the (non-functional, I presume) adapter entry "MS Basic Render Driver" ? Maybe it's a bit confusing for the not-so-power user.