[peves]

Hey guys, I'm pretty new to SCP and I have encountered pretty annoying bug (I couldn't believe that it's the way it should be:)).. :

When rotating view/ship, some of the elements of the universe/background move like they are way more closer than they really should be..
Ex.: Star and background nebula: When i rotate view, the star moves faster than the nebula.. it looks like the star is half a kilometer from me and nebula is far far away..
Next things is, that it happens also with HUD.. I target ship, and the only time the center of "targetting box" is at center of the actual target is when i keep it in the center of the screen, other times it's just draped over.. !?

I believe it's not right, but I can't imagine I am the only one who noticed it.. it's literally driving me crazy :/ space feel is ruined
For you I hope it's only my problem, for me I don't

Using:
fs2_open_3_6_10-20071028T or fs2_open_3_6_9 - doesn't matter, does it with both..
with or without mediavps - doesn't matter..
all flags on, all flags off - doesn't matter..
OpenGL or Direct3D - doesn't matter..
GeForce Go 7400, Win XP

I couldn't find screenshot key, so I drew it in mspaint  , but it's the way it is....... 

[attachment deleted by admin]

[Herra Tohtori]

AFAIK this is a known problem (at least, it should be known - it has been mentioned often enough recently...) and has to do with how the retail stars and newer background images are rendered.

The way I understand it, the retail stars (with cheesy motion blur) are handled more like parts of the HUD than actual background elements. You might have noticed that for example subspace nodes on the HUD tend to also suffer from this attitude-pseudo-parallax bug or what ever it should be called.

Also, suns suffer from this perhaps the most of all background elements.


Currently the only thing we end users can do is to wish that someone fixes it at some point, of course preferably sooner than later. Hmh, I wonder if anyone has Mantised it, though...  Meanwhile, it's not like it makes the game unplayable.

[peves]

Oh my.. thanx for such a fast response.. I really searched this forum from the inside out and didn't catch a note of it, sorry:)
Now at least I know I'm not alone:)

And it kinda does.., if not mentioning moving stars, how am I supposed to be oriented in a space fight when hud draws boxes, lines and triangles whereever it wants to

Just can't understand that it's not fixed until now.. I mean.. It's somehow more important than shiny models and specular maps:)

[ARSPR]

It's not fixed because it's really difficult. (That's what coders say, not my opinion)

You have more info in this really old mantis report: Mantis 83

[peves]

Well I'm not much of a coder.. but this and hard? ) looks like a bit of high school math to me, doesn't it? ..and as long it's three years old and they(whoever it is) couldn't do anything..
Allright, I have to trust them.. and as #83 says: it's extremely annoying.. Who can orient in a world where distanced objects are acting like they are near??

[Jeff Vader]

Tell me, my good man. Are you playing in widescreen? That can also cause the targeting box issue, since FSO doesn't support widescreen properly. The easiest option is to play in 1024x768, so that black edges of varying size circle around the screen. At least that's what I do with my laptop that has a native resolution of 1280x800. The suns and star etc still move the wrong way but at least the hud works.

[Wanderer]

As for screenshot button - have you tried 'print screen' button...

It takes screenshots and saves them into 'screenshots' directory.

[peves]

Tell me, my good man. Are you playing in widescreen? That can also cause the targeting box issue, since FSO doesn't support widescreen properly. The easiest option is to play in 1024x768, so that black edges of varying size circle around the screen. At least that's what I do with my laptop that has a native resolution of 1280x800. The suns and star etc still move the wrong way but at least the hud works.

Oh my.... good man:) I knew I should at least give it a try, but until your suggest I didn't.. And what a surprise.. Either I got used to that ****ty persp. or now it works fine everything.. Really strange.. That hud disorder is gone and it seems like even suns and stars are moving well.. strange But really thanks..

