SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

I think we should allow 512x512 and 1024x1024 in Orbiter. The latter would be much better for the PFD and HSI, the first one sufficient for rendering DPS screens.

256 x 256 makes little sense for us.

I don't think the resolution is configurable for each display...

 

[Urwumpe]

I don't think the resolution is configurable for each display...

No, its global... but maybe we could just stretch the DPS fonts to the larger resolution, should still look better than downscaling them to 256x256

 

[GLS]

No, its global... but maybe we could just stretch the DPS fonts to the larger resolution, should still look better than downscaling them to 256x256

That image still has a downscale of about 50%, and for 256x256 it is about 25%.

 

[Urwumpe]

That image still has a downscale of about 50%, and for 256x256 it is about 25%.

I know. but the real MEDS displays had a resolution of 1024x1024, that is the absolute hard limit anyway.

 

[GLS]

I know. but the real MEDS displays had a resolution of 1024x1024, that is the absolute hard limit anyway.

Yes it had. But how much will it cost to run SSU with the MFDs at 1024x1024? Or even at 512?
I think 512x512 will already look very good, and it is the cheapest "upgrade" available, so my vote is for that one, unless it shows itself to be too expensive.

 

[Urwumpe]

Yes it had. But how much will it cost to run SSU with the MFDs at 1024x1024? Or even at 512?
I think 512x512 will already look very good, and it is the cheapest "upgrade" available, so my vote is for that one, unless it shows itself to be too expensive.

Well, if we can delegate more work on the GPU, we have the needed "super computer" for that task right in every computer. Also if I remember correctly, we already used 512 x 512 in SSU by cheating orbiter a bit and use code from ExtMFD to increase the resolution slightly.

 

[jarmonik]

The performance impact can be tested with stock MFDs.

Technically, for the best MFD quality the size of the render surface should be equal to the size of the MFD visible on screen or a multiple of that. But that's not supported by Orbiter, at-least not yet.

I don't really know what could be accomplished with a programmable texture filters when rendering 1024 texture to a smaller rectangle on screen, Martin might have ideas. Linear filter is likely not the best.

Also, when drawing to 1024 surface the pen width should be at-least 3.0 to keep lines well visible and non-flickering.

I made some tests a while ago, if we create a mipmaps for MFD screens it does improve the screen quality when viewed from a distance.

 

[GLS]

Also, when drawing to 1024 surface the pen width should be at-least 3.0 to keep lines well visible and non-flickering.

Yes, that's why I think supporting only one resolution is better/easier. The alternative to that is to have 2 sets of code for each display for each resolution, and it's hard already keeping Sketchpad and GDI displays for the PFDs and DPS displays. :facepalm:

On the font side of things, I think we can load a specific font in GDI, in Sketchpad we can't, and in Sketchpad2 we can by using the '*'. So this still leaves us with the wrong font in the MDU maintenance and the subsystem displays.
A possible way to do this would be not to have any Sketchpad displays, keep the GDI ones for MOGE, and use Sketchpad2 for D3D9. If I'm correct, MOGE uses GDI, so this wouldn't lose any performance there. The bad news is that it would mean 2 sets of code per display. The good news is that they are all done, I just have to go back and retrieve the GDI ones.

 

[Urwumpe]

Can't we simply make things configurable for different MFD sizes?

I mean, it is all just the same algorithm, we just use different constants.

 

[GLS]

Can't we simply make things configurable for different MFD sizes?

I mean, it is all just the same algorithm, we just use different constants.

Other than keeping tons of variables for the coordinates, any ideas on how to do this?

---------- Post added at 03:24 PM ---------- Previous post was at 03:23 PM ----------

Adding a multiplier to the coordinates would be the easiest thing to do, but that won't allow precise placing of things .

 

[Urwumpe]

Other than keeping tons of variables for the coordinates, any ideas on how to do this?

I have about three to five ideas for that, the question is, how much beating from the rest of the team can I afford for my crazy ideas.

Adding a multiplier to the coordinates would be the easiest thing to do, but that won't allow precise placing of things .

Why not? A multiplier <1.0 should work fine.

 

[jarmonik]

On the font side of things, I think we can load a specific font in GDI, in Sketchpad we can't, and in Sketchpad2 we can by using the '*'.

The MOGE runs with an open source Sketchpad called GDIClient. You can edit it to accept the '*' override and distribute it with SSU. Or maybe Martin could include the change in Orbiter distribution.

EDIT: I suppose we could also include it in D3D9.

 

[GLS]

