Space Shuttle Ultra 3.0 released!

[GLS]

...aaaand...: Thanks to using a better compression (7zip I think you've used) the ZIPs
size went down from 170 MB (rc2) to 76,8 MB.
As you see, I like little improvements as much as the big ones
Thanks,
Kuddel

AFAIK nothing changed in the compression, we just removed some big documentation from the package and moved it into a download page in sourceforge. There's a link in the manual.

 

[Urwumpe]

AFAIK nothing changed in the compression, we just removed some big documentation from the package and moved it into a download page in sourceforge. There's a link in the manual.

Yes - if you followed the release candidates, which had been all in 7z, the file size changed with the cleanup for release. :lol:

 

[kuddel]

Thanks for the info, boys.
I fully support the decision to split SSU & Additional-(SSU-)Documents
:thumbup:

 

[asdad]

Urwumpe : Any news about save state of MPS ?

 

[GLS]

Urwumpe : Any news about save state of MPS ?

I'm working on that now, but it will only be available for the next major version of SSU (v4.0).

 

[asdad]

Ok i'll waitting

 

[White Owl]

I really like the looks of this hugely detailed addon, and am slowly trying to learn how to use it. How do I rescale the custom MFD pages to fill the whole MFD screen? The default is in one corner of the MFD screen , and so small much of the symbology is illegible. I must've installed something wrong?

 

[Urwumpe]

I really like the looks of this hugely detailed addon, and am slowly trying to learn how to use it. How do I rescale the custom MFD pages to fill the whole MFD screen? The default is in one corner of the MFD screen , and so small much of the symbology is illegible. I must've installed something wrong?

Can you provide a screenshot of the problem?

 

[GLS]

I really like the looks of this hugely detailed addon, and am slowly trying to learn how to use it. How do I rescale the custom MFD pages to fill the whole MFD screen? The default is in one corner of the MFD screen , and so small much of the symbology is illegible. I must've installed something wrong?

Are you talking about the ExternalMFD? Could you provide an image of what you see?

 

[White Owl]

Yes, here's a screenshot.

None of the other MFDs in this install have this problem. The in-cockpit view works okay, except of course for the very low resolution, but I understand that's an Orbiter limitation.
Thinking about it, I have a whole pile of addons that were installed a couple years ago and promptly forgotten... I'm thinking I should do a fresh install with just SSU and the required dependencies, then see how it looks.

 

[Urwumpe]

Yes, here's a screenshot.

None of the other MFDs in this install have this problem. The in-cockpit view works okay, except of course for the very low resolution, but I understand that's an Orbiter limitation.
Thinking about it, I have a whole pile of addons that were installed a couple years ago and promptly forgotten... I'm thinking I should do a fresh install with just SSU and the required dependencies, then see how it looks.

Ah, like I expected... generic cockpit mode was never really supported by us yet, only the VC mode. After all, you also need to access the switches in VC for controlling it.

I could imagine that in future versions, we might even disable generic cockpit mode, since it is pretty much unusable.

 

[GLS]

Yes, here's a screenshot.

None of the other MFDs in this install have this problem. The in-cockpit view works okay, except of course for the very low resolution, but I understand that's an Orbiter limitation.
Thinking about it, I have a whole pile of addons that were installed a couple years ago and promptly forgotten... I'm thinking I should do a fresh install with just SSU and the required dependencies, then see how it looks.

It looks like that because those displays were made for use in the virtual cockpit.
The current resolution is what Orbiter allows (it will look much better in the next Orbiter version).

 

[White Owl]

Okay, that all makes sense.

 

[DaveS]

Yes, here's a screenshot.

None of the other MFDs in this install have this problem. The in-cockpit view works okay, except of course for the very low resolution, but I understand that's an Orbiter limitation.
Thinking about it, I have a whole pile of addons that were installed a couple years ago and promptly forgotten... I'm thinking I should do a fresh install with just SSU and the required dependencies, then see how it looks.

What you're seeing there is the low resolution of the VC MFD texture in full effect. The CRTMFD modes should not be used outside the VC.

 

[martins]

How hard would it be to scale these MFD modes to arbitrary display resolutions? Is it more complicated than scaling every pixel coordinate with a global scaling factor?

Designing everything to a fixed resolution could be a problem if users will be able to select different texture sizes for the VC MFDs. Also it means that you now have to re-design the whole layout, instead of just changing the scaling factor.

 

[GLS]

How hard would it be to scale these MFD modes to arbitrary display resolutions? Is it more complicated than scaling every pixel coordinate with a global scaling factor?

Designing everything to a fixed resolution could be a problem if users will be able to select different texture sizes for the VC MFDs. Also it means that you now have to re-design the whole layout, instead of just changing the scaling factor.

When I did the A/E PFD (the display with the 8-ball), I thought of doing that, but that display has tons and tons and tons of stuff (and it's still not finished), and it is in the critical path of display performance. Adding the scalling would make it work on every resolution, but it would also mean lots of extra operations to convert the all the points, thus a drop in performance. On the rest of the displays it wouldn't hurt as much, as they are much more simple. The whole display system in SSU is due for updates in the near future, we'll see what happens then.

 

[Urwumpe]

How hard would it be to scale these MFD modes to arbitrary display resolutions? Is it more complicated than scaling every pixel coordinate with a global scaling factor?

Designing everything to a fixed resolution could be a problem if users will be able to select different texture sizes for the VC MFDs. Also it means that you now have to re-design the whole layout, instead of just changing the scaling factor.

Not really hard. The actual Space Shuttle software was drawing vector graphics, not bitmaps, so the display resolution is not that important, except having a good minimum to allow reading the text. Also the rendering of the displays will be changed towards such a system along the road to 4.0.

The biggest performance issue would be rendering text, which is very slow using GDI.

 

[martins]

When I did the A/E PFD (the display with the 8-ball), I thought of doing that, but that display has tons and tons and tons of stuff (and it's still not finished), and it is in the critical path of display performance. Adding the scalling would make it work on every resolution, but it would also mean lots of extra operations to convert the all the points, thus a drop in performance. On the rest of the displays it wouldn't hurt as much, as they are much more simple. The whole display system in SSU is due for updates in the near future, we'll see what happens then.

Well, if SSU is designed to run exclusively with VC, then it's probably just a choice between texture sizes 256, 512 and 1024. So the scaling there could be simply done by right shift operations in integer arithmetic, from the coordinates designed for the highest resolution. That should be really fast, unless you have 10000s of coordinates to scale.

Scaling to arbitrary sizes would still be more elegant, but this could be a halfway solution.

 

[Urwumpe]

Well, if SSU is designed to run exclusively with VC, then it's probably just a choice between texture sizes 256, 512 and 1024. So the scaling there could be simply done by right shift operations in integer arithmetic, from the coordinates designed for the highest resolution. That should be really fast, unless you have 10000s of coordinates to scale.

Actually, if scaling 10000s of coordinates, the normal linear multiplication could be faster by SSE - most better compilers do that already automatically.

Also for a modern CPU, the difference between shift and integer division is no longer existing, both need maximal a single cycle to execute. Of course, in terms of hyperthreading, branch prediction and other details, the shift solution is still better, but also an unnecessary optimization before finishing a feature.

 

[asdad]

Next Revision Please ?