VOGONS


dgVoodoo Splinter Cell Games

Topic actions

First post, by daniel_u

User metadata
Rank Member
Rank
Member

Bugs related to Splinter Cell games using DgVooDoo here.

Last edited by daniel_u on 2017-01-10, 15:30. Edited 1 time in total.

Reply 1 of 232, by daniel_u

User metadata
Rank Member
Rank
Member

**DO NOT PLAY THE GAMES WITH PS3 HD TEXTURES. Some shadows will not be rendered anymore.
**DgVooDoo 2.7x down to 2.6x something:
1. Forcing the resolutions will pixelate and shift some effects. I use 2.54 which only pixelate slightly the effects. The higher the res the more pixelated the effect will be.

For SC 1 we have(game bugs):

1.Shiny texture bug
Bug
c1G3fAZ.png
Normal
NJDdaUy.png
(CIA. Defense ministry). I managed to remove the specular reflections from the shaders. No more glitches but also no more (broken anyway)reflections, only for the specific areas. See attachments below.

2.Shadows and light appear/disappear based on mouse movement or distance.(game design not really a bug)
3.Missing shadows compared to the XBOX version. (Ubisoft sucks sometimes.)
4.Coronos of lights flicker. For Win 10 set the the exe to always play in 640x480. Now in DgVoodoo , Force resolution to 1080p or something. Setting to high will break certain levels and for sure Oil Refinery(see below)

Advices:
1.Play the game with res forcing where possbile(2.54). (Water in Oil Refinery level might look strange. Maybe some other levels)For some , some performance issues might happen.
2.Use 4800 preset for classic light

cX3FnXZ.png

Use DgVoodoo-5700 Ultra for soft light
1NMe1Pq.png

Notes:
1.Game is dependent on the monitor refresh rate. 30 fps is the original. Going higher will cause some elements to 'move' too fast(light beams)

For SC 2 we have:
1.Color of the light is wrong.
DEpVOkc.png
2. Crosshair in the middle of the screen, flashing. (Fix: alt tab out the game and go back in, or user bordeless gaming app, remove cursor option)
3.There should be a light coming out of the door but is not, as per Hishamerrish . This is definitely an wrapper issue:
ZYCD0gb.png

Here how it should look:

atTClSP.png

To play the game with all the effects: use 2.54 version with a resolution which doesnt pixelate the bloom,480p-1080p resolution with full 8x MSAA.(might generate other issues)
--to be updated

Game Bugs:
1.Heat haze is resolution dependent.
Here's how it looks on 640x480(distorted image of the wood in the background). On higher res the effect will be less/small visible. The higher the res the less/small intense the effect will be. The heat haze on higher res will be at the bottom where the fire can barely be visible.
lyWFOaP.png
2.Missing bloom and flickering of the corona of lights..(windows,exterior button lights of elevator/lift, candles in the first level, etc)
CEU5Jso.jpg
P8JETCZ.jpg
Because of the high resolution some effects are small. Use 480p or a litlle higher with MSAA to have them all visible and rendered ok.
Forcing the game witth DgVooDoo latest(2.7x) ,to a higher resolution 'fixes'(wrapper might ignore something and game thinks is still renders the heat haze in 480p) the heat haze but breaks the bloom(it becomes pixelated and shifted to the right a bit).
hPnJbRc.png
For 2.54 seems it is better:(fixes the flickering because of the higher res, no matter the the version)
HQb4Jad.png
--to be updated

Notes:
1.Game is dependent on the monitor refresh rate. 30 fps is the original. Going higher will cause some elements to 'move' too fast(light beams)

Recommended version(imho) for SC 2 : 2.54 .
Recommended version(imho) for SC 1 : use 2.54 atm . Use latest if you have performance problems.

Attachments

  • Filename
    2-1_CIA_tex.rar
    File size
    3.08 MiB
    Downloads
    158 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    1_2_Def_Ministry_tex.rar
    File size
    2.39 MiB
    Downloads
    141 downloads
    File license
    Fair use/fair dealing exception
Last edited by daniel_u on 2021-01-23, 20:16. Edited 70 times in total.

Reply 2 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Reply 3 of 232, by daniel_u

User metadata
Rank Member
Rank
Member
TomArrow wrote:
Hello Dege and others, […]
Show full quote

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .😀
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.

Reply 4 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie
daniel_u wrote:
Hi, I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .:) The xbox version al […]
Show full quote
TomArrow wrote:
Hello Dege and others, […]
Show full quote

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .😀
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.

Heya, thanks for the tip. Unfortunately, the code only uses this value to inject it into memory, probably altering a variable in the algorithm, so it doesn't expose the algorithm itself.

