Space Shuttle Ultra development thread

[Urwumpe]

Yes. Maybe it's time start implementing some of the MEDS screens into CRTMFD? Or should we rename it to SSU_MEDS_MFD?

Also, we can fix up the SPI screen and make it work like outlined on page 65.

Should be possible, but I am very unhappy with the MFD screen resolution of 256x256.

I have two options:
- we just extend CRT MFD, even if it's impossible to increase the MFD screen resolution to something more readable. Maybe rename it MDUMFD.
- We replace the label texture and the MFD rectangle with dynamic textures and do the MFD painting directly inside the Atlantis DLL. The most realistic solution, but also the solution where we have to do too much ourself. (I don't want to do such a large change after the rescaling, better add some new features now.)

Alternative: We do 1 first but design the code with a change to 2 in mind. For example increasing the size of the label texture rectangle, and paint labels, MDU menu and Fault line on it in form of a simulated MDU.


Donamy: Can you repaint the textures to the new labels (e.g. GPC/CRT -> IDP/CRT)

 

[DaveS]

Alternative: We do 1 first but design the code with a change to 2 in mind. For example increasing the size of the label texture rectangle, and paint labels, MDU menu and Fault line on it in form of a simulated MDU.

This one seems to hold the best possibilities as we don't box ourselves into a corner like options 1 and 2. That we could test the approach first without commiting ourselves to any specific approach.

 

[Urwumpe]

OK, so I suggest, for performance testing, we implement each label/menu area as the lower part of a separate 512x512 texture. If we can have this on normal hardware, it should also be no problem once we paint on it. The transfer between CPU memory and GPU memory will be the worst problem.

Maybe we can even implement a back buffer using the OrbiterSDK, I have the feeling it is possible, but have not yet tested it. If it is possible, we can paint the CRTs in sequence and only exchange the textures once every 0.25 seconds.


If this is still too slow, we can go back to mapping all MDU menus on a single texture.

 

[DaveS]

I have some progress on the concrete hardstand recently. Still a long from completion though.

 

[computerex]

- We replace the label texture and the MFD rectangle with dynamic textures and do the MFD painting directly inside the Atlantis DLL. The most realistic solution, but also the solution where we have to do too much ourself. (I don't want to do such a large change after the rescaling, better add some new features now.)

Do you mean somehow getting the device context from the MFD, resizing it, then painting it or do you mean getting rid of the MFD altogether and creating your own interface? The first one if possible would be much easier to do, as the external MFDs do something like that, however the latter would definitely affect the FPS. My experiences with dynamic texturing have been...interesting.

 

[Urwumpe]

I have some progress on the concrete hardstand recently. Still a long from completion though.

Well, it is already possible to imagine how it will look like on a good ground texture. Could get fun to see.

 

[Urwumpe]

Do you mean somehow getting the device context from the MFD, resizing it, then painting it or do you mean getting rid of the MFD altogether and creating your own interface? The first one if possible would be much easier to do, as the external MFDs do something like that, however the latter would definitely affect the FPS. My experiences with dynamic texturing have been...interesting.

I mean drawing on a dynamic 512 x512 texture by code inside MGAtlantis.dll, instead of using the MFDs, which are practically drawn on dynamic 256x256 textures.

256x256 would be more comfortable for older hardware, but I have doubts they would like the rest of the VC.

My main problem with 256x256 is, that we have to use fonts which are 5 pixel wide, which is hard to read.

 

[computerex]

This will be interesting. Could the refresh rate be configurable by the user? Better yet, could it correspond with the refresh rate set inside the Orbiter launchpad? I wouldn't want to do it though, doing mouse click events inside VCs are cumbersome.

 

[Urwumpe]

This will be interesting. Could the refresh rate be configurable by the user? Better yet, could it correspond with the refresh rate set inside the Orbiter launchpad? I wouldn't want to do it though, doing mouse click events inside VCs are cumbersome.

I could access Orbiter.cfg and read the parameter.

But I would prefer keeping the VC rendering settings different to the Orbiter MFD settings (especially because of the different rendering methods). In orbit for example, we could live very well with only 1 update per second (in fact, most values of the Shuttle are only updated once per second).

 

[SiameseCat]

There is an oapiGetDC() function, to get the HDC for a surface. This could be used to replicate the MFD functionality. We might still have sizing problems, though. Also, I'm not sure if we could do this and have dynamic texturing.

 

[ryan]

Hey guys I was wondering could there be some day there would be all the switchs are working with effects on the spacecraft, or is that to much becuase theres to many.

 

[Urwumpe]

Hey guys I was wondering could there be some day there would be all the switchs are working with effects on the spacecraft, or is that to much becuase theres to many.

The number of switches is finite. And so is the number of parameters, we can have effect on. The shuttle only measures around 2500 values. :rofl:

Well, I at least hope for more switches working as in the old Shuttle.

SiameseCat: Sizing should be no problem once we use fixed texture sizes. I think 512x512 is good enough, the real MDUs have a screen resolution of 1152 x 1152, from what I can decypher.

Also GetDC should work with dynamic textures - that is its purpose. But I don't know if create surface also works for replacing textures.

 

[Donamy]

Urwumpe,

What do you mean, repaint the textures, to the new labels ?

 

[Urwumpe]

Urwumpe,

What do you mean, repaint the textures, to the new labels ?

Currently, we show only one line of 6 labels (MFD button labels). In the real shuttle MEDS, its three lines, which are framed by status information. The lines are fault line, menu title and "edge key labels" - our buttons.

If the MFD is used by CRT MFD, we could make it paint the realistic MEDS labels this way, otherwise, we just show the title of the other MFD.

 

[Donamy]

Something like this ?

.

 

[Urwumpe]

yes, but with one difference - it's 11 MDUs. Also the edge key menu labels could be a bit higher, for fitting two lines into them. The blue lines could also be a tiny bit thinner.

 

[DaveS]

I was just thinking: would be possible to add the ET cam view to SSU? A secondary view could be the STS-112 ET cam view from the ET LOX cabletray instead of from inside in the ET LOX feedline fairing as it has been since STS-114.

 

[Urwumpe]

I was just thinking: would be possible to add the ET cam view to SSU? A secondary view could be the STS-112 ET cam view from the ET LOX cabletray instead of from inside in the ET LOX feedline fairing as it has been since STS-114.

Should go, but I would recommend making it separate from the normal VC view mechanism, for example using a different keyboard command. It's not like we need this view all the time.

We could use a CTRL + key binding for switching to a ET camera VC view and define the neighbors as such, that left and right move between the ET cameras and up and down go back to the normal VC mode again.

When the ET is separate, we could use this key binding for the Payload bay cameras. This would make the orientation in the VC simpler and we could use more VC positions for work stations.

From reading the MEDS stuff - had there been a replacement for the MMUs I did not get aware of? It mentions a MSU for loading MDU formats, which is a standard term for a mass storage unit.

EDIT: I just found out we still paint on the wrong texture for R13L. Fixing it.

 

[Donamy]

yes, but with one difference - it's 11 MDUs. Also the edge key menu labels could be a bit higher, for fitting two lines into them. The blue lines could also be a tiny bit thinner.

Dennis ,

I emailed you the new one with eleven slots.

 

[SiameseCat]

Any idea when the displays will be ready? I could do some work on CRT MFD, but ther's not much point if the display functions are being changed. Also, how should the RMS be controlled? I'm looking at using fake thrusters to rotate/translate the arm.