Glurak wrote:Yes could be but Blizzard said in his Forum that they will support Glide maybe you should just aks to support your wrapper ? i […]
Show full quote
Yes could be but Blizzard said in his Forum that they will support Glide maybe you should just aks to support your wrapper ? i dont know, Here is the Post:
http://us.battle.net/en/forum/topic/20742864601
It looks like the Developer of nGlide has the same problem and he try to talk with Blizzard:
http://us.battle.net/en/forum/topic/20742849642
They gave him an answer that they will look into it for 1.14c
Just a Question your Wrapper dont support DDraw Games like Diablo 1 // Warcraft 2 Bnet Edition or Command And Conquer Tiberian Dawn// Red Alert? When yes is there a tutorial or something to scale the Games?
Cool, the we only have to wait for 1.14c. In fact, Blizzard doesn't support Glide in their 1.14b patch, only in a broken way that works only with Sven's wrapper. Once they fix the function names, it'll automatically work with dgVoodoo again (and nGlide, ZeckenSack, and a real 3Dfx driver again), so I don't have to ask anything.
Till then, what about D3D? Diablo II worked with it for me, but I'm not sure if there is something special in Glide as for the rendering quality.
Glurak wrote:
Just a Question your Wrapper dont support DDraw Games like Diablo 1 // Warcraft 2 Bnet Edition or Command And Conquer Tiberian Dawn// Red Alert? When yes is there a tutorial or something to scale the Games?
Do you mean, upscaling the resolution? That makes no sense for DDraw-only games (working with plain bitmaps).
Resolution scaling is only for things rendered "in 3D", of triangles.
teleguy wrote:I get a generic Windows error message:
"Engine stopped working
Problem details:
Fault Event Name: BEX
.
.
.
Fault Module: Stack […]
Show full quote
Dege wrote:I've done a quick test with Drakan Demo and Diablo II 1.14b (Glide, forced to 1280x1024) but both works fine with 2.51. 😕
I'll try them on an AMD too, to see what happens.
Edit: (BTW, crash on Drakan Demo means driver crash? I remember having one with some old nVidia driver.)
I get a generic Windows error message:
"Engine stopped working
Problem details:
Fault Event Name: BEX
.
.
.
Fault Module: Stackhash_3487"
etc.
I've tried it on my AMD and it worked.
However, BEX is "Buffer overflow Exception". It's typically comes from debug version of C-runtimes.
I doubt the game demo links to such a MSV CRT, so
- either DDraw enumerates too many resolutions to the game, causing stack overflow (but not in my case, as I have a relatively few resolutions without any additional super/custom resolutions),
- or you may have enabled some options in very tech developer-stuffs, like AppVerifier or GlobalFlags which can force "debug circumstances" to apps (I doubt it, too)
Glurak wrote:I testet a little with Diablo 1 it works until the Intro ends then the game goes in the Taskbar (music is stil running but the game cant go fullscreen)
Edit: i testet more after i disable the Disable alt-Enter to toggle Screen status option the games works extremly fine. with one exception the menüs are only windows in low resolution dont know why ^^
Diablo1 has issues with dgVoodoo, I wrote about it earlier. Now it can only be played in windowed mode because of some DXGI (D3D11) limitiations, and there is a graphical glitch somewhere AFAIR.
xcomcmdr wrote:About water rendition problems with MGS and HW acceleration turned on :
- Intel HD4000 : no problem (Windows 10, patch + dgVoodo […]
Show full quote
About water rendition problems with MGS and HW acceleration turned on :
- Intel HD4000 : no problem (Windows 10, patch + dgVoodoo combo)
- GeForce 4 Ti4200 : no problem (on Windows 98SE, and Windows XP. Only the modified executable was used)
- MSI GeForce GTX 950 OC : no problem (Windows 10, patch + dgVoodoo combo)
It's strange, because when I last checked, it was wrong for me (GF GTS 450). But when I check again after my last attempt (:-D) with a newer version of dgVoodoo, it was fine again.
xcomcmdr wrote:That sounds awesome ! Thanks a lot for your dedication.
In fact, I'd like to offer more than thanks. Is there a way to support the project by giving money ? (couldn't find any 'donate' button on the official website
Ah, thanks a lot for that. Yes, currently there is no donate button, I think I'll set up a paypal account for that, somehow. 😁
De-M-oN wrote:Soooo now I tried NFS 4 with it and I'm impressed. That z-fighting headlights is indeed gone 😮
You're a god. Thank you!!
Sharp fonts as well. I've set the wrapper to 2560x1600 with 8x MSAA and the game to 1600x1200. Looks awesome. 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.
Thanks, but rather let's say I just spent too many time on both sides of DirectX: user and driver sides, and so got some experiences. 😁
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.
-------------
Meanwhile I did some experiment with supporting 10.0 level output and whipped up an experimental version, with which I played DX8 games at 10.0. But, I have mixed feelings about that:
* 1. On the one part, it revealed that there are number of limitations, one of is very basic, in theory. These are:
- Lack of mipmapping in Glide ( 😒 )
- Lack of mipmapping in DX(<=7) in some (rare) cases (tolerable)
- Missing fixed function vertex tweening support in DX8 (tolerable, as I didn't encounter any game using it. Anyway, this could be solved, I just don't want to rewrite basic rendering codes because of that)
- D3DCompiler is always needed (because I don't want to include precompiled shaders for 10.0; wouldn't make sense, concerning performance, but it's totally tolerable)
- No Phong shading available (tolerable, as it didn't prove to be very useful in practice + performance issues again, it's very computation-consuming)
- Multisampled depthStencil surfaces cannot be used as a shader input, so blitting/locking depth buffers when AA is forced would give an error (tolerable as only a few (1 or 2) games do that)
- Cubetextures cannot be viewed and used as 2D texture arrays. This one is very basic, but, it affects rare cases too, after all: when a game copies data from one cube texture to another with format conversion, or from one that was rendered by 3D. It seems also tolerable, since majority of the games don't do such operations.
(I hope no more to come...)
*2. On the other hand, despite the limitations look too 'deal breaker', it'd be a pity if a game not requiring much gpu resources couldn't be played on a 10.0 hw just because of limitations that don't even affect the game. I'm speaking of DX here, as lack of mipmapping in Glide is too serious. It all would only be "recommended" for wrapping DX, for last-resort cases.
So, I'm still pondering on what to do: ditch the idea as it is, or support 10.0 with the limitations above, including that I don't care of potential rendering glitches and error messages in games, except for crashes in dgVoodoo code.