|
2007-10-04 20:28
|
NearlyBlackScreen.jpg (15,774 bytes) |
|
|
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 ;) |
|
2007-10-04 21:38
|
|
|
|
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? |
|
|
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. |
|
|
Might be fixed, don't know. Someone else will need to verify that and resolve this if so, or fix it if not. |
|
|
Fade-out seems to be working as of C08062008. Is this still a problem? |
|
|
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. |
|
|
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. :) |
|
|
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). |
|
|
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. |
|
2008-08-25 16:02
|
|
|
|
Should be fixed now. |
|
|
I really hope that hack doesn't have any other implications... |
|
|
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) |
|
|
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. |
|
|
I've just tested with Fade.fs2 mission and it seems fixed. (Nightly r4871) |
- Anonymous
