VOGONS


dgVoodoo 2 for DirectX 11

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 60 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Well, it's not. It crashes with Project64... 😁 😵

Let something be untested and you can be sure it won't work... I hate software industry. 😊

Anyway, when that crash is fixed, I still get another one with certain ROMs. Seems Glide64 calls a missing function belonging to an extension. So, that's why Napalm is needed here, with full support (I guess Glide64 was designed for Napalm only).

It's a neverending story without a happyend. 😊

Reply 62 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Yes...

But T-buffering is a 3Dfx techinque for antialiasing on Voodoo 4&5 (2x, 4x, 8x, depending on the number of chips in SLI).
Also, as many other things, it could be forced through registry. I can't recall though that when it's used, it can be enabled/disabled during a Glide session through the API (I think it's needed for motion blur). Anyway, I'm planning to include it in into the Napalm build. (The things is that all available extensions should be implemented or else it worth nothing. Many of them are only for the 3Dfx OpenGL (1.1) driver if I got it right. But unfortunately I'm not sure if it can be done completely, time will show...)

ps: I wrote in the readme that I didn't want to get back into the Glide businness. Now I'm realizing that I have already been got in... 😵 😵 😁

Reply 64 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

😀 Yes, something like that...! Or, I pushed myself back.

Further investigating the 3Dfx driver, I got to the following:
Original OpenGL driver is not a pure OpenGL->Glide3 Napalm wrapper, unfortunately (as for Windows). OpenGL uses the SURFACE extension. The problem is that surface implementation is only partial in Glide3, creating and releasing surfaces is implemented via DirectDraw. So that, surface extension functions operate on ddraw surfaces in (Win) Glide3. It's something like that 3Dfx display driver has different components (GDI, DDraw, Glide, OpenGL) but the boundaries between run on bad places. 😀 (Well, actually it's not true. Obviously they wanted to avoid duplicating surface management codes. It's is the same in nowadays display drivers, OpenGL renders on DDraw surfaces on Windows.)

So that, since 3Dfx OpenGL driver depends on its own ddraw and glide3 components, it makes it impossible to use it via a Glide wrapper. Unless a mini-ddraw -> D3D11 wrapper is also provided... 😁

But it doesn't worth the effort. Writing another component just to have an OpenGL 1.1 -> Glide3 (and mini ddraw) -> D3D11 wrapping? It makes no sense but programmatically would be nice... 😁

Sorry for the lot of technical blabla. I just wanted to say that OpenGL->Glide3 wrapper won't work.

Reply 66 of 3949, by notindeed

User metadata
Rank Newbie
Rank
Newbie

Hmm i tried this some time ago with hitman 1, but it doesn't seem to get past the compatability checks 🙁
It's sad, because basically no glide wrappers support glide3.
Ideally i would like a opengl glide wrapper that supports it but i don't know of one or at least any that will work with hitman 1.

I tried nglide with it but that has a lot of issues, mainly with text scaling - so basically you can't read anything! Also the maps get broken.
Using native directx or opengl in game is problematic you see - it causes the fog to render incorrectly (not scaling smoothly) and also there are terrain clipping issues not present in 3dfx mode.

Also, one good side effect of a wrapper is i can tell the game it is rendering in a lower resolution but then actually force to render it in a higher one. This helps to solve huge issues with interface scaling being so tiny at high res.

Any suggestions?

Reply 68 of 3949, by notindeed

User metadata
Rank Newbie
Rank
Newbie

Thanks. I'm not sure how successful it would be with font scaling since I imagine it would have the same font scaling issues that directx would, but maybe it would force to directwrite rather than gdi... (knowing microsoft i doubt it!). Might be lucky though! If zeckenack's glide to opengl would get past the security check then hopefully that would be ok.

Here is an example of the fogging issue: http://www.hitmanforum.com/index.php/topic/18 … 0p/#entry347051
For me, it looks similar to the fogging issues thief 2 had after a time (though it was fixed when ati drivers released a fix for gta3 fogging).

Of course I don't know whether it would ever have worked correctly in d3d or opengl modes with old cards or drivers, but the fact that it does work with the nglide wrapper would suggest it might have.
I haven't got screenshots of the other issues but I might have a video somewhere.

In some ways, it would be good if there were some kind of "legacy directx" and "legacy opengl" wrappers that kind of wrapped older, deprecated or changed directx and opengl calls to new ones and kind of fixed up things, and also allowed you to force higher resolutions, so the game thinks it is running at a lower res for helping with interface scaling.
Sadly I don't know of any such projects.

Reply 69 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

I've tried Hitman with the wrapper. There were some errors in the vertex shader (I think this game is the first one using clip space coord system I tried).

But... Having those fixed, fog is still missing. It's the same as on the screenshot in the forum you posted about. I debugged it all the evening but still don't understand why fog should show up at all. But I can't imagine that this looked thus on a 3Dfx card.[/img]

In some ways, it would be good if there were some kind of "legacy directx" and "legacy opengl" wrappers that kind of wrapped older, deprecated or changed directx and opengl calls to new ones and kind of fixed up things, and also allowed you to force higher resolutions, so the game thinks it is running at a lower res for helping with interface scaling.
Sadly I don't know of any such projects.

I think wrapping old(er) D3D interfaces is already done by MS itself or the driver writers. For example, Vista's new WDDM display driver model does not allow DDIs older than DDI9 (display driver interface). So, MS had to wrap pre-DX9 interfaces to DDI9 at least. What is more, as GPUs are merely evolving into a programmable machine doing general parallel floating point operations, native support of old, fixed function functionality (like fog, alpha testing, texture stages, and so on) may be also missing on the those GPUs. So, if an old feature is not supported natively then the complete fixed function stage must be silently replaced with a shader equivalent somewhere in the driver, or in the MS directx runtime. It means that an old bug with old GPUs may have been fixed on new GPUs just by doing the new, wrapped way.

Attachments

  • Filename
    Hitman1.png
    File size
    883.7 KiB
    Downloads
    50 downloads
    File license
    Fair use/fair dealing exception

Reply 70 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Ok, got it... forget my previous post.
According to the original driver triangle setup code, I realized what the problem was...

Now it looks fine.

Attachments

  • Filename
    Hitman1_fog.png
    File size
    718.37 KiB
    Downloads
    52 downloads
    File license
    Fair use/fair dealing exception

Reply 71 of 3949, by notindeed

User metadata
Rank Newbie
Rank
Newbie

Hmm that certainly looks correct!

I had a video of the clipping issue but i cannot seem to find it. It is corrected by nglide, but an issue in d3d and opengl modes.

To see the issue easily, go to the hotel level (Mr Wulf level) and go in the main doors, then head all the way to the right and look out of the windows onto the street. Instead of seeing the pavement properly, you see lots of clipping strange mess issues in d3d and opengl.

Hmm, can you try setting the in game resolution to 640*480 and then forcing a higher resolution (say 1280 * 960, exactly double) in your wrapper and seeing if that breaks the hud and 2d interface? As in nglide it would, that being one of the main issues.
Another problem with nglide is that for some reason texture filtering and anti-aliasing would not work, even though it said it "forced these things". It also appeared to be 16bit rather than 32bit forced - or at least the lighting around light sources and certain areas was a lot more "rainbow" than in opengl / direct3d mode.

Hope any of this information helps.
If anyone knows of any lightweight video software i will try and make the videos again if that would help. The only problem is my computer is 10 years old of so, so it has be be quite light for it to cope!

Reply 72 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

To see the issue easily, go to the hotel level (Mr Wulf level) and go in the main doors, then head all the way to the right and look out of the windows onto the street. Instead of seeing the pavement properly,

Sorry, I don't know this game, but downloaded a savegame containig all "milestones", I think. Do you mean the Gallárd hotel? Maybe it's a silly question as there may be no other hotels in the game, but there there is the receptionist to the right at the main entry, and there is no window there.
Anyway, if I look out of a window elsewhere then everything is fine even with D3D for me.

As for forced resolutions, the only issue is with the text. Even if 640*480 is forced to 1280*960, text is a bit hard to read (that's why forcing is unhealthy), but everything else is fine. 2D, HUD, map, they aren't broken. A sad thing is that it could be played in 1280*1024 without forcing resolution as the game setup supports it natively, but the 3Dfx renderer initializes glide with a max of 1024*768, no matter if I set the resolution to a higher one... 😵

It also appeared to be 16bit rather than 32bit forced - or at least the lighting around light sources and certain areas was a lot more "rainbow" than in opengl / direct3d mode.

It's because Glide supports only 16 bit textures. I suppose the 3Dfx renderer scales down texture quality to 16 bit when needed, that's why you can see texture quality loss here and there in the game. It cannot be helped - D3D and OGL are better in this respect compared to Glide. 😐

Reply 73 of 3949, by notindeed

User metadata
Rank Newbie
Rank
Newbie

Yes, that is the correct level! The windows i am meaning are to the far right - go past the reception, and through the main doors into the corridor with the guest rooms. The windows are in here. You can also go to the end of the corridor, and in peoples rooms themselves too to see the effect.

Here is the location: http://img163.imageshack.us/img163/4601/maplocation.png
Here is the clipping issue (in d3d and ogl): http://img585.imageshack.us/img585/2513/clippingc.jpg
When you move the view, it changes dynamically.
Here is how it should be, with nglide: http://img13.imageshack.us/img13/3877/properclipping.png

Just for clarification, here is the rainbow lighting i was refering to:
http://img839.imageshack.us/img839/7012/rainbowlighting.png

And text resize corruption using nglide and forcing a higher resolution:
http://img824.imageshack.us/img824/3166/textcorruption1.png
http://img844.imageshack.us/img844/9381/textcorruption2.png

Text corruption can also be seen on the hud of the other nglide shots! It also effects icons and the map too.

You are correct that in opengl and d3d you can run 1280*1024. (strangely there is no 1280*960 choice, which would be actual 4:3 instead of 5:4). The problem with this is that the interface does not scale. Therefore everything is very small and hard to read.

With nglide, if you tell the game it is running at 640*480 and then run at 1280*960 (or any other resolution apart from the one specified in-game) then the text corrupts like shown above. The fact that 1280*960 is exactly double means it should scale fine, and result in a much more readable interface. So something with the scaling is not so good. I assumed it was because nglide is a d3d based glide wrapper, and thought maybe an opengl one would do it better (considering font scaling with ms libraries seems rather awful on non-directwrite applications).

Another solution would be an opengl wrapper for opengl that the only thing it wraps is the resolution so that you can "force" resolutions outside of the game, simply providing a way to kind of "fake" interface scaling support.
Or does what i say sound mad?

Sorry some of the pictures are rather big.... ms paint on xp is not the best for saving images!

Thanks for your time!

Reply 74 of 3949, by Gamecollector

User metadata
Rank Oldbie
Rank
Oldbie

NGlide 1.01 is using wrong pixel center for re-sizer. So - only "Screen Resolution=by app (default)" is working correctly. Must be fixed in the next version...

Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).

Reply 75 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Yes, that is the correct level! The windows i am meaning are to the far right - go past the reception, and through the main doors into the corridor with the guest rooms. The windows are in here. You can also go to the end of the corridor, and in peoples rooms themselves too to see the effect.

Here is the location: http://img163.imageshack.us/img163/4601/maplocation.png
Here is the clipping issue (in d3d and ogl): http://img585.imageshack.us/img585/2513/clippingc.jpg

Well, thanks, I will visit that window! 😀

Altough I didn't check it myself, it seems there is no issues with Glide & nGlide.
The text looks the same with dgVoodoo (with 640*480 scaled to 1280*960) even with unforced texture filtering and antialiasing. 🙁
However I cannot explain this special case at the moment, maybe it's the pixel center, as GameCollector said. Probably pixel center is at .5 in Glide and it should be corrected when scaling is active (I can't remember).

As for the rainbow textures, I still say it's because of 16 bit textures, it's not an issue.

Another solution would be an opengl wrapper for opengl that the only thing it wraps is the resolution so that you can "force" resolutions outside of the game, simply providing a way to kind of "fake" interface scaling support.
Or does what i say sound mad?

I think resolution scaling couldn't be done for neither DirectX nor OpenGL (in general). The problem is that these APIs support offscreen buffers which can be copied to the rendering buffer by either texturing or raw copy. If raw copy is used, the offscreen size has to be scaled too. But, how would a wrapper know that what purpose is an offscreen is allocated for? It could be indeterminable. The only case is the classic OpenGL 1.x that does not support frame buffers (offscreens) but only 2-3 rendering buffers with a depth buffer, as Glide does.

Reply 76 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Well, thanks, I will visit that window!

I visited the window. Indeed, it has some kind of clipping issue with D3D. Must be a bug in the D3D renderer. However, with 3Dfx it's OK.

The fact that 1280*960 is exactly double means it should scale fine, and result in a much more readable interface. So something with the scaling is not so good.

Well, I thought the same at first time. The bad news is that it's not true. Pixel center is at .5 in pixel space in Glide. If a coordinate of (x.5, y.5) is scaled by 2 then the resultant coord falls into the middle between two neighbor pixels. It's not good, because the rasterizer uses different texture coordinates for the second case when rendering the next pixel.
Just think into it: if a vertex (x.5, y.5) is used for rasterizing a pixel, and given a texcoord (s,t) for that vertex, then the rasterizer uses exactly (s,t) for rendering that pixel, since (x.5, y.5) is a pixel center. If you scale that up by 2, then a half pixel distance is needed to reach the next pixel center, but then (s,t) gets slightly interpolated too. So that texel->pixel mapping gets wrong.
I did an experiment with some "smart scaling" by offseting pixel centers, but then realized that it just transformed this problem into another wrong case: vertices between 2 neighbor pixel get scaled onto pixel centers, and the same applies I wrote above.

So, scaling seems evident for the first look, but it's not at all. In fact, it cannot be solved. The application has to know the exact mapping from clip space to pixel space to apply accurate texel->pixel mapping. If that mapping is altered by silent resolution forcing then the application uses bad assumptions. 🙁

JetFighter III is fixed. At least some good news to speak about. 😀

Reply 77 of 3949, by notindeed

User metadata
Rank Newbie
Rank
Newbie

As for the rainbow textures, I still say it's because of 16 bit textures, it's not an issue.

Hmm okay. It's just confusing for me as it is part of lighting, not the texture, so i don't really understand 😖 Especially since nglide was adamant it could run proper 32bit (mind you, i can't even get it's texture filtering, anti aliasing or anything to work!).
So yer, i'm not sure i understand!

I visited the window. Indeed, it has some kind of clipping issue with D3D. Must be a bug in the D3D renderer. However, with 3Dfx it's OK.

Yer. Strange how it is for opengl too.
Mind you it's the same for the fogging. I struggle to believe that all these games had fogging issues (with d3d / ogl) on graphics cards when they were released? So I guess newer drivers break the games? Or is it probably newer hardware too? Or windows cos of direct x implementations?

(Basically what i am asking is if i went back to windows me or 98 and put in old drivers for a 9600 pro or something, is it possible it would fix things, or is this unlikely!).

Hmm i kind of understood about your pixel centre stuff (though not exactly 😊 ), but yes, that's unfortunate! It seems to usually be the way that something that seems like it should be nice and possible then is difficult and not so! heehee.

I think resolution scaling couldn't be done for neither DirectX nor OpenGL (in general). The problem is that these APIs support offscreen buffers which can be copied to the rendering buffer by either texturing or raw copy. If raw copy is used, the offscreen size has to be scaled too. But, how would a wrapper know that what purpose is an offscreen is allocated for? It could be indeterminable. The only case is the classic OpenGL 1.x that does not support frame buffers (offscreens) but only 2-3 rendering buffers with a depth buffer, as Glide does.

This is probably very ignorant of me, but say if you just scaled the offscreen buffer too, wouldn't that be okay? Sure you would also be scaling the textures as you say, but that wouldn't necessarily be a problem ?
Or would it then try and read those textures back in using only the coordinates of the original size, meaning you only get part of the texture?

Reply 78 of 3949, by arablizzard2413

User metadata
Rank Newbie
Rank
Newbie

Any update on the referenced memory could not be read crash in King's Quest Mask of Eternity that started in v2.15 and happens every 5-10 minutes?

Attachments

  • Filename
    dgvoodoo2_15-crash.png
    File size
    212.96 KiB
    Downloads
    20 downloads
    File license
    Fair use/fair dealing exception

Reply 79 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Hmm i kind of understood about your pixel centre stuff (though not exactly ),

Yes, a blueprint or something like that should have been attached. 😀

This is probably very ignorant of me, but say if you just scaled the offscreen buffer too, wouldn't that be okay?

You are right. Probably scaling every offscreen would solve the problem, but that's a brute force solution.

Sure you would also be scaling the textures as you say, but that wouldn't necessarily be a problem ?
Or would it then try and read those textures back in using only the coordinates of the original size, meaning you only get part of the texture?

No, texture coordinates are independent on texture size, so the same part of them would be used as without scaling. The problem would come from scaling the texture bitmap. Doing scaling in any way, nearest point or bilinear, would corrupt the texel->pixel mapping, I think.