If the algorithm is DirectX-based, my naive thinking would suggest that it could be 'grabbed' with something similar to a 3D ripper. That is, the instructions could be seen. But that would probably be a pain in the ass to filter out the correct ones from the ones that are unrelated, depending on how the data is arranged.

But I'm a newbie either way. I figured I'd ask here because someone might know a simple answer that may take me weeks to figure out.

Oh and I'm totally fine with the PC version. Xbox would be way too much work to figure out is my best guess.

Reply 5 of 232, by daniel_u

User metadata
Rank Member
Rank
Member
TomArrow wrote:
Heya, thanks for the tip. Unfortunately, the code only uses this value to inject it into memory, probably altering a variable in […]
Show full quote
daniel_u wrote:
Hi, I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .:) The xbox version al […]
Show full quote
TomArrow wrote:
Hello Dege and others, […]
Show full quote

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .😀
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.

Heya, thanks for the tip. Unfortunately, the code only uses this value to inject it into memory, probably altering a variable in the algorithm, so it doesn't expose the algorithm itself.

If the algorithm is DirectX-based, my naive thinking would suggest that it could be 'grabbed' with something similar to a 3D ripper. That is, the instructions could be seen. But that would probably be a pain in the ass to filter out the correct ones from the ones that are unrelated, depending on how the data is arranged.

But I'm a newbie either way. I figured I'd ask here because someone might know a simple answer that may take me weeks to figure out.

Oh and I'm totally fine with the PC version. Xbox would be way too much work to figure out is my best guess.

There is a program called 3d-Analyze that has many video options including dumping the pixel and vertex shaders. Might help.

Reply 6 of 232, by Dege

User metadata
Rank l33t
Rank
l33t
TomArrow wrote:
Hello Dege and others, […]
Show full quote

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Hi Tom,

well, I think the algorhytm could be reverse engineered.
I did tons of debugging on SC 1/2 when working fixing shadow buffers and rendering bugs related to those games. Millions of shaders to check out, etc.
I'm not sure (because I didn't specifically debugged night vision) but it's probably solved by a post process shader at the end of the frame rendering.
Since I can debug the process of the frame rendering at polygon level (I mean, Draw-call level), and the debug version of dgVoodoo disassembles all of the game shaders, I think I could figure it out what's going there.
My scruple is, is publicly reverse engineering a propietary game legal?

Reply 7 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:
Hi Tom, […]
Show full quote
TomArrow wrote:
Hello Dege and others, […]
Show full quote

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom

Hi Tom,

well, I think the algorhytm could be reverse engineered.
I did tons of debugging on SC 1/2 when working fixing shadow buffers and rendering bugs related to those games. Millions of shaders to check out, etc.
I'm not sure (because I didn't specifically debugged night vision) but it's probably solved by a post process shader at the end of the frame rendering.
Since I can debug the process of the frame rendering at polygon level (I mean, Draw-call level), and the debug version of dgVoodoo disassembles all of the game shaders, I think I could figure it out what's going there.
My scruple is, is publicly reverse engineering a propietary game legal?

Hi Dege,

I would be very grateful if you did that, but I am no lawyer, so I have no idea about that. All I can say is you could send it to me personally and I would be fine keeping it to myself. Also, it's imo hardly a very sophisticated algorithm that would qualify as some kind of intellectual property. As I said, I am not interested in it because I am unable to come up with something that looks like it, but because I want the exact thing, for shits and giggles. Either way, it's your call. I don't want to get you into trouble.

Reply 8 of 232, by Dege

User metadata
Rank l33t
Rank
l33t

OK, after all I did it in the other thread when debugged light beams...

So, look at this scene, normally without NightVision:

Scene_Normal.png

The steps of NightVision rendering is:

1. At first, the scene seems to be rendered as normally, but with some ambient lighting

Scene_Ambient.png

2. You can see 3 light emitter objects here: Moon and 2 lamps. Their lights are rendered into a smaller texture

Light_Srcs.png

3. The image of those lights are blurred and dilated in a more step process (e.g. blurring the texture by drawing into a half a size texture, then blending this texture (back) onto the original one), this will serve as the aura of the light sources.
Step 2 and 3 are not NightVision specific because you have light aura normally as well, but their extent are larger in NightVision.

Light_Srcs_Aura.png

4. Finally the game does the postprocess with 3 textures, to get the final image

texture 0 - the rendered scene (step 1)
texture 1 - a 128x128 texture, must be containing the 2D noise as an image (which must have more than one frames for animation)
texture 2 - 256x256 texture to which the light aura was rendered

