Non-standard aspect ratio - now solved for Fighter HUD

[Cody]

I know that I’ve griped about this before, but it’s very mildly irksome.

Why doesn’t Oolite 1.73 onwards like 1280x1024 in full screen mode? The gap under the HUD is getting to me.
Even the standard HUD is the same. It puts the bottom message line too close to the top of the HUD, and just does not look right.
Everything else is great, and it doesn’t affect gameplay, but…

I do not like to play in Windowed mode, which cures the problem.
My only solution is to change my display every time I want to play Oolite (the lower choice offered by Oolite is not good),
and then change it back again. Not satisfactory. It’s the same in trunk (r2626).

I understand that this is a “non-standard” aspect ratio but in 1.72.2 there was no problem.
I can’t be the only one using a 1280x1024 monitor, can I?
Or am I the only one to have this very minor problem?

If I am the only one, then please ignore this post. If not, is there any hope in the MNSR? Or beyond that, even?



Regards

[Screet]

Why doesn’t Oolite 1.73 onwards like 1280x1024 in full screen mode? The gap under the HUD is getting to me.
I understand that this is a “non-standard” aspect ratio but in 1.72.2 there was no problem.

1280*1024 is one of the most common resolutions, as it's standard for 19" TFT screens. Surely, now widescreen is coming more and more into the market and TFTs got cheaper, thus often providing higher resolutions nowadays, but most people I know did end up with 19" when they became affordable - and that's simply their native resolution.

Interestingly, I never noticed there would be something wrong with how Oolite is using it in fullscreen before reading your message

Maybe the reason is that I use the standard HUD and that it's floating a few cm above the bottom never did look too wrong (while other HUDs with more graphical content surely would look strange).

I can very well imagine that there are several developers running that resolution and simply never noticed that there would be a problem...

Screet

[JensAyton]

HUDs are laid out in a 640×480 point coordinate system, and therefore assume a 4:3 aspect ratio unless the designer puts content outside the “board”. If the screen/window aspect ratio is not 4:3, the content area is scaled to fit inside the screen, so that no information ends up off-screen. For wider aspect ratios, that means padding is added to the left and right. For narrow aspect ratios, it means padding is added to the top and bottom.

This behaviour has not changed since 1.72, and there is no way to change it without breaking existing HUDs.

[Screet]

For narrow aspect ratios, it means padding is added to the top and bottom.
This behaviour has not changed since 1.72, and there is no way to change it without breaking existing HUDs.

Really not possible? Padding top and bottom seems strange to me...why not padding at top only? I don't recall any HUD that's reliant on the top position, but all I know depend upon the bottom position...

Screet

[Cody]

Hi Ahruman.

Fair enough, you'll not hear another word from me on this subject.
Thanks for the explanation.


Regards

[JensAyton]

For narrow aspect ratios, it means padding is added to the top and bottom.
This behaviour has not changed since 1.72, and there is no way to change it without breaking existing HUDs.

Really not possible? Padding top and bottom seems strange to me...why not padding at top only? I don't recall any HUD that's reliant on the top position, but all I know depend upon the bottom position...

The one used by default in OSE puts a sprite under the crosshairs. This would be misaligned if the HUD was shifted down.

[pmw57]

For narrow aspect ratios, it means padding is added to the top and bottom.
This behaviour has not changed since 1.72, and there is no way to change it without breaking existing HUDs.

Really not possible? Padding top and bottom seems strange to me...why not padding at top only? I don't recall any HUD that's reliant on the top position, but all I know depend upon the bottom position...

The one used by default in OSE puts a sprite under the crosshairs. This would be misaligned if the HUD was shifted down.

So the solution here is to plan for a future fix, where sprites for the crosshairs can be defined separately from the hud. If the separate sprite for the crosshair is defined then it's a straight-forward top-only padding.

Then, work with the OSE developer to come up with a solution.

After the the OSE update has been out for a couple of code releases, apply top-padding to all huds.

[Kaks]

If I may: from a developer point of view this whole thread is plain weird.

The graphical issues experienced by El Viejo are a direct result of the way the HUD of his choice was designed: it was drawn without taking into account all possible height/width display ratios.

The way Oolite is displaying HUDs is to centre them to the centre of the screen.

