Tip:
In SC1 if you set the game exe to 640x480 and in DgVooDoo you force the resolution (not to high) the coronas around lights will not flicker anymore.(2.54 till 2.6 something version of DgVooDoo comes in handy here-> doesnt shift the effects ).
Beware some levels will not look right. Oil Ref level, water will be broken. You can play this level with force res off and set the res in the game or 13ag widescreen.

daniel_u wrote on 2020-12-25, 22:09:

Tip:
In SC1 if you set the game exe to 640x480 and in DgVooDoo you force the resolution (not to high) the coronas around lights will not flicker anymore.(2.54 till 2.6 something version of DgVooDoo comes in handy here-> doesnt shift the effects ).
Beware some levels will not look right. Oil Ref level, water will be broken. You can play this level with force res off and set the res in the game or 13ag widescreen.

when i use this setting the mouse stuck in the corner .... is there any suggestion ?

hishamerrish wrote on 2020-12-26, 07:10:

daniel_u wrote on 2020-12-25, 22:09:

Tip:
In SC1 if you set the game exe to 640x480 and in DgVooDoo you force the resolution (not to high) the coronas around lights will not flicker anymore.(2.54 till 2.6 something version of DgVooDoo comes in handy here-> doesnt shift the effects ).
Beware some levels will not look right. Oil Ref level, water will be broken. You can play this level with force res off and set the res in the game or 13ag widescreen.

when i use this setting the mouse stuck in the corner .... is there any suggestion ?

Uncheck that option in DgvooDoo, "capture mouse" or something, i think.

daniel_u wrote on 2020-12-26, 09:17:

hishamerrish wrote on 2020-12-26, 07:10:

daniel_u wrote on 2020-12-25, 22:09:

Tip:
In SC1 if you set the game exe to 640x480 and in DgVooDoo you force the resolution (not to high) the coronas around lights will not flicker anymore.(2.54 till 2.6 something version of DgVooDoo comes in handy here-> doesnt shift the effects ).
Beware some levels will not look right. Oil Ref level, water will be broken. You can play this level with force res off and set the res in the game or 13ag widescreen.

when i use this setting the mouse stuck in the corner .... is there any suggestion ?

Uncheck that option in DgvooDoo, "" or something, i think.

yes capture mouse must be unchecked ...

Splinter cell 2 HD texture has some bugs too 🙁
shadows not render correctly and some places the shadow and the light are a little weak
the light not rendering at the start of the Paris mission
the bloom has been lowered you can see that from the light on the Sam back ....

SC2 ETexRenderer vs SC1 ETexRenderer

I finally had a chance to remove the specular component of the shaders that cause the shiny texture glitch for SC1, for the SD texture files.
Replace the textures in the texture folder.(you might want to back them up first)

Thanks man!

daniel_u wrote on 2021-01-23, 20:08:

I finally had a chance to remove the specular component of the shaders that cause the shiny texture glitch for SC1, for the SD texture files.
Replace the textures in the texture folder.(you might want to back them up first)

THANK YOU SO MUCH

hishamerrish wrote on 2020-12-10, 00:02:

Hi dege .... there is an issue with the light rendering in SCPT in one place as far as i know it is rendering fine with an old […]
Show full quote

Hi dege ....
there is an issue with the light rendering in SCPT in one place as far as i know
it is rendering fine with an old version only (d3d8_0_05)
I tried many version of djvoodoo2 but no luck
if it is possible to be fixed that will be great
and the bloom is not broken in the old version
thanks a lot 😀
dgvoodo2 2.73 v
v d3d8_0_05

Ok, this was indeed a wrapper issue, and I fixed it.

Bloom effect: as I guessed previously, it's "broken" (more on that immediately) because of the modification of some internal scaling calculation in the 2.6.x series. If I experimentally put back the old version then bloom is right with forced resolution too. However, it breaks other things like the fading screen from the load-game menu into the actual game.
So, it may sound stupid, but the present scaling calc-formulas are the correct in dgVoodoo, even if the bloom is broken. Both by thinking into it as a theory and a lot of practical case (games fixed).
SCPT's 2d bloom renderer is not compatible with the scaling method and could only be "fixed" on the game side (but actually I didn't examin how easy would that be).
The bug of the old version combined with the method of bloom renderer extinguished each other, that's why it was "good".

