Klauss' new GUI for cockpits, bases, etc.

[chuck_starchaser]

Of interest to modellers, like how to prepare surfaces for displays and stuff.
Klauss wrote a wiki about it; it's here
http://vegastrike.sourceforge.net/wiki/ ... e:Docs:GUI

[chuck_starchaser]

Klauss, what does this mean?

* Do not reference texture targets inside a texture target. I need not say, you mustn't reference the texture target you're rendering... but might (although not recommended) reference others.

I'm just not getting what you mean by "reference".

Also, you seem to worry about MIP mapping, but I would have thought for cockpit displays we'd use bilinear filtering... Isn't it expensive to generate new mipmaps with every texture update?

[klauss]

Many cards support hardware-assisted generation of mipmaps, with little overhead (some, though).

For cockpits, you may use bilinear, but you may not. When the thing gets mapped to a 3D object, it is subject to all the usual filtering decisions. So, you choose: use bilinear, or mipmapping. If you choose mipmapping, you should follow those guidelines.

About referencing... well... since dynamic textures are defined throughout the whole execution, you may want to reference - that is, use - say, VDU0 from GAUGES, or VDU0 from VDU1. Like drawing a rectangle using that texture. It is very tricky and probably not worth it achieving consistent results: you have to use them in the proper order, blah blah... plus, I really don't think you even can use VDU0 to render into VDU0... but if you can, it implies creating a snapshot of the texture target prior to starting rendering internally quite certainly, so it is rather inefficient.
Hence... do not do that.

Safest way to avoid that, is not placing sub-picture VDUs. Not using render-target in render-target. Rather... if you want sub-picture VDUs, place a camera viewport.

[chuck_starchaser]

I'm still lost, as I don't see how I *could* reference one texture from another. In practical terms for a modeller, are you saying the material for a gauge, in the .mtl file, should have a blank in the texture name field?

[klauss]

Imagine you used a .mtl file to specify items in a GUI layout (which you won't). Since dynamic textures are just like normal textures, you could do:

MAP_KD light.png

just as you could do

MAP_KD autotextures/vdu0

The latter you shouldn't... even if you could perhaps get away with it (ie - it would perhaps work). The ever-so-present perhaps is the problem: depends on tiny implementation details whether you can or can't with that particular texture - another may behave differently.

[chuck_starchaser]

Ah, I get you now.

Can you dynamically switch which dynamic texture to map? As in, if you have three VDU's say, one which you can control what to display on, directly, and the others acting like a shift register, displaying the last info screen in the previous vdu?

[klauss]

Interesting.

There would be a way to accomplish what you say... reorganizing the VDUs to swap their content. It's not as hard as it sounds, since the whole GUI is organized in layouts and layers.

In fact, I could make something very much equivalent possible by automating that task. Kind of Layout::swapTargets("vdu0","vdu1").

[chuck_starchaser]

Also, don't forget the feature we once thought of: being able to rotate dynamic texture uv coords to simulate temporary loss of vertical synch, when you get hit by an EM weapon.

[hellcatv]

that'd be elite

and I'm sure (being the proponent of realism as you are chuck) you'll demand the same effect on the "Window" to the world (which is also a sensor)

[chuck_starchaser]

that'd be elite

and I'm sure (being the proponent of realism as you are chuck) you'll demand the same effect on the "Window" to the world (which is also a sensor)

No, it aint!

[klauss]

that'd be elite

and I'm sure (being the proponent of realism as you are chuck) you'll demand the same effect on the "Window" to the world (which is also a sensor)

Possible.
Tricky, but possible.

[chuck_starchaser]

Might as well say that everything is a simulation, and pick a refresh rate the monitor doesn't support...

[klauss]

If it wasn't for modern monitors turning your screen black on such cases, I would give that one some serious thought.

[chuck_starchaser]

Allright, then, every time a missile hits you, send the monitor a degauss command...

(this is hopeless...)

[Halleck]

Haha... hardware-wrecking realism for the win!

[Ryder P. Moses]

And when your ship is about to blow up, the game sends commands to your BIOS to turn off all the fans! Realistic smoke and fire to accompany the explosion!

[chuck_starchaser]

Before that, we could send the speakers a signal strong enough to decone them and then fry the moving coils, to simulate blowing off of the ear-drums, and consequent permanent loss of hearing.