Or a wacky way to support "HD" resolutions with 2D elements scaled since Sin didn't have any on the list, or GoG ignorantly assumed it was a Glide game. There is quality loss going that path anyway since Sin does have a lot of 24/32-bit textures, to the point the software mode has unique palettes and color lookup tables per level and recolors every texture to the palette.

robertmo wrote:

btw dosbox works faster with cycles max 105% (105 is actually 95%, while 100 is 90). It was left like that to be comparable with older dosbox versions that had 90% limit. 90 was called 100 so that people don't ask how to set 100.

What if you set cycles max 110%?

So I take it just ignore the Chrome warnings that these files are malicious?

mr_bigmouth_502 wrote:

robertmo wrote:

btw dosbox works faster with cycles max 105% (105 is actually 95%, while 100 is 90). It was left like that to be comparable with older dosbox versions that had 90% limit. 90 was called 100 so that people don't ask how to set 100.

What if you set cycles max 110%?

Just like Spaceballs One you go to plaid 😁

Not sure what would happen if you tried that pecentage however.

Greatings Dege,

Is it possible to reduce the hardware requirement for dgVoodoo2 to include support for Direct3D10 Shader Model 4.0? In the latest release 2.32, you mentioned that you have a special version which works on GeForce 8600GTS, but the work was not released. If you already worked on it, then may just as well release it to gain supports from GeForce 8/9 class owners.

kjliew wrote:

Greatings Dege,

Is it possible to reduce the hardware requirement for dgVoodoo2 to include support for Direct3D10 Shader Model 4.0? In the latest release 2.32, you mentioned that you have a special version which works on GeForce 8600GTS, but the work was not released. If you already worked on it, then may just as well release it to gain supports from GeForce 8/9 class owners.

Hi!

Shadermodel 4.0 could be included but, finally, I dropped the idea.
1. I know it sounds weird but there would be no mipmapping through glide with SM4.0.
2. AFAIR the performance wasn't so good on that GF 8600GT (and supposedly on all contemporaries), so I thought it wouldn't worth the effort.

I'm not sure, but due to other pending developments, I may change my mind with a later version and include an SM4 build in the zip.

I released a new version.
First version of DX5, 6 and 7 support is added.
But haven't yet tested with tons of games. By now and for the time being I have enough of it all. 😀

Dege wrote:

I released a new version.
First version of DX5, 6 and 7 support is added.
But haven't yet tested with tons of games. By now and for the time being I have enough of it all. 😀

Amazing stuff! I have no time for wrapper testing these days (just time for, well, talking about them) but I hope my fellow gamer geeks here at VOGONS can give it a solid workout. 😀

Still no joy for ATI

Visiting my folks for thanskgiving so hopefully I'll have time for testing....

So far today:
Helped put up insulation in a building.
Helped rake and burned leaves
Grocery\hardware shopping.

They work tomorrow so hopefully no more work for me... heh

Neat, the dynamic lighting in Direct3D mode on King Quest Mask of Eternity works at full speed. (change the setting in options.cs)

DosFreak wrote:

Visiting my folks for thanskgiving so hopefully I'll have time for testing....
...
They work tomorrow so hopefully no more work for me... heh

One of my Linux-using friends said "*SNRK* WINE has had decent support for DirectX/Direct3D 7.0 and lower for quite some time now" so I am curious how dgVoodoo 2 DirectX compares against Wine for Windows. Don't think anyone's doing builds for them against latest WINE anymore tho, PCGamingWiki has links to DX8.1 and DX9 DLLs: http://community.pcgamingwiki.com/tags/downloads/Wine/

Still no joy for ATI

You mean it doesn't work on ATI?
Well I didn't changed Glide shaders at all since the last version so the same issues are expectable... 🙁
I submitted my bug report with a simple repro app to ATI back in April but there's no answer at all. I also doubt they fixed anything related to this in their drivers.
As for DirectX, I forgot to test it on my lowend ATI. I wanted to but I very wanted to get rid of this version as well, I may have slapdashed it.

Neat, the dynamic lighting in Direct3D mode on King Quest Mask of Eternity works at full speed. (change the setting in options.cs)

Cool, thanks! 😎 I didn't know that it can be forced in D3D.

of my Linux-using friends said "*SNRK* WINE has had decent support for DirectX/Direct3D 7.0 and lower for quite some time now" so I am curious how dgVoodoo 2 DirectX compares against Wine for Windows.

Personally, I don't have a clue. 😀
Never tried Wine on Windows. Maybe the newest version is cool but no binaries compiled for Windows?

Dege wrote:

One of my Linux-using friends said "*SNRK* WINE has had decent support for DirectX/Direct3D 7.0 and lower for quite some time now" so I am curious how dgVoodoo 2 DirectX compares against Wine for Windows.

Personally, I don't have a clue. 😀
Never tried Wine on Windows. Maybe the newest version is cool but no binaries compiled for Windows?

It seems no one has released builds of the full Wine on Windows since July 2013, while Wine has swiftly moved on since then.
http://www.nongnu.org/wined3d/
It also has issues: http://wiki.winehq.org/WineD3DOnWindows
and more issues: http://wiki.winehq.org/WineOnWindows

Someone on GOG.com forums was building these, but that's all.
http://community.pcgamingwiki.com/files/file/ … ows-directx-81/
http://community.pcgamingwiki.com/files/file/ … dows-directx-9/