The shader used for drawing a screen quad (with my comments):

 ps.1.1

def c4, 0.300000, 0.590000, 0.110000, 0.000000 ; coefficients for converting to grayscale (r,g,b weights)
def c5, 0.900000, 1.000000, 0.900000, 0.000000 ; coefficients for domination of 'green'
tex t0
tex t1
tex t2 ; sample textures
add r0, t0, t2 ; r0 = rendered scene + light aura (additive blending of light aura to the scene)
add r0, r0, r0 ; r0 = 2*(rendered scene + light aura)
dp3 r0, r0, c4 ; r0 = dot(r0.rgb, c4.rgb) converting to grayscale
mul r0, r0, c5 ; r0 = bend the result toward a little greenish
mul_x2 r0.rgb, r0, t1 ; result = 2 * r0 * 2dnoise texure

and then clamp the result into [0, 1].

Night_Vision.png

Reply 9 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie

Hah! Fuckin brilliant, mate. Thank you! Just what I wanted.

Only thing that surprised me is the weighting of color information for greyscale generation. Didn't expect that!

Now I told you I'm a nitpicker, so if and only if you find the patience and time, can you elaborate more on the steps that came without code examples?

Namely:

- How much ambient lighting is used? If it is a fixed value, what is it? And is it in RGB 255 255 255 mode or fractions of 1 just as the coefficients? Is it global or specific for every material? (in which case of course you don't need to list every material's value, haha)

- The smaller texture from step 2 is not the light emitter itself, if you look closely, but rather a snap of the scene rendered in 1 bit (kind of!), with a certain brightness treshold for determining whether the pixel is bright or black. The 'active' pixels have a color value of 177,254,177. Is this always the case or does it depend on variables? Is it constant or does it change over time?

- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.

Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
Filename
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
File size
21.32 KiB
Views
11681 views
File comment
Try with Normal Version Plus Added Half-sized blurred version
File license
Fair use/fair dealing exception
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png
Filename
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png
File size
22.23 KiB
Views
11681 views
File comment
Try with two half-sized blur versions added together
File license
Fair use/fair dealing exception

- For the noise, does it simply tile the texture over the whole image? (looks that way)

- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

- Is normal bilinear sampling used to upscale the aura back onto normal size?

- In the "add r0,r0,r0" line, is there some particular reason you wrote 2*(rendered scene + light aura) in the comment instead of 2*r0?

- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

That's all I can think of right now...

Reply 10 of 232, by Dege

User metadata
Rank l33t
Rank
l33t
TomArrow wrote:

Hah! Fuckin brilliant, mate. Thank you! Just what I wanted.

Only thing that surprised me is the weighting of color information for greyscale generation. Didn't expect that!

Well, the human eyes are sensitive at different degrees to red, green and blue color, that's why it is.
It has its on studies, see e.g. 'Luma coding in video systems'.

TomArrow wrote:

Now I told you I'm a nitpicker, so if and only if you find the patience and time, can you elaborate more on the steps that came without code examples?

Namely:

- How much ambient lighting is used? If it is a fixed value, what is it? And is it in RGB 255 255 255 mode or fractions of 1 just as the coefficients? Is it global or specific for every material? (in which case of course you don't need to list every material's value, haha)

For this, the vertex shader(s) the game using should be examined. Unfortunately they are way more difficult than pixel shaders but could be figured out. It's indeed possible that the exact value varies for different scenes, materials, etc.
For vertex shaders normalized [0..1] or signed normalized [-1..1] space is more convenient.
Unnormalized space would just be painful (multiplying two unnormalized values would require an explicit additional normalization, etc.).

TomArrow wrote:

- The smaller texture from step 2 is not the light emitter itself, if you look closely, but rather a snap of the scene rendered in 1 bit (kind of!), with a certain brightness treshold for determining whether the pixel is bright or black. The 'active' pixels have a color value of 177,254,177. Is this always the case or does it depend on variables? Is it constant or does it change over time?

Ok, it's true. It indeed seems to be a thresholded monochrome bitmap, but

TomArrow wrote:

- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

I didn't checked the details on shaders.

TomArrow wrote:
- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and t […]
Show full quote

- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.

Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png

Good question, the detail should be checked.

TomArrow wrote:

- For the noise, does it simply tile the texture over the whole image? (looks that way)

I think it's tiled, as it's only a 128x128 compressed texture and it has fine granurality on the final image.

TomArrow wrote:

- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

The 2 'add' intructions produces 2*(rendered scene + light aura). (2*(t0+t2))
The '_x2' modifier only means that the result (that is, r0*t1 here) has to be further multiplied by 2.

