[Dragon]

The code could probably be based on current mission-based mainhall switching.

Err... not really.  The mainhall switching code is separate to the code that manages the two supported interface resolutions (640x480 & 1024x768).

Ah, so in that case, why not expand the code that supports those two? TBH, I totally forgot it was there besides the mainhall, but FSO already has (and had since retail) a way of supporting two different resolutions, for all interface bitmaps. While three aspect ratios would be needed to cover everything, there is some sort of code in there that perhaps could handle it.

Though on the other hand, we did have it since retail, and I don't think it was touched since then. This tends to mark Codethluthu lairs, from what I've gathered. Still, I suppose some of that code might be of use. Eh, I wish I knew more about "proper" languages, not only Mathematica and LaTeX. If I make it through those exams somehow, it's possible that I'll have some sort of course in C during my second year. Maybe then I'll be able to help more with it.

[The E]

There are two layers to the interface issue. You are talking about the frontend one, the one that decides what to show the player.
The issue with interface scaling however lies on the backend layer, the one that decides how something will be shown. Something that controls behaviour in one layer should not interact with anything on the other; the two should be as separated as possible.

[karajorma]

To be honest, I'd rather see us move to a system where we simply use a table to decide where the hotspot areas are, rather than the archaic method we use now. I've been looking at rewriting the loadout code but I find my work heavily constrained by the fact that I have to support the old system.

What we'd need would be

1) A default table (based on FS2's default layout)
2) A way to parse other layouts from the image they use to the newer table format (to support older mods and TCs)


the advantage of a table system is that you'd only need a few layouts (4:3, 16:9, etc) to support everyone. It would also be analogous to current way we handle HUD layout so it would make an easier learning curve for new modders.


I've been seriously tempted to write such a system (cause of the loadout issues) but it would probably be better coming from someone more familiar with the graphics code.

[Bryan See]

May I ask, what is your experience with C/C++?

My experience with C++ is from several institutions e.g. Tunku Abdul Brahman College and Universiti Putra Malaysia, and more than a decade ago. I agree with karajoma that the load out system should be reworked.

[karajorma]

There are very few parts of the engine that shouldn't be rewritten. The issue is what is a priority and what can we live with for now.

My issue with the loadout screen is that it's been the source of a large number of bugs over the years and that it's very restrictive in what it allows. The only reason I haven't completely rewritten it already is that it would require the changes I mentioned to snazzyUI.

[Bryan See]

Then you strongly propose rewritting the loadout screen, as well as the fix of wide screen aspect ratio in briefings, tech room and so on.

[mjn.mixael]

Well, after having personally handled the new HUD code pre Yarn's patches and then also working with the new HUD code post Yarn's patches... I would prefer not to have to write tables for every resolution ever. I did that with the HUDs and it was a PITA anytime I wanted to make a change that affected the HUD.

I fully realize it's more of a complaint than a logical argument. I'm mostly saying that I'd like to make conversation to see if we would be able to find a better way that to have to table Interfaces for every (or most) resolutions.

[Mongoose]

