2017-09-19 19:12 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001510FSSCPgraphicspublic2008-10-11 07:08
ReporterARSPR 
Assigned ToWMCoolmon 
PriorityhighSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformDELL Dimension 9200OSWindows VistaOS VersionUltimate 32-bit
Product Version3.6.9 
Target VersionFixed in Version 
Summary0001510: Fade out does not work
DescriptionFade to black does not work and the bug has different behaviours depending on the build.

(Maybe related to 0001186 ???)

Steps To ReproduceI've noticed this issue in "Blue Planet - Age of Aquarius" MOD, "... With Vast Seas" (BP-01-2.fs2) mission. Sorry, but you have to play the mission till the end. :(

To pass it in the shortest way:
+ Power up your engines at full strength.
+ Afterburn till the first waypoint.
+ Then afterburn till the signal source which turns to be a disabled escape pod.
+ Wait till the Transport arrives.
and then ...

With official 3.6.9. (I suppose this is the right behaviour):
+ The screen fades to black.
+ You get a scripted scene where the transport jumps out.
+ You abruptly get your controls back and then you have to jump out to finish the mission.

With CVS 2007-09-22 (posted by Goober):
+ You miss the fade to black.
+ You abruptly get the scripted scene (with no previous fade to black).
+ You abruptly get your controls back and then you have to jump out to finish the mission.

With Taylor'x XT0924:
+ The screen fades to black.
+ The screen is kept black. You can't see anything.
+ Because the message log and the game sounds, I think that the scripted scene is actually played and you get your controls back so you can jump out and finish the mission. But the screen is kept black all the time, you don't even see the normal jump-out sequence.
+ Well, a little lie ;). The screen isn't fully black. Look at the attached screenshot (NearlyBlackScreen.jpg). You can see a one-pixel-width line of background in the right side of the screen. (The coloured pixels around this line are just jpg compression artifacts).
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0008553

ARSPR (reporter)

He, he, he, mystery solved thanks to Cobra hint in the MOD thread

We've got here a mixture of mission and build bugs or at least behaviour changes...

+CVS 2007-09-22: It does not fade out because of 0001186. Fade to black is too slow you don't see it.

+Taylor's XT0924: It does what it is told to do. As Cobra said, there's no fade-in sexp so the screen is kept black.

+Official 3.6.9., camera sexps and mission bug: As Cobra said, there's no fade-in sexp, this is a mission bug that should be fixed. Mission works fine with official 3.6.9. because set-camera SEXPs cause a fade-in somehow . I think this is actually a bug that is fixed at least in Taylor's build. Some SCP guy should confirm this.

I upload a fixed version (with a fade-in SEXP).

The only bug that remains is the slightly misplaced black faded-out screen ;)

~0008615

taylor (administrator)

I actually forgot to respond to this the last time I read it (I think I was a little confused ;))...

So, this is actually fixed in Xt builds, right? And it's broken in CVS builds because of 0001186, and broken in 3.6.9-final because of a mission bug.

Which means that this is just a duplicate of 0001186, which has since been fixed, correct?

~0008618

ARSPR (reporter)

Yes, this is a duplicate (it was a mix of several bugs) but the very very small issue with the nearly faded-out black screen.

When the screen fades out, it leaves a one pixel width of visible screen in the right and lower sides of the screen.

Look at the screenshot (NearlyBlackScreen.jpg) from bp-01-2.fs2, the coloured pixels at the right side are the destroyed Earth background.

~0009463

taylor (administrator)

Might be fixed, don't know. Someone else will need to verify that and resolve this if so, or fix it if not.

~0009546

WMCoolmon (developer)

Fade-out seems to be working as of C08062008. Is this still a problem?

~0009549

ARSPR (reporter)

Fade out was fixed quite long ago

As I said in (0008618), this mantis report is a mixture of bugs. Fade out one (the important one) was fixed some time ago.

