|
2008-05-26 11:47
|
|
|
|
I found the problem causing the cutscene bars to jerk.. But.. I couldn't see the other issues you mentioned. can you post a screenshot of what you mean as i was unable to see those other mentioned problems using the attached mission. |
|
2008-06-02 18:07
|
screen0004.jpg (10,136 bytes) |
|
|
Screenshot attached. |
|
|
I am not seeing anything like that. In my test before and after applying the 'no jerkyness' fix the cutscene bars worked properly. However the sun glare seems to affect the whole screen so when the camera is facing a star the bars appear gray instead of black. This looks a tad odd as the fade out goes all to way to the black while the cutscene bars appear clearly grey. Also somewhat oddly there appeared to be a single line of pixels between the bottom of the faded out area of the screen and the lower bar where thrusterglows got rendered. So when properly piloted i could make that line flicker even though i had faded out screen with cutscene bars. |
|
|
Yeah, that line of visible pixels has been a problem with fade-out since it was implemented. Is it fixable? I'm pretty sure it's been brought up before but nothing seems to have come of it. Regarding the bars, what build are you using? I only started getting the problem with WMC's new camera build (http://www.hard-light.net/forums/index.php/topic,54045.0.html). |
|
|
Changing - even radically - the clipping limits didn't affect the visible thrusters at all.. As for the build. Fresh SVN build. As WMC has not uploaded that to SVN yet i don't get that error (i should have noticed it wasn't SVN build) so unless its somehow dependent on your system it is apparently a bug in his code. I committed a fix for the cutscene bar jerking though. |
|
|
Some notes for scaling: num = 2/[1-width/(height*aspect)], where num is the value that height ought to be divided by to get aspect. Aspect is in the format of (16/9), etc. - If width/height == aspect, then cutscene bars should not be drawn. - If num is negative, then width should be divided rather than height. (eg 4:3 on a 16:9 monitor) I would assume that width needs to be divided by abs(num), but I haven't checked this mathematically. In general I'm assuming that the aspect ratio that the FREDder expects should be used, rather than the aspect ratio of the monitor itself. This means that if someone has a 16:9 monitor, they won't see the black bars. I feel this makes it easier for the FREDder to act as a cinematographer and script in appearances of ships to coincide with musical cues and so on, rather than have to worry about the framing being different with differently shaped monitors. I've only skimmed this bug, but this is all due to a related conversation that Wanderer and I were having. |
|
|
I think the bars should appear regardless of the aspect ratio. To me their more important function is to indicate a cutscene rather than standardise the aspect ratio, although I can certainly see how that would be useful. Maybe there could be an optional argument in the SEXP to show them regardless of the monitor's aspect ratio? |
|
|
Should be fixed in C08062008 |
|
|
Tried it in a few resolutions, works great. I take it they no longer change the aspect ratio at all? |
|
|
Right. What I was doing was changing the clipping area - the area of the screen that's used for rendering. That gives you a bit of a speedup with cutscenes (or it should) since the game no longer has to render objects that aren't visible because of the black bars. Problem is, the rest of the game assumes the clipping area is going to be the entire renderable space, and adjusts, most noticeably, the background and probably other things as well. It could also cause trouble with RTT as well, if you had some reason to redirect the player's current view somewhere, you'd also get the black bars. So rather than fuss with that, which would be the best possible final solution, I just put black bars over everything. |
|
|
Sounds fixed to me. |
- Anonymous