After a closer look it's still not absolutely perfect, but with widescreen the displacement is ten times more visible.. Allright, but it kinda solves the problem... 
Now to deal with that issue of some white and some normal ships:)
EDIT: ...and some nontransparent sprites:(

[taylor]

Well I'm not much of a coder.. but this and hard? ) looks like a bit of high school math to me, doesn't it? ..and as long it's three years old and they(whoever it is) couldn't do anything..
Allright, I have to trust them.. and as #83 says: it's extremely annoying.. Who can orient in a world where distanced objects are acting like they are near??

It's not hard in a rocket-science sort of way but a this-is-going-to-take-for-damn-ever-to-get-right sort of way.  The engine was simply written for use with an orthographic view and the HTL code conversion just made part of the engine use a perspective view.  Everything needs to be converted in order for us to be able to properly match up the orthographic elements with the perspective ones.

[Herra Tohtori]

Would it be possible to offer a chance to reduce the number of retail stars to zero? That would take care of the retail stars being a problem, and quite honestly I've never liked the motion blur effect very much - and skybox stars are so much more shiny...

Also, it could perhaps be possible to apply hackish workarounds so that there is a star at location A on the background but with an empty (black or transparent) texture, and then add an image of the star as a nebula/planet bitmap.

It would according to my understanding *work*, the light from the star would still come from approximately correct region of space... and then all the background elements would be rendered in the same way. The problem with this approach is that it would be pretty hackish, and I'm not quite sure how the lack of sun glow texture would affect the look of the stars compared to current system. Also, when this finally gets fixed, we would have plenty of missions with hackish workarounds of an old problem...

Anyway, if that would work, it would only leave the HUD problems, but IMHO it shouldn't be surprizing that all elements of the HUD are not perfectly aligned to the objects of 3D environment... Even in FS2 era. 

[Mobius]

Would it be possible to offer a chance to reduce the number of retail stars to zero? That would take care of the retail stars being a problem, and quite honestly I've never liked the motion blur effect very much - and skybox stars are so much more shiny...

Definitely a good idea

Anyway, if that would work, it would only leave the HUD problems, but IMHO it shouldn't be surprizing that all elements of the HUD are not perfectly aligned to the objects of 3D environment... Even in FS2 era. 

Sometimes, the stars move strangely when the camera is turning. Their movement is indipendent from the one of planets and nebulae.

[Bob-san]

Would it be possible to offer a chance to reduce the number of retail stars to zero? That would take care of the retail stars being a problem, and quite honestly I've never liked the motion blur effect very much - and skybox stars are so much more shiny...

Definitely a good idea

Anyway, if that would work, it would only leave the HUD problems, but IMHO it shouldn't be surprizing that all elements of the HUD are not perfectly aligned to the objects of 3D environment... Even in FS2 era. 

Sometimes, the stars move strangely when the camera is turning. Their movement is independent from the one of planets and nebulae.

Interesting idea. But, what about converting everything that's been done so far so it has no problem?

[Herra Tohtori]

@Mobius:

From stars (the distant ones), only the retail stars are affected by this particular problem. Skyboxed starfield is rendered correctly in relation to planet and nebula bitmaps, mostly because they are images and not procedural like the retail stars.

The other background element aside from retail stars that is affected by this particular issue are obviously the suns.

Now, if the suns were converted to be rendered in the same way as the nebulae and planets, and the number of retail stars was reduced to zero, both of these problems would be out of our hair at least for the time being. But like I said, it would leave the HUD mis-alignment problems to be dealt with a code fixing solution, but I probably could manage with a little HUD problem if the background elements were not exhibiting same problems. Can't speak of others, though.


@Bob-san: about converting... You would need to:


0. Replace the sun textures with a transparent/black one (I can't remember if the system uses alpha or additive blending, but the idea is to make all sun textures invisible in the game itself)

1. create shiny new Sun texture, at least one for each colour, then add all to stars.tbl to nebula/planet section (and I have no idea if that table has some kind of entry limits or not)

2. Go through every mission, and add a new background element to all locations where there is a sun (with it's new invisible textures), so that the light of the star will still shine from the correct direction, but the actual visual effect of the star would be separate from the actual star.


Now, there are several sides to this kind of solution, and these are the main points I can think of:

The Good:

-It would fix the current problem with sun bitmap rogue rendering.

The Bad:

-Converting everything to this would take a lot of time and effort and I'm rather sure that most everyone would have better things to do with their time.
-After this issue perhaps gets fixed at some indeterminate time in future, it would likely mean that all the converted stuff needed be re-converted or "downgraded" to their old form to take advantage of the fixed star/sun/HUD rendering. More work, yay.
-Meanwhile, there would be hell to pay with supporting both old system missions and new "workaround"-missions.

-Extensive use of this workaround could actually discourage the actual fixing of the issue. It would make the symptoms go away as far as the background is concerned, but the problem would still be in the code, affecting only the HUD as it would appear to casual gamer.

The Ugly:

-The effect would be different from current sun effect in, for example, the way it actually would draw the texture. Currently, many star images have kind of "spikes" or light beams coming from the star, and as you rotate your ship they rotate with you, indicating them to be diffraction artefacts caused by the optics of the human eye or somesuch. If the suns were rendered as planets/nebulae, they would be fixed to the background.
-The effect would lack the glow texture that the sun bitmaps usually have. This is not an issue in itself, as with creative texture design it's quite possible to make "bright-looking" stars without any glow effect at all. I cannot say whether it would be better or worse from current, but it would be different for sure.
-IT'S A HACK. This is not an elegant solution, it's a cumbersome workaround to hide a problem.


Sooo... what gives? My opinion is that existing stuff shouldn't be converted to use this kind of workaround. I can deal with occasional goofy-looking stars, and I suspect most others can as well... However, new missions  could be made to use it to begin with, and they would still be compatible after the eventual fix gets made.

I guess it's up to FREDders then whether or not they want to do it or not.



But, at any rate - the ability to drop the number of retail stars to zero would be a welcome addition to the engine/FRED, especially since the stars look ridiculous when they are rendered over an image of a planet on skybox surface. Kinda makes it look like the shadow side of the planet is transparent.

[peves]

well, in my opinion.. rendering sun onto skybox(skyball? ) is an extremely stupid idea;)
also.. I love retail stars   

And... what's so hard about keeping HUD elements at the place where it's according 3d elements are? if you project 3d objects onto 2d screen, you just use the same screen coordinates (X,Y) ?! there's no space for errors like drawing target boxes somewhere else on screen...
Or am I wrong?

[Herra Tohtori]

well, in my opinion.. rendering sun onto skybox(skyball? ) is an extremely stupid idea;)

If you mean including the sun on actual skybox[sphere] texture, I agree, that would be dumb and you'd need a new skybox texture every time you change the sun... But if you refer to rendering sun in a similar fashion to planets and nebulae, I must ask why so?

And... what's so hard about keeping HUD elements at the place where it's according 3d elements are? if you project 3d objects onto 2d screen, you just use the same screen coordinates (X,Y) ?! there's no space for errors like drawing target boxes somewhere else on screen...
Or am I wrong?

From what I gather, the suns, retail stars and HUD still use more or less original retail FS2 rendering, which was apparently using ortographic view, whereas the new hardware transformlighting rendering engine uses perspective view in rendering. Or something to that effect, I'm not that well versed in the inner workings of the engine.

Anyway, the HUD system knows where the according 3D elements are, but the projection of that position to the screen would be different in perspective than it is in ortographic rendering, thus the slight difference in locations between the 3D object and it's HUD representation, the difference increasing towards the edges of the field of view.

You know, like when you have two tangential lines, they theoretically touch each other in the distance when using the perspective view, whereas when using the ortographic view, they stay more or less at same distance from each other. I'm sure the explanation to this problem is not quite that simple, but the principle is same - when using two different rendering modes, it's natural that things don't completely align with each others.


What is hard in fixing it... well, even my limited coding experience tells me it would likely be tedious to no end, as was already said:

It's not hard in a rocket-science sort of way but a this-is-going-to-take-for-damn-ever-to-get-right sort of way.  The engine was simply written for use with an orthographic view and the HTL code conversion just made part of the engine use a perspective view.  Everything needs to be converted in order for us to be able to properly match up the orthographic elements with the perspective ones.

So basically there's two ways to deal with the problem:

1. Make all graphical parts of the engine use same (perspective) view OR

2. Change all the offending graphical elements to be rendered by one single graphical part of the engine.


My cumbersome suggestion for a work-around uses the method 2 as far as background elements are considered, but can't deal with the HUD issues. Also, if someone really wants to keep the retail stars in business, it doesn't help that either.

[taylor]

All of the suggested "fixes" for this are pretty much crap so far.  It's obvious that few people actually understand what the actual problem is.

It's not an issue of simply converting everything to use the perspective view (which isn't possible anyway since all of the problematic elements will always be rendered with an orthogonal view), the issue is that all of the math is different between the two views.  The code has to be converted to use the same math for view setup regardless of it being an ortho or perspective view.  The best way to do that is via the graphics API, which means that this change was always dependent on supporting both OpenGL and D3D.  But as D3D is now officially dead, there is nothing stopping the changes being made, except for the time required to do it.