[EDIT] And now it seems there's a new project, "dosse91" plans to keep releasing builds for Windows. WineD3D 1.7.32 is up.
http://sourceforge.net/projects/wined3d4win/

Some of which can be worked around: https://forums.virtualbox.org/viewtopic.php?f=6&t=25939

Well, there's always this project for OpenGL 2.x users, but I suspect it is not as far along as dgVoodoo. (Maybe he could use some help.)
https://www.williamfeely.info/wiki/DXGL
Here are his thoughts on the matter: https://www.williamfeely.info/phpBB3/viewtopic.php?f=5&t=10

[EDIT] Made a post about dgVoodoo on DXGL forums, and one announcing the new DirectX feature of dgVoodoo on VOGONS: dgVoodoo now offers DDraw\D3D wrapper to Direct3D 11

Dege wrote:

You mean it doesn't work on ATI? Well I didn't changed Glide shaders at all since the last version so the same issues are expect […]
Show full quote

Still no joy for ATI

You mean it doesn't work on ATI?
Well I didn't changed Glide shaders at all since the last version so the same issues are expectable... 🙁
I submitted my bug report with a simple repro app to ATI back in April but there's no answer at all. I also doubt they fixed anything related to this in their drivers.
As for DirectX, I forgot to test it on my lowend ATI. I wanted to but I very wanted to get rid of this version as well, I may have slapdashed it.

I have an older lower end card (ATI Radeon HD 4600). I was trying it with KQ MoE. It crashes the game on launch, either with the Glide or with the D3D. Zeckensack's ancient 0.84c works but with dynamic lighting on it is too slow.

collector wrote:

Dege wrote:

You mean it doesn't work on ATI? Well I didn't changed Glide shaders at all since the last version so the same issues are expect […]
Show full quote

Still no joy for ATI

You mean it doesn't work on ATI?
Well I didn't changed Glide shaders at all since the last version so the same issues are expectable... 🙁
I submitted my bug report with a simple repro app to ATI back in April but there's no answer at all. I also doubt they fixed anything related to this in their drivers.
As for DirectX, I forgot to test it on my lowend ATI. I wanted to but I very wanted to get rid of this version as well, I may have slapdashed it.

I have an older lower end card (ATI Radeon HD 4600). I was trying it with KQ MoE. It crashes the game on launch, either with the Glide or with the D3D. Zeckensack's ancient 0.84c works but with dynamic lighting on it is too slow.

What about using nGlide 1.03, dgVoodoo 1.50Beta2, psVoodoo, or OpenGlide 0.09rc9 (included with Glidos) for now? Have you tried them?

Today morning I couldn't stand and did a quick test with my ATI HD6450.
Tried it with the followings:

- Tomb Raider 3,4,5 (D3D)
- MadTrax (D3D, Glide)
- KQ MoE (D3D)
- One of the demos I listed in the readme (D3D with Phong shading)

Everything worked perfectly, except
- the usual, MadTrax wasn't completely smooth with Glide (because Glide needs power for emulated texture sampling, as always)
- I set vain useDynamicLighting to 1 in Options.cs, there was no dynamic lighting applied

I don't know what it does on HD7xxx series, as Glide has problems with that.

I have an older lower end card (ATI Radeon HD 4600). I was trying it with KQ MoE. It crashes the game on launch, either with the Glide or with the D3D.

Hmm, it's a DX 10.1 capable card. Are you interested in creating a log to see what happens (the same process that Walt did for me with Glide)?

@Stiletto: Thanks Pal, I very appreciate your service! 😀
I'm going to have a look at those links!

From WineHQ docs:

t the moment Direct3D8 (d3d8.dll) , Direct3D9 (d3d9.dll) and Direct3D 10 can be used on Windows. DirectDraw and Direct3D<7 can't be used at this point due to a conflict with opengl32.dll. [In short ddraw.dll loads wined3d somewhere at startup (e.g. when a surface is created). Wined3d dynamicly loads opengl32.dll when it is loaded. During initialization of wined3d we query the opengl capabilities and for this purpose use opengl functions like wglCreateContext and wglMakeCurrent. It appears that when wglMakeCurrent is called, this triggers opengl32.dll to create a directdraw surface (so native opengl32.dll calls our ddraw.dll!) and since wined3d wasn't initialized we again have to initialize opengl and this causes some infinite loop. There are hacks to get it to run but it is very unstable and 3d won't work. The proper solution is likely to avoid opengl32.dll and directly load the ICD.]

Offf course, why it didn't came to my mind... Windows OpenGl uses DirectDraw to create the single/double buffer for the rendering window, so DX->OGL wrapping can't work on Windows.
But it must work OK on any other platform.

Could DX wrap to the mesa3d sw rasterizer? (or a modified one)

truth5678 wrote:

Could DX wrap to the mesa3d sw rasterizer? (or a modified one)

Well, I don't know the capabilities of mesa3d but if it can render into a bitmap then it could somehow be utilized.
There were 2 ways to do that:
- Either it would be part of the current DX11 rendering environment (as a software 3D device) as a new implementation of the internal D3Ddevice-driver interface
- Or a completely new implementation for a sw rendering environment (it would be much work)

The first way seems to be viable, as software devices are handled in the same way in MS DX, but I think it would require some development in DDraw as well.
So, the answer is: maybe but it would require additional development.