TomArrow wrote:

- Is normal bilinear sampling used to upscale the aura back onto normal size?

It should be, after all the point is the blurriness.

TomArrow wrote:

- In the "add r0,r0,r0" line, is there some particular reason you wrote 2*(rendered scene + light aura) in the comment instead of 2*r0?

Hurry, copypaste... it's actually only means that r0 = r0 + r0. 😀

TomArrow wrote:

- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

I don't know what happens with the texture until it's passed for rendering. It's a compressed one, so probably there is no any preprocessing on it.

Reply 11 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:

Well, the human eyes are sensitive at different degrees to red, green and blue color, that's why it is.
It has its on studies, see e.g. 'Luma coding in video systems'.

That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. 😉 Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Dege wrote:

For vertex shaders normalized [0..1] or signed normalized [-1..1] space is more convenient.
Unnormalized space would just be painful (multiplying two unnormalized values would require an explicit additional normalization, etc.).

I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

Dege wrote:

Ok, it's true. It indeed seems to be a thresholded monochrome bitmap, but

TomArrow wrote:

- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

I didn't checked the details on shaders.

Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Dege wrote:
TomArrow wrote:
- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and t […]
Show full quote

- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png

Good question, the detail should be checked.

Would you check on those details for me or am I asking too much?

Dege wrote:
TomArrow wrote:

- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

The 2 'add' intructions produces 2*(rendered scene + light aura). (2*(t0+t2))
The '_x2' modifier only means that the result (that is, r0*t1 here) has to be further multiplied by 2.

Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

Dege wrote:
TomArrow wrote:

- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

I don't know what happens with the texture until it's passed for rendering. It's a compressed one, so probably there is no any preprocessing on it.

Compressed you say? The original is a BMP file. Hmm.

Reply 12 of 232, by Dege

User metadata
Rank l33t
Rank
l33t
TomArrow wrote:

That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. 😉 Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Yes, you're right.
But I guess the developers just took the usual grayscale coefficients for the conversion, that's all. I use to do the same. 😀

TomArrow wrote:

I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

No, I'm not talking about the normalized vertex (coordinate) space.
Ambient light is indeed just a plain additive component in the lighting calculations. But the lighting calculation formula as a whole is much more complex, e.g. you have to multiply the incoming light color with the material diffuse color. For those calculations it's handy to have even the color information in normalized [0..1] range, that's all what I meant. If the [0..255] range were used then a simple multiplication would leave the range (for example, 255*255 = 65025), so additional operations for 'normalizing it back' would be needed.
That's why defining constant values are more common in [0..1] range for shaders rather than [0..255].

TomArrow wrote:

Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Quite sure, thresholding pixels needs a pixel shader.

TomArrow wrote:

Would you check on those details for me or am I asking too much?

I could have another look. 😀
But, since I only debug a particular scene, I'm not sure if the values (like ambient) are constant in general.

TomArrow wrote:

Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

It's only a matter of the properly chosen texture coordinates. Scaling the scene into 256*256 (for generating auras) won't preserve the aspect ratio but it's not a problem at all. That texture will be stretched back to the scene texture size later, when the final image is calculated.
Texture coordinates are also normalized [0..1, 0..1], but coordinates outside of that range can be used, so e.g. [0..4, 0..4] means 4x4 tiling a texture, if the texture addressing mode is set to 'wrap mode'. But these are really deep details of the rendering. 😀

TomArrow wrote:

Compressed you say? The original is a BMP file. Hmm.

You mean, it's stored as a BMP in the game data files?
Then SC may compress them after reading them in to save video memory.

Reply 13 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:
TomArrow wrote:

That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. 😉 Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Yes, you're right.
But I guess the developers just took the usual grayscale coefficients for the conversion, that's all. I use to do the same. 😀

I see. Wasn't aware of that practice. Always thought it'd be straightforward to just average the values. And more efficient. But maybe that's not true.

Dege wrote:
No, I'm not talking about the normalized vertex (coordinate) space. Ambient light is indeed just a plain additive component in t […]
Show full quote
TomArrow wrote:

I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

No, I'm not talking about the normalized vertex (coordinate) space.
Ambient light is indeed just a plain additive component in the lighting calculations. But the lighting calculation formula as a whole is much more complex, e.g. you have to multiply the incoming light color with the material diffuse color. For those calculations it's handy to have even the color information in normalized [0..1] range, that's all what I meant. If the [0..255] range were used then a simple multiplication would leave the range (for example, 255*255 = 65025), so additional operations for 'normalizing it back' would be needed.
That's why defining constant values are more common in [0..1] range for shaders rather than [0..255].