The problem with the stars, suns, HUD elements, death view, etc. is all caused by the EXACT same thing.  You can't fix one of them without it being a pathetic hack, so the only way to do it is to fix the root of the problem, which would automatically fix everything else.  But this requires a sizable rewrite/restructuring to do which is why it's "hard".

The problem is annoying to be sure (more so for us since nobody will stop complaining about it), but it doesn't prevent anyone from playing the game so it's not high priority, especially considering the effort involved in the fix.

[Herra Tohtori]

 

Hey, at least I have no illusions about my suggested workaround being hackish, cumbersome and (arguably) crap.

Although, I like to maintain the tought that I have in general terms some understanding what causes the problem - whether or not I can put it to tongue of humans is a different matter altogether.

I completely agree that making the symptoms (or part of them) go away is more of something that Microsoft would do *cough*vista*cough*, rather than a real solution to the problem. Kinda like hiding the most glaring security issues behind a dialogue that basically asks if it's all right to open this security hole, which makes it the user's fault when things go south.

I'm simply more or less blindly theorizing ways to make do what we got now - that is, if someone is really annoyed enough with the suns having apparent rogue parallax behaviour, they can make a mission where at least the sun(s) stay put as a background element like any other. Whether it's worth the trouble, I'd personally say no, it isn't. But people have been known to disagree with me from time to time.