To coin a phrase, making the centre of the screen not the centre of the screen, doesn't make any sense to me.

Of course, if you feel that strongly about having an off-centred centre of the screen, you can always patch the game, and submit a patch. If it doesn't actually break things in any of the supported platforms, sure, we'll consider adding the patch to the codebase.

Oolite has had the same centered centre of the screen behaviour since it's been able to go full screen. The same HUD El Viejo is using now looks exactly the same with 1.73 as in any other version that can display it.

El Viejo, and anybody interested, have a look using 1.65 and see for yourself. I've no idea why you never noticed that gap in 1.70 through to 1.72.2 but it was there all the time.
Again, don't take my - or Ahruman's - word for it. Check for yourselves.

The Fighter HUD wasn't designed with 1280x1024 in mind.

This might sound weird, but why not change that specific HUD's design, instead of asking us to change the way Oolite handles different display resolutions across 3 different computer platforms?

[pmw57]

This might sound weird, but why not change that specific HUD's design, instead of asking us to change the way Oolite handles different display resolutions across 3 different computer platforms?

That's a good question. I'll shall try to provide a worthy answer.

Nobody wants the crosshairs at the centre of the screen to move from where they are.

My idea is to allow hud designers to be capable of accommodating multiple aspect ratios, by being able to create the graphics for the crosshairs area separate from the hud area.

The intention being to "untie" the existing OSE hud design so that no matter how the aspect ratio changes, that the graphics for the crosshairs can be allowed to stay in the middle, and the graphics for the hud stay at the bottom of the screen.

[Kaks]

So the solution is to redesign the HUD!

If anyone wants to also redesign the way Oolite uses HUDs, this is an open source project, there's nothing to stop anybody from doing so!
I'm already looking forward to seeing a working patch to Oolite's codebase!

edit: of course, as Ahruman pointed out already, the Oolite HUD display redesign needs to be done in a way that's backward compatible with existing HUDs...

[another_commander]

I don't know if this covers fully pmw57's idea of crosshairs separation from hud, but the crosshairs in 1.73.4 are already separate from the rest. They can be defined independently, and positioned as one sees fit. All this is handled from the crosshairs.plist file. See the example image, where I have moved the "No Weapon Here" crosshairs higher up in the screen (click thumbnail to enlarge):

If this is not good enough or does not cover the idea fully, then as Kaks already said, it will be great to have a patch submitted from anyone who considers this a problem important enough to require urgent resolution.

[Cmdr Wyvern]

When I worked on MilHUDv3, I took advantage of the fact that Oolite can recently support multiple background images in the hud. It's all separate elements that can be moved, resized, tweaked around, turned off, even changed if the player has some plist skills. Almost infinite variety is possible there, whatever you like goes.

And yes, it's completely compatible with 1280*1024, which FYI happens to be the native rez of my monitor.

[Kaks]

Almost infinite variety is possible there, whatever you like goes.

Wyvern, apparently this seems to be a bit too restrictive.

Hopefully someone will come up with a patch to expand the options, so maybe they won't have to redesign the HUD!

[Cmdr Wyvern]

Almost infinite variety is possible there, whatever you like goes.

Wyvern, apparently this seems to be a bit too restrictive.

Hopefully someone will come up with a patch to expand the options, so maybe they won't have to redesign the HUD!

Wait... A HUD made to be flexible winds up being restrictive?
Man, who woulda thunk? It's a bit much for the old wetware processor to compute... :brain explodes:

[JensAyton]

Oolite has had the same centered centre of the screen behaviour since it's been able to go full screen. The same HUD El Viejo is using now looks exactly the same with 1.73 as in any other version that can display it.

El Viejo, and anybody interested, have a look using 1.65 and see for yourself.

Well, actually… there was a bug causing all HUDs to be misaligned on non-Mac systems that we fixed somewhere around 1.69 or 1.70.

I don't know if this covers fully pmw57's idea of crosshairs separation from hud, but the crosshairs in 1.73.4 are already separate from the rest.

That wouldn’t work for the aforecited OSE HUD, since it uses a sprite and the new crosshair stuff only supports lines.

Anyway, the overall point is: it would be possible to change the way HUDs work so they can pin elements to the edges or centre, but it would be a biggish feature, not a geometry adjustment or a reversion to how it worked in the Golden Age.