lowenz wrote:

*SC2 doesn't even start: "General protection fault! History: CreateEchelonTextures <- UD3DRenderDevice::SetRes <- UWindowsViewport::TryRenderDevice <- UWindowsViewport::OpenWindow <- UGameEngine::Init <- InitEngine" UE message

Removing the widescreen fix by ThirteenAG the game starts but fails to load a level (same as SC1)

General protection fault!

History: FD3DRenderInterface::DrawPrimitive <- FStaticMeshRender <- FDynamicActor::Render <- RenderLevel <- FLevelSceneNode::Render <- FCameraSceneNode::Render <- UGameEngine::Draw <- UWindowsViewport::Repaint <- UWindowsClient::Tick <- ClientTick <- UGameEngine::Tick <- UpdateWorld <- MainLoop

Here's the first bug for SC:
The level is the oil refinery. In the ocean you can see some lines that make up some squares. Artefacts?
Here is the save game to downaload and test:

http://s000.tinyupload.com/?file_id=01418287687537353629
I'm using 2x MSAA with a 4k resolution(nvidia downsampled).

Picture here: http://imgur.com/yaj4poH

Second bug: Shiny textures. You can observe more here: https://youtu.be/nB9BTbtNyDw?t=9m.
Save game here:
http://s000.tinyupload.com/?file_id=00807555039924949758

Hope it helps.

Update: "General protection fault! History: CreateEchelonTextures <- UD3DRenderDevice::SetRes <- UWindowsViewport::TryRenderDevice <- UWindowsViewport::OpenWindow <- UGameEngine::Init <- InitEngine" UEmessage

.....is due to low RAM of the default GF4 preset, 128 MB. With 256 MB the game starts fine with the Widescreen Patch. Still, loading a level:

General protection fault!

History: FD3DRenderInterface::DrawPrimitive <- RenderBspSurface <- RenderLevel <- FLevelSceneNode::Render <- FCameraSceneNode::Render <- UGameEngine::Draw <- UWindowsViewport::Repaint <- UWindowsClient::Tick <- ClientTick <- UGameEngine::Tick <- UpdateWorld <- MainLoop

I guess it's because I'm not using any widescreen anything, but running at 1600x1200 using dgVoodoo2 WIP25, GeForce 4 Ti w/256 MB VRAM, and fast memory access hasn't caused me a single problem. Though I haven't gotten to the oil refinery level yet, and I don't know what the game is supposed to look like with working shadow buffers other than the screenshots shown, it looks fine from here!

EDIT: Here's the game running through the first real-time cinematic (briefing for Training): https://youtu.be/p1ZZ1cKIlzo

Expack3 wrote:

I guess it's because I'm not using any widescreen anything, but running at 1600x1200 using dgVoodoo2 WIP25, GeForce 4 Ti w/256 MB VRAM, and fast memory access hasn't caused me a single problem. Though I haven't gotten to the oil refinery level yet, and I don't know what the game is supposed to look like with working shadow buffers other than the screenshots shown, it looks fine from here!

EDIT: Here's the game running through the first real-time cinematic (briefing for Training): https://youtu.be/p1ZZ1cKIlzo

The problem is the lines in the water.

daniel_u wrote:

Expack3 wrote:

I guess it's because I'm not using any widescreen anything, but running at 1600x1200 using dgVoodoo2 WIP25, GeForce 4 Ti w/256 MB VRAM, and fast memory access hasn't caused me a single problem. Though I haven't gotten to the oil refinery level yet, and I don't know what the game is supposed to look like with working shadow buffers other than the screenshots shown, it looks fine from here!

EDIT: Here's the game running through the first real-time cinematic (briefing for Training): https://youtu.be/p1ZZ1cKIlzo

The problem is the lines in the water.

I saw that from your screenshot. As I said, I haven't gotten to that level yet, so I can't test to see if I have that issue.

I found the culprit: the MSAA - and so FL 10.1 - seems *needed* to use Shadowbuffer Mode :p

All the problems I had are solved turning it ON. Can you fix it, Dege? MSAA shouldn't be a requisite :p

lowenz wrote:

I found the culprit: the MSAA - and so FL 10.1 - seems *needed* to use Shadowbuffer Mode :p

All the problems I had are solved turning it ON. Can you fix it, Dege? MSAA shouldn't be a requisite :p

Does it come only with widescreen patch? (I should try it)
I re-tested SC with and without MSAA, FL10.0, FL10.1 with GF4 128MB VRAM and the game worked fine.

I set the ingame resolution to 1024x768 and scaled it up from that through dgVoodoo, but if you use larger resolutions then the amount of GF4 VRAM can be a problem.

SCPT also worked fine. Does WIP25 crash for you, while earlier version works?

The water has a glitch, indeed, because it looks fine natively.
I thought I would never debug Splinter Cell again, but... 😁 😁 😁

Expack3 wrote:

I guess it's because I'm not using any widescreen anything, but running at 1600x1200 using dgVoodoo2 WIP25, GeForce 4 Ti w/256 MB VRAM, and fast memory access hasn't caused me a single problem. Though I haven't gotten to the oil refinery level yet, and I don't know what the game is supposed to look like with working shadow buffers other than the screenshots shown, it looks fine from here!

EDIT: Here's the game running through the first real-time cinematic (briefing for Training): https://youtu.be/p1ZZ1cKIlzo

Cool video! 😎