As to what comes to zero amount of retail stars, that would actually have a much more valid reason to offer than the perspective problem - namely the fact that if you have a skybox where there's a planet image included, the stars will render on top of the planet, which is rather unrealistic even to most arcade-y of gamers...

[peves]

Noooow I get it!
Heh.. guys, thanks for helping me to understand the Problem.. this was the thing I at least wanted to do

[Nuke]

i made a lead indicator in lua which i havent been able to **** up no matter which resolution im using. i also solved it with 100% 2d math (its a math whore cause everything needs to be scaled in real time), i dont see why the same system cant be used in c. a good example is with the hud on my mouse script. notice its always a uniform size no matter what youre resolution is.

the lua function, getScreenCoords(), which projects 3d vectors onto the hud always assumes 640*480 or 1024*768 (i assume this is just a redirect to a c function in the game which the game uses to render its own hud internally). on init i check the screen width to see if its >=1024. if true it means im dealing with high res or vice versa. i divide the actual width and height values with either 1024 and 768, or 640 * 480 depending on which resolution mode im using to generate 2 values, hfactor and wfactor (i also keep an average of the 2 for procedurals that require strict proportions, and a bool to tell me if i use hires mode).

 

Code: [Select]

if w >= 1024 then
wf = w / 1024
hf = h / 768
awh = (wf + hf) / 2
hires = true
else
wf = w / 640
hf = h / 480
awh = ((wf + hf) / 2) * 0.625
hires = false
end
every time i want to use a coordanates returned by getScreenCoords(), i apply the factors to the reults.

Code: [Select]

xship, yship = target:getScreenCoords()
xship = xship * wf
yship = yship * hf
drawreticle(xship,yship)

and it will put those crosshairs on that target every time. of course this is all with the lua interface, i dont know what the engine looks like on the inside. and i dont know what parts of the hud are handeled in 2d and whats done in 3d. but somewhere the engine has to say, ok this is where the gauge goes. surely its possible to intercept that and apply this formula. of course this is probibly one of those pathetic hacks that taylor mentioned