Heat haze: It's not an easy case. Heat haze is rendered as a fullscreen 2d mesh consisting of quads with the scene as a 2d image wrapped to it. Mesh points are perturbated randomly, in the area where the fire is, to alter from their standard position by 3-4 (or so) pixels, giving the sense of the heat-distorted image.
Each screen-quad is 16x16 pixels, independently on the resolution. So, in 640x480 it's a grid with (640/16+1)*(480/16+1) vertices.
That's why it works nicely in 640x480 but not in 4K. 16x16 pixels with a 3-4 pixels perturbation in 4K are so tiny that the effect hardly can be seen.
I did a little experiment to make the renderer always do its mesh calculations by the grid size for the 640x480 case independently of the current game-resolution, but unfortunately it all proved to be hard to separate from other parts of the rendering. 🙁 I'm not saying it's impossible but hard.

Btw, nice work with the textures!!!

Dege wrote on 2021-02-04, 19:14:

Ok, this was indeed a wrapper issue, and I fixed it.

Great news. Many thanks.

Dege wrote on 2021-02-04, 19:14:

Btw, nice work with the textures!!!

Thanks and ...Thank You for your commitment and help.

Now, about scaling issues. How about creating some scaling profiles for the wrapper?

A dropdown I mean, like the simulated graphics adapters ? If you plan with care and use some design patterns(adapter pattern 😀 ) you can keep your core logic separated from these special cases. Work on these only when you see fit.
Not sure how design patterns affects graphics programming concepts, though 😁
This will be the best decision i think considering there might be other games with scaling issues. Once kinda ready there will not be the need for two versions.

Now regarding SCPT and SC we are in limbo. 😀 There is a version that 'works' and there is a version that is correct + some extra fixes.
Is there a posbility that you can post here and only just one time, a 2.6x version(latest that doesnt have the right scaling changes ) with the fix you did above? Unofficial.

It seems old splinter cell games have been investigated enough. There is a lot of info here that somebody could pick it ip and create a custom d3d8.dll only for these games. (this could be a solution but i will not even propose it 😁)
I know keeping two versions is not a solution but if nothing new will happen maybe there will not be a need anymore. You kinda fixed all that was possibile without patching the game.
Except color of the light(which i currently focus on, to patch, looking for those vertex shaders constants that give out the color ) there is nothing else.

Also one question related to SCPT color of the light: when you debug, are you able to tell from what file of the game, static data is coming?. Pinpoiting without debugging is madness.
Many years ago you said RGB color values is coming affected from/by some constants. I picked up on that and I believe i can change the color of the light in SCPT or at least show some garbage on the screan. 🤣
(
here is your (g)old(en) post :
Re: dgVoodoo 2 for DirectX 11
c[87] = (0.003922, 0.003081, 0.001892, 1.000000) -> this has been on my mind for some time now
)
Thanks again, Dege.

PS: Will update my main post to reflect your findings

I don't like the idea of scaling profiles because in fact the pre-2.6.x scaling doesn't work well in general, but only for Splinter Cell. Other than that it just causes various artifacts. It doesn't even work perfectly for SC itself because it breaks other 2d things, like the fading screen, as I mentioned.
Bloom in SC is a typical thing that could be "fixed" for scaling better on the application side instead of struggling inside the wrapper (but maybe it's complicated like heat haze, I don't know).

I'll look at it along with the light a bit later (I cannot remember by heart where those values came from).

Dege wrote on 2021-02-05, 20:03:

I don't like the idea of scaling profiles because in fact the pre-2.6.x scaling doesn't work well in general, but only for Splinter Cell. It doesn't even work perfectly for SC itself because it breaks other 2d things, like the fading screen, as I mentioned.

I didnt saw(i may have missed it) any issues in 2.6 maybe in 2.7 with pre 2.6 scaling code. But i understand. Thanks.

Dege wrote on 2021-02-05, 20:03:

I'll look at it along with the light a bit later (I cannot remember by heart where those values came from).

No hurry, i will give you a save game location when i got the chance to simplify the job. 😁.
Also is it possbile to also a release a 2.6x d3d8.dll (old scaling code)version with the shadow fix for SCPT? Again when you have the time. 😁

Thanks Dege for your answers and help. I appreciate it.

Edit:
I thought i had it... still off..changed it from yellow to white...i need to find the light beam of a lamp. Wrong object. Oh well....

Dege wrote on 2021-02-04, 19:14:

Ok, this was indeed a wrapper issue, and I fixed it. […]
Show full quote

hishamerrish wrote on 2020-12-10, 00:02:

Hi dege .... there is an issue with the light rendering in SCPT in one place as far as i know it is rendering fine with an old […]
Show full quote