Oh! Right. Lol. For some reason I thought those numbers in brackets were vectors ... silly.

Dege wrote:
TomArrow wrote:

Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Quite sure, thresholding pixels needs a pixel shader.

But it would then be a pixel shader applied over the entire image, not individual vertices, no? (If that's possible). I just don't see why one would bother implementing such a feature by cluttering vertex rendering code with it instead of just taking it from the final image. (That's how it is done in video production too, where you obviously can't access "vertices" retroactively)

Dege wrote:
TomArrow wrote:

Would you check on those details for me or am I asking too much?

I could have another look. 😀
But, since I only debug a particular scene, I'm not sure if the values (like ambient) are constant in general.

That'd be great. No problem whatsoever about being sure if they are constant. I take whatever I can get, heh. Of course, if you feel super excited about comparing it to a random second scene, I won't protest.

Dege wrote:
TomArrow wrote:

Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

It's only a matter of the properly chosen texture coordinates. Scaling the scene into 256*256 (for generating auras) won't preserve the aspect ratio but it's not a problem at all. That texture will be stretched back to the scene texture size later, when the final image is calculated.
Texture coordinates are also normalized [0..1, 0..1], but coordinates outside of that range can be used, so e.g. [0..4, 0..4] means 4x4 tiling a texture, if the texture addressing mode is set to 'wrap mode'. But these are really deep details of the rendering. 😀

Aah! So the texture has an addressing mode set (that is invisible in the example you posted) which determines how and if it will be stretched to fit onto another texture of another size?

Dege wrote:
TomArrow wrote:

Compressed you say? The original is a BMP file. Hmm.

You mean, it's stored as a BMP in the game data files?
Then SC may compress them after reading them in to save video memory.

Yup. BMPs. There are four. I converted two to PNG (for the forum upload), look:

Noise0_gauss.png
Filename
Noise0_gauss.png
File size
27.31 KiB
Views
11635 views
File license
Fair use/fair dealing exception
Noise1_gauss.png
Filename
Noise1_gauss.png
File size
27.35 KiB
Views
11635 views
File license
Fair use/fair dealing exception

Histogram shows a tone range between roughly 70 and 191, which would translate normalized to roughly 0.27 to 0.74. Multiplied with 2 (since mulx2) it's roughly 0.5 to 1.5. So the normal values of the image would fluctuate by 50%. Now this is a purely subjective statement, but it doesn't seem that strong to me in the final image. But then, it's a bell curve (Gauss), so maybe that's why it looks okay. Can you 'grab' one of the noise textures from the "t1" variable, to compare it to the one I posted?

Reply 16 of 232, by alien41

User metadata
Rank Newbie
Rank
Newbie

I would first like to thank everyone involved in this project.

I do not know if it's a bug, but compared to the XBOX version, SC 1 still has some places missing shadows and in some cases, the shadow disappears as the character approaches.

I can put some pictures if the guys want.

Reply 17 of 232, by daniel_u

User metadata
Rank Member
Rank
Member
alien41 wrote:

I would first like to thank everyone involved in this project.

I do not know if it's a bug, but compared to the XBOX version, SC 1 still has some places missing shadows and in some cases, the shadow disappears as the character approaches.

I can put some pictures if the guys want.

Yeah, theres quite a lot of small differecens.

MIssing effects, shadows and some bugs. It would be nice if a modder would fix these but Dege only restores the original PC things.
He is not willing to add new stuff to the games, altough he added 'soft' shadow for Sam in SCPT. 😉 He's a busy man not sure if there is some way to convice him to fix the game. Maybe some donations? 😀
Either way i'm happy because now we can play SC1 & 2 on PC without retro hardware. Thanks Dege.

Maybe Komat is more willing to change the original programming but he is long gone.

Reply 18 of 232, by TomArrow

User metadata
Rank Newbie
Rank
Newbie

One thing in particular I noticed wrong (and I'm relatively sure that's not how it's supposed to be) is that some lit areas have hard edges. And many light cones with hard edges kinda overlap and it looks very "artsy", 2D art like, if you know what I mean. There is no fallof. This is very apparent in the Presidential Palace in the upper elevator room.

Reply 19 of 232, by daniel_u

User metadata
Rank Member
Rank
Member
TomArrow wrote:

One thing in particular I noticed wrong (and I'm relatively sure that's not how it's supposed to be) is that some lit areas have hard edges. And many light cones with hard edges kinda overlap and it looks very "artsy", 2D art like, if you know what I mean. There is no fallof. This is very apparent in the Presidential Palace in the upper elevator room.

Without some pictures and save game is hard to know what are you talking about. 😀 Can you elaborate?