I have about three to five ideas for that, the question is, how much beating from the rest of the team can I afford for my crazy ideas.

Depends on how crazy those ideas are.

Why not? A multiplier <1.0 should work fine.

Because the line widths and font sizes will have to be different, and I'm sure there will be places where things won't line up correctly. And on top of a bigger (slower) display, it would add an operation for each coordinate... we could probably make it with a cheap shift-left or -right, but IMO it would still be not worth the gain.

---------- Post added at 04:00 PM ---------- Previous post was at 03:54 PM ----------

The MOGE runs with an open source Sketchpad called GDIClient. You can edit it to accept the '*' override and distribute it with SSU. Or maybe Martin could include the change in Orbiter distribution.

EDIT: I suppose we could also include it in D3D9.

Oh boy, more code :facepalm: :lol:.
The more I think about my GDI/Sketchpad2 idea, the better it sounds. It requires no more work from anybody except me :uhh:.

 

[Urwumpe]

Depends on how crazy those ideas are.

Crazy like a fox?

 

[GLS]

I'm still working on the (new) displays and font... still a few days away from having this pretty enough to show.
Anyway, small heads-up for the new panels: the bottom texture of the MDUs (for the menus) should be 60 pixels tall on a 512 pixel display. Currently it is equivalant to +/- 82, so it's a bit too tall.

---------- Post added 06-29-16 at 03:24 AM ---------- Previous post was 06-28-16 at 05:50 PM ----------

So, after a day spent carefully measuring everything to get one of the displays right, I realize that it doesn't look right... there's too much empty space in the bottom of the display. A quick check of the math used shows that any errors that might be present don't account for a space this big, so I decide to draw lines at regular intervals to see what is where. It then became clear that our MDUs don't have the correct aspect ratio. Because the menu area is "added" to the MFD area (square), and it all has to be square, this last one becomes squeezed vertically and still retains the full size. As a result, if a display is properly draw there will be an empty area at the bottom where the menu should go, but it is actually being drawn on the other texture.
This (finally) explains why the circles look like ovals. I thought it was due to the camera position looking down to the display (and also that I was going crazy :uhh.

Right now, the only thing I'm going to test is my pillow, but if testing tomorrow goes well I say we dump the menu texture and draw the menu as part of the display. But this will not show the button labels in any other display except ours........

---------- Post added at 02:27 PM ---------- Previous post was at 03:24 AM ----------

I did the changes to draw the menus directly on the display and it all seems to work as expected! The other MFDs still work and respond to the buttons, but now there's no indication of what each button does.
As a test to get a square display, I edited the coordinates of the display groups for both CDR MDUs. I copied the coordinates of the bottom 2 vertices of the label mesh to the bottom 2 vertices of the display mesh, effectively stretching it back to +/- a square. So the mesh group numbering didn't change I added the FLAG 2 entry to the label groups instead of deleting them.

If nobody has a problem with keeping these changes until the new vc comes online, I'll do them to the other MDUs, and then return to the "main road" and continue with the display/font changes.

 

[DaveS]

I did the changes to draw the menus directly on the display and it all seems to work as expected! The other MFDs still work and respond to the buttons, but now there's no indication of what each button does.
As a test to get a square display, I edited the coordinates of the display groups for both CDR MDUs. I copied the coordinates of the bottom 2 vertices of the label mesh to the bottom 2 vertices of the display mesh, effectively stretching it back to +/- a square. So the mesh group numbering didn't change I added the FLAG 2 entry to the label groups instead of deleting them.

If nobody has a problem with keeping these changes until the new vc comes online, I'll do them to the other MDUs, and then return to the "main road" and continue with the display/font changes.

I have no problems with this. I'm no big user of the regular Orbiter MFDs so losing the labels isn't a huge deal for me.

 

[GLS]

I have no problems with this. I'm no big user of the regular Orbiter MFDs so losing the labels isn't a huge deal for me.

ExtMFD still works, so all other MFDs are still "fully accessible and supported". In the vc they still work, the user will have to do things by memory. :shrug:

With this, the new MDUs will only have one (square) mesh/texture, so please disregard my previous post asking for a 60 pixel tall menu texture.

 

[GLS]

Anyone know a way to set the width of a font in Sketchpad? In GDI there are parameters to set both height and width, but in Sketchpad there's only width...

 

[Urwumpe]

Anyone know a way to set the width of a font in Sketchpad? In GDI there are parameters to set both height and width, but in Sketchpad there's only width...

What about choosing a fitting font?

 

[GLS]

What about choosing a fitting font?

I'd have to make it...