Full Screen Shader Crash (1.18b7)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. in setup.ini - Set postprocessing=2
2. Create a small room in FPSC using the segments and items listed in 
additional info
3. Launch a test game from within the FPSC editor and pick-up or try to use 
either weapon.

What is the expected output? What do you see instead?
Expected output: No crash
Actual output: DBProBasic3DDebug.dll crash

What version of the product are you using? On what operating system?
OS: Windows 7 Home Premium 64bit V6.1 Build 7600
Graphics Card: nVidia Geforce 9600, Driver Version 8.17.12.6099 (current stable 
release)

Please provide any additional information below.
Segment used: dungeon_room_1 from FPSC pack #23
Eneties Used: Bow from model pack #28
Light source: Single static light using default settings
Shaders used: Depth of field shader included with beta 1.18 Beta 7

Crash occured almost immediately after picking up the bow. With the Crossbow 
from pack #28, crash occures either immediately after weapon pick-up or within 
seconds of firing the weapon.

Original issue reported on code.google.com by arko...@gmail.com on 29 Jan 2011 at 12:20

Attachments:

• [FPSC Crash.jpg](https://storage.googleapis.com/google-code-attachments/fpscreatorengine/issue-21/comment-0/FPSC Crash.jpg)

[GoogleCodeExporter]

If this crash also happens with a standalone executable, can you create one and 
zip it up and attach here, so I can see the bug. Cannot reproduce at this end 
currently.

Original comment by LeeBamberTGC@gmail.com on 5 Feb 2011 at 3:31

• Changed state: Accepted

[GoogleCodeExporter]

Here's a small room build. I ran a quick test on another comp here in our home 
office after putting this build together just to verify I wasn't completely 
insane. The other comp I used for testing is hardware wise completely different 
from my main comp, and is using older drivers. It crashed almost immediately 
after the bow was collected.

It was too large to attach (even when compressed), so here's a link to it on my 
mega-upload account. http://www.megaupload.com/?d=0U20D696

Original comment by arko...@gmail.com on 6 Feb 2011 at 2:05

[GoogleCodeExporter]

The Megauploads Zip file is corrupt. Please re-compile and send, thanks.

Original comment by LeeBamberTGC@gmail.com on 6 Feb 2011 at 7:57

[GoogleCodeExporter]

Re-uploaded: http://www.megaupload.com/?d=328EBNMK

Original comment by arko...@gmail.com on 6 Feb 2011 at 3:27

[GoogleCodeExporter]

Sorry about the corrupt upload earlier. I never should've used 7zip, always 
have horrible luck with it.

Original comment by arko...@gmail.com on 6 Feb 2011 at 6:37

[GoogleCodeExporter]

I extracted your zip and ran the game, which allowed me to collect both weapons 
and fire them without the crash you report. I am certain it is something to do 
with the specific system set-up and the key is finding out exactly what the 
causal factor is. If you have experience in serious debugging, it would be 
great (at your own risk of course), if you could swap out your GPU for another 
card, swap out drivers, close down all background tasks and run again, run on 
another machine you might have, e.t.c. Generally whittling down the cause to a 
single item in your set-up. Given where the crash occurs and the fact your 
resource bars are quite high for a single room, it might be related to the 
hardware specification like CPU/GPU/Sound. Let me know if you find anything 
further out.

Original comment by LeeBamberTGC@gmail.com on 9 Feb 2011 at 2:09

[GoogleCodeExporter]

I've tested in on two different systems so far.

System 1: 3 GHz Dual Core, ECS nForce system board, 2GB system memory, nVidia 
GeForce 9600GSO graphics card. Display driver release date: 10/16/2010.
System 2: 3.3 Ghz single core, eMachines system board, 2GB system memory, 
nVidia GeForce 8400GS graphics card. Display Driver release date: 7/10/2010.

Both systems are running Windows 7 Home Premium 64bit, System 1 has the latest 
updates from Microsoft, System 2.... Ugh, Don't think it's ever been updated. 
Aside from the OS, the only common factor the two computer's share is the audio 
driver version - Both are using a Microsoft release from July of 2009.

The demo I provided you a link to crashes on both systems. I'm going to try 
playing around with the audio drivers some and see if that has any effect.

Original comment by arko...@gmail.com on 11 Feb 2011 at 12:26

[GoogleCodeExporter]

I think I nailed it down finally. After updating the audio drivers on one of my 
two test systems, it still crashed. So I ran through all the commonalities, 
everything I hadn't tried. The one common factor I could find was that the 
"shader crash" always seemed to happen when I was using postprocessing=2 in the 
set-up file (which I've always used for whatever random shader i'm playing 
around with) and never seemed to happen with postprocessing=1 (I've always used 
it for bloom - even for Bond1's modified bloom).

So I set post processing in the set-up file to 1 and ran several tests using 
various random shaders I've been playing around with as replacement for the 
bloom shader - No crash with any of them, even ones that were crashing before. 
The same shaders set as the depth of field shader with post processing set to 
2? Crashes every time on both my test systems.

It may not be a fix in the traditional sense, but I'm happy with it... Really 
glad I found a work around... Next debugging stage was going to involve running 
some linux tests.... As a side note - FPSC runs great using Wine on Linux.

Original comment by arko...@gmail.com on 13 Feb 2011 at 12:47

[GoogleCodeExporter]

Just to clarify, does it crash when you use the "default shaders" using 
Postprocessing=2?

Original comment by LeeBamberTGC@gmail.com on 15 Feb 2011 at 7:36

[GoogleCodeExporter]

Yes, even the default shaders crash if I set it to Postprocessing=2 and use 
them as "post-depthoffield" shader.

All full-screen shaders work without a crash when I have it set to 
Postprocessing=1 and I'm using them as the "post-bloom" shader.

Original comment by arko...@gmail.com on 15 Feb 2011 at 11:49

[GoogleCodeExporter]

I take it you are 'modifying' the full-screen shader, is that right?  Does it 
crash when you do not modify the full-screen shader at all, and use the one 
from the official V118 update? Postprocess=2 (depth of field) does more than 
choose a different shader file, it prepares the scene to render with additional 
depth information (to another camera) which could indicate you're running out 
of video memory (or close to the edge)? Can you tell me the dedicated GPU video 
memory of each of your test systems, thanks. 

Original comment by LeeBamberTGC@gmail.com on 21 Feb 2011 at 5:27

[GoogleCodeExporter]

That might be it... Seems odd to me though that all shaders, even the default 
DOF shader file would crash like this if used as the as the "postprocessing 2" 
shader.

Pulled these numbers from DX Diag on both systems.
System 1: 1521MB total video memory
System 2: 1266MB total video memory

Original comment by arko...@gmail.com on 22 Feb 2011 at 12:24

[GoogleCodeExporter]

I take it you are 'modifying' the full-screen shader, is that right?  Does it 
crash when you do not modify the full-screen shader at all?

Original comment by LeeBamberTGC@gmail.com on 22 Feb 2011 at 1:24

• Changed state: Started

[GoogleCodeExporter]

Although I first noticed it while using a modified shader, even when it's 
unmodified, it still results in the same crash.

The demo I uploaded, for example, is using the unmodified DOF shader file. It 
crashes on both my test platforms.

Only when either the Box or X-Bow from model pack 28 is picked up or used 
though. I've tried reproducing the issue using other items and have been unable 
to do so.

Original comment by arko...@gmail.com on 22 Feb 2011 at 11:21

[GoogleCodeExporter]

Do you have any idea why it crashes on your two test systems and not on anyone 
else's systems? Is there something unique about your system configurations or 
set-up not reported? Any possibility you could create a short video of the 
crash, as I will get a real feel for this issue then. Sorry to be a hassle. 
Non-reproducible bugs are the bane!

Original comment by LeeBamberTGC@gmail.com on 27 Feb 2011 at 10:13

[GoogleCodeExporter]

I don't consider it to be a hassle at all, I know how rough bug squashing can 
be (half the reason I love FPSC so much is I've written an FPS engine before - 
frichen pain in the arse to do right).

Both of the test systems are machines we've (The Wife and I) built ourselves. 
As far as I know there's nothing too unique about either of the test systems. 
Mine (System 1) usually has it's CPU over-clocked a hair and dual boots Ubuntu 
Linux along side Windows 7 (I've been testing FPSC built games under WINE - so 
far they've all run great), but I've already tried it with the clock speeds 
reset to their base values and I still get the same crash. Her's stock without 
any modifications or over-clocking.

I'd be happy to do a video capture of the crash as it happens, if you could 
suggest a good app for doing the video capture. I have Fraps, but it doesn't 
capture the error screens.

Also, I'll take the test build I sent you and do a WINE test in Ubuntu with it. 
I've been curious to see if it would crash there as well.

Original comment by arko...@gmail.com on 27 Feb 2011 at 11:17

[GoogleCodeExporter]

Here we go... Found an open source screen recording app that works OK.
Video of the crash is attached.

Original comment by arko...@gmail.com on 9 Mar 2011 at 7:33

Attachments:

• debug.zip

[GoogleCodeExporter]

I too get the same problem running the inclosed game debug.  If I pick up any 
of the weapons it crash with the same error message in the screenshot and video.

I copied and paste the bloom shader into the DOF to see if that would work.  It 
also crashs with the same error message.  If I copy the DOF and paste it into 
the bloom shader and enable postprocessor=1 it works without any error message 
and I can pick up and use the weapons.

The link below is the details of my system.  It includes everything I hope you 
will need to investigate the problem.

http://speccy.piriform.com/results/IdYnza51nBd0KF80FaTl9Pg

Original comment by DavidsGr...@gmail.com on 9 Mar 2011 at 11:26

[GoogleCodeExporter]

I made some progress on tracking down the bug for Lee. It honestly works on 
Lee's machine. On my machine with a newer video card and updated recent drive, 
it does crash. On my other two machines that are older. They work. 

But I Lee had some ideas and I had some similiar ideas and Lee asked me if I 
would like to try and track this bugger down. He thinks it has to do with the 
video card/driver.

Anyway, I tracked it to the hud.x file that is in the gun folder. I used the 
Katana for the test weapon. I tested quite a few weapons. The only ones that 
wouldn't work is the Katana form MP 9 (all the others from that pack work) and 
the Crossobow/Oil bombs from the Fanatasy Pack. I'm thinking I should verify 
now the same with those two weapons by replacing their hud.x files with one 
that works.

Terry
aka F l a t l a n d e r (the banned evil member) :SMILE:

Original comment by terryr...@gmail.com on 22 Apr 2011 at 4:20

[GoogleCodeExporter]

I just tested out the crossbow, oil bombs and bow and arrow by replacing their 
hud.x with the 44Snub hud.x which works. All three of these picked up without a 
crash. Of course the hud and weapon that is being held is all wrong. :)

Replaced with original hud.x and crashed.

So, I am very confident that it is the hud.x that is at issue. For whatever 
reason that be. Hopefully Lee can figure it out. He's the expert. ;)

Terry
aka F l a t l a n d e r

Original comment by terryr...@gmail.com on 22 Apr 2011 at 4:34

[GoogleCodeExporter]

Nice, glad to see it's been narrowed down. I honestly never would've thought to 
check the hud.x files. I've been planning on replacing all the hud.x files for 
the fantasy pack as part of a project I've been working on, but was holding off 
until I finished the level design and primary game scripting. One year into the 
project, no end in sight yet. I think we can all agree someone needs to invent 
a machine that creates "free time".

Original comment by arko...@gmail.com on 23 Apr 2011 at 1:23

[GoogleCodeExporter]

Lee's going to be on vacation. He'll probably be back Thursday or Friday of 
next week. I got the information to him a little late as I was running late. As 
he said everybody at TGC will bugger out all next week so he might as well have 
some vacation. :) 

Original comment by terryr...@gmail.com on 23 Apr 2011 at 1:55

[GoogleCodeExporter]

For those of you who have been watching this issue, Lee had asked me to check 
all the other versions. I used the "Katana." Of course they work in all other 
versions below v1.17 since there is no post processing for them. Checking 
version 1.17 and setting postproccessing to 2 does crash using my machine.

Again, this does not crash on Lee's machine and it does NOT crash on two of my 
older machines. Just my recent machine.

BTW, I was just thinking, which is extremely dangerous at times. The machine I 
am using that crashes is a Windows 7 64bit. I notice that the machine arko... 
uses this operating system as well. I'm going to mention this to Lee.

Original comment by terryr...@gmail.com on 28 Apr 2011 at 9:37

[GoogleCodeExporter]

Yeah, both my test systems are 64 bit windows 7

Original comment by arko...@gmail.com on 28 Apr 2011 at 10:01

[GoogleCodeExporter]

I have knocked this issue down to low and added extra help in the documentation 
to advise users avoid using post processing mode 2 with certain HUD models as 
this crash is extremely difficult to reproduce (impossible) at this end. It is 
likely a combination of things. As post processing mode 2 is not the default 
state of FPSC games, it will not affect anyone performing a simple upgrade. If 
this issue can be reproduced here, we'll be able to fix it in time.

Original comment by LeeBamberTGC@gmail.com on 3 May 2011 at 4:03

• Added labels: Priority-Low
• Removed labels: Priority-Medium