I obviously tested with AND without the WS patch and it's not her fault, it seems.
Enabling MSAA solves my problem with erratic lighting - camera dependent - in SC Versus too (Unreal Engine 2) ->

Dege wrote:

The water has a glitch, indeed, because it looks fine natively.
I thought I would never debug Splinter Cell again, but... 😁 😁 😁

Until that level it worked ok. I'm very happy.

There's also the shiny texture glitch. I'm really curios of the cause. Shiny textures affects Geforce FX series but not GeForce 4 Ti 's.

Looking forward,the game comes with some .bat files(used for benckmarks). Try running those(check to see which demo's are working with shadow buffers).

When i ran one of them i had some weird issues . Shadows were all over the place(Kalinatek level). Something was not working right.
I didnt play test those levels yet but there could be some problems ahead.

Dege wrote:

but if you use larger resolutions then the amount of GF4 VRAM can be a problem.

256 is good enough, no slowdowns at all.
But maybe you can add more memory (512,1024), the only thing important is to set the preset to 128 MB (as it is) for old Unreal Engine versions.

lowenz wrote:

Dege wrote:

but if you use larger resolutions then the amount of GF4 VRAM can be a problem.

256 is good enough, no slowdowns at all.
But maybe you can add more memory (512,1024), the only thing important is to set the preset to 128 MB (as it is) for old Unreal Engine versions.

I'm quite sure you can edit the amount of memory there, no?

daniel_u wrote:

I'm quite sure you can edit the amount of memory there, no?

Yes, but the real problem is why with UT 436 every value above 128 MB causes this:

Unreal Gold D3D renderer from the Anthology (2006)+Unofficial Patch 227i seems to be NOT tainted by this issue. UT one is affected.

lowenz wrote:

Yes, but the real problem is why with UT 436 every value above 128 MB causes this: […]
Show full quote

daniel_u wrote:

I'm quite sure you can edit the amount of memory there, no?

Yes, but the real problem is why with UT 436 every value above 128 MB causes this:

Unreal Gold D3D renderer from the Anthology (2006)+Unofficial Patch 227i seems to be NOT tainted by this issue. UT one is affected.

Check if your PC's swap file is large enough.

4 GB.
Obviously that message is not to be taken literally, it's a cry of misunderstanding between drivers+OS and UT+dgvoodoo2 :p

With 128 MB UT runs perfectly. Dege too encountered the problem, it's why the presets are set to 64/128 MB.

lowenz wrote:

I found the culprit: the MSAA - and so FL 10.1 - seems *needed* to use Shadowbuffer Mode :p

All the problems I had are solved turning it ON. Can you fix it, Dege? MSAA shouldn't be a requisite :p

Ok, I can reproduce it: Unforced resolution + no MSAA causes a crash. Fixed.
Water glitch is due to forced resolution, it's fine with unforced one. Since water is dinamically rendered into textures, resolution forcing affects their size. Even integer scale factor (ISF) doesn't help. 😒

lowenz wrote:

4 GB.
Obviously that message is not to be taken literally, it's a cry of misunderstanding between drivers+OS and UT+dgvoodoo2 :p

With 128 MB UT runs perfectly. Dege too encountered the problem, it's why the presets are set to 64/128 MB.

Yes, I was able to reproduce it. I'm going to check it out.

daniel_u wrote:

There's also the shiny texture glitch. I'm really curios of the cause. Shiny textures affects Geforce FX series but not GeForce 4 Ti 's.

Looking forward,the game comes with some .bat files(used for benckmarks). Try running those(check to see which demo's are working with shadow buffers).

When i ran one of them i had some weird issues . Shadows were all over the place(Kalinatek level). Something was not working right.

Could you post screenshots about them, when you get there, plz?

Dege wrote:

Water glitch is due to forced resolution, it's fine with unforced one. Since water is dinamically rendered into textures, resolution forcing affects their size. Even integer scale factor (ISF) doesn't help. 😒

Can it be fixed?
I will try to run the game forcing the resolution in the game files + unforced in the dgvoodoo ,to see if this will help.

Dege wrote:

daniel_u wrote:

There's also the shiny texture glitch. I'm really curios of the cause. Shiny textures affects Geforce FX series but not GeForce 4 Ti 's.

Looking forward,the game comes with some .bat files(used for benckmarks). Try running those(check to see which demo's are working with shadow buffers).

When i ran one of them i had some weird issues . Shadows were all over the place(Kalinatek level). Something was not working right.

Could you post screenshots about them, when you get there, plz?

Will post asap.(the bat files should be in the system folder of the game)

daniel_u wrote:

Can it be fixed?

Unfortunately not.

daniel_u wrote:

Will post asap.(the bat files should be in the system folder of the game)

Thx!

daniel_u wrote:

Dege wrote:

Water glitch is due to forced resolution, it's fine with unforced one. Since water is dinamically rendered into textures, resolution forcing affects their size. Even integer scale factor (ISF) doesn't help. 😒

Can it be fixed?
I will try to run the game forcing the resolution in the game files + unforced in the dgvoodoo ,to see if this will help.

Try getting ThirteenAG's widescreen fix, disabling the ThirteenAG shadow buffer fix in both the inis, and rename ThirteenAG's d3d8.dll to d3d81.dll. This should allow you to run at your native resolution without issue.

d3d8.dll and d3d8.ini of TAG fix are worthless if you use D3D8 by dege 😉 You can remove them.
In the ini script let the shadowbuffer option set to 1.