There's, (or there was, as I haven't tested recently), an extremely unimportant issue where the faded-out black screen does not cover 100% of the screen. There is still one-pixel-width line of visible screen in the right and lower sides (NearlyBlackScreen.jpg). But I feel you can forget about this last issue. Any effort spent in it will be too much effort.

~0009595

WMCoolmon (developer)

So is there anything left to be done? That little line is worth fixing if it still exists - I've seen it before, and it looks crappy. But I just checked and I can't seem to reproduce it.

I'd like to close this bug if there's nothing more to be done with it. :)

~0009606

taylor (administrator)

I have "fixed" this in the Xt tree previously, but there doesn't actually appear to a bug in the code. It seems to be a compiler/optimization related issue that messes it up. A slight refactoring of the code in freespace.cpp appears to make the remaining problem go away, but what the real issue is I have no idea (hence why I haven't committed the Xt change for this).

~0009608

ARSPR (reporter)

Last edited: 2008-08-25 12:03

I've just tested with SVN 4758 compiled by Chief (http://www.hard-light.net/forums/index.php/topic,55879.0.html) and the line issue still happens (at least at 1680x1050 in my system)

I upload a test mission I made quite long ago. The mission fades out at 5 s, IIRC so you have time to move the background bitmat till the window border.

~0009753

phreak (developer)

Should be fixed now.

~0009766

chief1983 (administrator)

I really hope that hack doesn't have any other implications...

~0009767

phreak (developer)

not necessarily, because the gr_shader call is supposed to shade the entire screen a single color. I think the red "pain" effect may suffer from this issue too.

I am just curious why a rectangle from (0,0) to (1023,767) was causing it to not work right (it even occured in debug builds)

~0009908

chief1983 (administrator)

Marking high since this should be easy enough to verify as fixed before 3.6.10. Just need someone to test and say it's ok.

~0009930

ARSPR (reporter)

Last edited: 2008-10-11 05:31

I've just tested with Fade.fs2 mission and it seems fixed. (Nightly r4871)

+Notes

-Issue History
Date Modified Username Field Change
2007-10-04 16:28 ARSPR New Issue
2007-10-04 16:28 ARSPR File Added: NearlyBlackScreen.jpg
2007-10-04 17:37 ARSPR Note Added: 0008553
2007-10-04 17:38 ARSPR File Added: bp-01-2.fs2
2007-10-29 16:05 taylor Note Added: 0008615
2007-10-29 17:12 ARSPR Note Added: 0008618
2007-11-22 05:10 taylor Status new => assigned
2007-11-22 05:10 taylor Assigned To => taylor
2008-07-17 12:30 taylor Note Added: 0009463
2008-07-17 12:30 taylor Assigned To taylor =>
2008-07-17 12:30 taylor Status assigned => new
2008-08-07 04:18 WMCoolmon Note Added: 0009546
2008-08-07 04:18 WMCoolmon Assigned To => WMCoolmon
2008-08-07 04:18 WMCoolmon Status new => feedback
2008-08-08 06:12 ARSPR Note Added: 0009549
2008-08-23 02:47 WMCoolmon Note Added: 0009595
2008-08-24 19:04 taylor Note Added: 0009606
2008-08-25 12:02 ARSPR Note Added: 0009608
2008-08-25 12:02 ARSPR File Added: fade.fs2
2008-08-25 12:03 ARSPR Note Edited: 0009608
2008-10-01 00:05 phreak Note Added: 0009753
2008-10-02 00:46 chief1983 Note Added: 0009766
2008-10-02 10:44 phreak Note Added: 0009767
2008-10-09 16:25 chief1983 Note Added: 0009908
2008-10-09 16:25 chief1983 Priority normal => high
2008-10-11 05:30 ARSPR Note Added: 0009930
2008-10-11 05:31 ARSPR Note Edited: 0009930
2008-10-11 07:08 phreak Status feedback => resolved
2008-10-11 07:08 phreak Resolution open => fixed
+Issue History