Theoretically couldn't one develop a system that used relative coordinates, so that you'd only have to make separate tables for each aspect ratio instead of resolution?  From what I can tell that's how Yarn's updated HUD code handles things.  (I say this realizing it'd probably be a massive pain in the ass to do so for the interface, though.)

[mjn.mixael]

Yarn's HUD code doesn't even require Widescreen vs Fullscreen designation for all but the most fringe cases, as I recall from when I setup MediaVPs 2014 and BtA.

[The E]

Yeah, I think that if this is going to happen, we're going to implement it in such a way that the amount of duplicate definitions needed is drastically reduced. Like this, for example:

Code: [Select]

$Button
   $Coords: (x, y)  ;;default coordinates if no matching ones for the current aspect ratio can be found
   +Aspect Ratio: 16:9
      +Coords: (x, y)
   +Aspect Ratio: 4:3
      +Coords: (x, y)
   $Action: some_action
   $Default Image: awsmbutton.png
   $MouseOver Image: awsmbutton_hi.eff
   $MouseClick Image: awsmbutton_cl.png
I know that Yarn's hud rewrite doesn't require this dance, but there may be points where it would be benefitial to have the ability to define something like this for the interface. Alternatively, we could just let the tabler set an aspect ratio globally for his interface, and then just apply scale-to-fit.

Point is, there's a bunch of options we could pursue, but I think the overriding concern will always be to hide as much complexity as possible.

[karajorma]

I think doing it by aspect ratio would be the most sensible way to solve the problem. I was under the impression the HUD fix did that. If not, why not?

[mjn.mixael]

The first HUD fix did need aspect ratios to be defined. After Yarns patches, you define positions by screen percent rather than pixel location and the code does its best to place them on all aspect ratios based on the percentage. You can certainly be more accurate by creating HUDs for each aspect, but its not required anymore.

[karajorma]

Do you think something like that would work for the rest of the interface?

[mjn.mixael]

Honestly, I can't really answer that question. I have no idea what kind of crazy math goes on in the background with Yarn's HUD patches. As a modder, I would hope so.. because I've experienced first hand what it's like to keep up with lots of duplicate table entries for different resolutions. I don't necessarily look forward to that for something even more complicated, like the Interface.

However, I will say if it were between having to deal with duplicate entries or no upgrades at all.. I'd root for the former.

[ngld]

I've been experimenting a bit and finished a (simple) implementation of an unstretched interface.
For every element you can specify the distance to the top, right, bottom and left edge (in relation to its parent). If you want to have a button appear at the lower right, you can set bottom and right to 0. If you want an element to appear at (10, 20) you have to set left to 10 and top to 20. You can set pixel values or percentages (which are relative to the parent element's size).
Right now I've implemented four kinds of elements: Box, Text, Image and Button.
A box can have a background color, border and a fixed size.
A text element displays text. You can set a fixed width which will make the text wrap or let the engine calculate the width (and height) of the text content. You can also change the text font and color.
An image element displays an image (duh!) and can be stretched.
A button has three images: normal, hover and clicked (it can also be stretched).

All settings are optional but every element has to have at least two coordinates.
A simple screen with a background, a logo, a button and some text would look like this:

Code: [Select]

#Interface Start
$Name: Example_Screen
[
  $Image: background_image
    +Stretch
    +Top: 0
    +Right: 0
    +Bottom: 0
    +Left: 0
    [
      $Image: logo
        +Top: 10
        +CenterX
      $Text: I'm an example text to demonstrate this...
        +Top: 10%
        +Left: 20
        +Right: 20
      $Box
        +Autosize
        +Bottom: 0
        +Right: 0
        [
          $Text: Commit
            +Top: 0
            +Left: 0
          $Button
            +Top: 10
            +Left: 0
            +Image: accept-normal
            +HoverImage: accept-hover
            +ClickImage: accept-click
        ]
    ]
]
#Interface End


NOTE: I used the multiplayer symbol as the logo, the fictionviewer as background (that's why there seem to be two buttons).
"+Autosize" means the engine calculates the box's size itself (I guess I should make that the default when only two coordinates and no fixed size are given.).
"+CenterX" and "+CenterY" center an element along the X or Y axis.

The hover and click effects for the button already work. What do you think so far? Is the table format too complex?

[Axem]

This is pretty cool.

And also slightly distressing! I was making my own LUA UI stuff for interfaces and stuff and then you come in with this.

(Still this is very awesome and I wish to see more! MORE!)

[karajorma]

This sort of thing should definitely be handled by the engine rather than lua though. It's one thing for something like the mainhall, but something like loadout would be incredibly complicated to handle via scripting.

[Axem]

Oh I totally agree. Native code is always better than hackish scripting trying to emulate native code.

[karajorma]

Well in the case of the loadout, I don't think it would even be possible. So much is hardcoded there.

Which is why I'm very interested in ngld's changes.

[ngld]

I added text boxes, transparent colors (alphacolor) and animations.

The code is now on github. The important parts are in code/menuui/tblui.cpp.

If you want to create your own ui tables, just drop them in the data/tables folder and put something like the following in scripting.tbl:

Code: [Select]

#Conditional Hooks
$State: GS_STATE_TECH_MENU
$On State Start: [
    ba.readTblui("ui-test.tbl")
    ba.openTblui("Example")
]
#End

EDIT: Added tags to the text renderer. Now you can write i.e. "This is {blue}some blue text{/blue}." or "This is {color #00000}black text{/color}.". I also added a a {font ...} tag.