Hi dege ....
there is an issue with the light rendering in SCPT in one place as far as i know
it is rendering fine with an old version only (d3d8_0_05)
I tried many version of djvoodoo2 but no luck
if it is possible to be fixed that will be great
and the bloom is not broken in the old version
thanks a lot 😀
dgvoodo2 2.73 v
v d3d8_0_05

Ok, this was indeed a wrapper issue, and I fixed it.

Bloom effect: as I guessed previously, it's "broken" (more on that immediately) because of the modification of some internal scaling calculation in the 2.6.x series. If I experimentally put back the old version then bloom is right with forced resolution too. However, it breaks other things like the fading screen from the load-game menu into the actual game.
So, it may sound stupid, but the present scaling calc-formulas are the correct in dgVoodoo, even if the bloom is broken. Both by thinking into it as a theory and a lot of practical case (games fixed).
SCPT's 2d bloom renderer is not compatible with the scaling method and could only be "fixed" on the game side (but actually I didn't examin how easy would that be).
The bug of the old version combined with the method of bloom renderer extinguished each other, that's why it was "good".

Heat haze: It's not an easy case. Heat haze is rendered as a fullscreen 2d mesh consisting of quads with the scene as a 2d image wrapped to it. Mesh points are perturbated randomly, in the area where the fire is, to alter from their standard position by 3-4 (or so) pixels, giving the sense of the heat-distorted image.
Each screen-quad is 16x16 pixels, independently on the resolution. So, in 640x480 it's a grid with (640/16+1)*(480/16+1) vertices.
That's why it works nicely in 640x480 but not in 4K. 16x16 pixels with a 3-4 pixels perturbation in 4K are so tiny that the effect hardly can be seen.
I did a little experiment to make the renderer always do its mesh calculations by the grid size for the 640x480 case independently of the current game-resolution, but unfortunately it all proved to be hard to separate from other parts of the rendering. 🙁 I'm not saying it's impossible but hard.

Btw, nice work with the textures!!!

Thank you so much for your time Dege

daniel_u wrote on 2021-02-06, 12:22:

Also is it possbile to also a release a 2.6x d3d8.dll (old scaling code)version with the shadow fix for SCPT? Again when you have the time. 😁

You mean the newly fixed shadow bug in the Jerusalem level?

Dege wrote on 2021-02-09, 17:56:

daniel_u wrote on 2021-02-06, 12:22:

Also is it possbile to also a release a 2.6x d3d8.dll (old scaling code)version with the shadow fix for SCPT? Again when you have the time. 😁

You mean the newly fixed shadow bug in the Jerusalem level?

Yes sir. There might not be another chance to do it. Code differences could become too large and be incompatible in the future and the effort wil not be worth it.(also i dont think there will other issues. You owned quite nicely the shadow buffers 😉 )
Even if 2.6x has issues ,in general, for SC1 and 2 it works nice. It will mean a big deal for the comunity that at least there is one way to experience these games 99% glitch free.(DX 11 is the new dx9 😁 )

If there is a perfomance issues they can always use latest.

Thank you.

A quick question: does 2.6x work better in any way (apart from the bloom scaling issue) than the latest (2.72) version?
Because if it doesn't (I hope) then it'd be better to release that special version from the 2.7x code repo.

Dege wrote on 2021-02-12, 20:30:

A quick question: does 2.6x work better in any way (apart from the bloom scaling issue) than the latest (2.72) version?
Because if it doesn't (I hope) then it'd be better to release that special version from the 2.7x code repo.

From what i know, for SC, 2.6x is not better than 2.7 when the end user doesnt force the resolution.
The last version actually(doesnt matter if it's 2.6 or 2.7 just without those bloom/scaling issues) + latest fix for the shadow buffers(SC2).

Sorry for being lazy... but can someone please give me a quick rundown of current best practices for playing SC1 with dgVoodoo2?

I installed ThirteenAG's widescreen fix, and manually copied the latest DLLs (2.73) to the game's folder. It's working, but got a few questions left:

- Keep the dgVoodoo.conf from the widescreen fix, or replace it by latest file (2.73)?
- Should I use the PS3 textures?
- What about extra downloads, like a few posts up here, any more of those?

daniel_u wrote on 2021-01-23, 20:08:

I finally had a chance to remove the specular component of the shaders that cause the shiny texture glitch for SC1, for the SD texture files.
Replace the textures in the texture folder.(you might want to back them up first)

1) Replace it, of course
2) No
3) Fixes for the original textures