Non-standard aspect ratio - now solved for Fighter HUD

[zevans]

How about add support for a new tag describing aspect ratios and what to do in case of rendering emergency - and have the default assumption "4:3" and "nothing" so that HUDs that don't know about the new stuff continue to behave in the old way?

[pmw57]

How about add support for a new tag describing aspect ratios and what to do in case of rendering emergency - and have the default assumption "4:3" and "nothing" so that HUDs that don't know about the new stuff continue to behave in the old way?

Why should we even have to be aware of such ratio issues? If things are anchored relative to the centre of the screen and/or edges, such ratio problems need not become an issue.

[Killer Wolf]

interesting thread. i use 1280x1024 and my vamp HUD doesn't fit the 1.73 release when it used to work fine in 1.65.

This was due to a bug in 1.65 which was fixed in 1.67. In 1.65, the HUD coordinate system varied between planets. From 1.67, it is standardised on the previous Mac behaviour.

out of interest, how come altering the Y placement value in the HUD plist in 1.73 doesn't shift the vamp HUD down to get rid of the gap? is something else overriding that?

[Commander McLane]

This was due to a bug in 1.65 which was fixed in 1.67. In 1.65, the HUD coordinate system varied between planets.

"Planet Macintosh to planet Microsoft: If there is any intelligent life-form at your place, please respond..."

[pmw57]

... static ...

[Captain Hesperus]

... static ...

<garble>
<blue screen of death...>

Captain Hesperus

[JensAyton]

This was due to a bug in 1.65 which was fixed in 1.67. In 1.65, the HUD coordinate system varied between planets.

:shock:

"Planet Macintosh to planet Microsoft: If there is any intelligent life-form at your place, please respond..."

Platforms, buggrit. :-p

[Cmd. Cheyd]

<Planet Microsoft reboots communication array just in time to watch Planet Macintosh's Main Power Station (read- battery) explode>

<shrugs> meh...

[Killer Wolf]

this HUD stuff getting on my t*ts now. nothing i do gets the thing to place flush against the bottom of the screen. i've even sized the image to be 1024x768, and tried 1280x1024, and used that. it still gets resized by the game, leaving strips at top and bottom. changing the WIDTH and HEIGHT settings in plist, when larger than the image (ie, using 1280 etc when the image is 1024) makes it bigger and doesn't fit the screen, making it the exact size leaves strips. as mentioned earlier, using the X and Y values appears to have no effect.
i've made everything 4:3 which, if i'm reading ahruman's post correctly, means it shouldn't need to be scaled and should fit perfectly. or am i missing something obvious?

[another_commander]

I think you need to make your image 5:4 aspect ratio. You are currently trying to fit a 4:3 image in a 5:4 resolution.

[Killer Wolf]

Well like i said, Ahruman mentioned 4:3 on the first page so i've been trying that :-/

[Y A J]

What do you think about this patch, which allows HUD items to specify new x_origin and y_origin properties which describe the desired co-ordinate system? (The values should be floating point numbers, e.g. x_origin = 1.0 means that the x co-ordinate is interpreted relative to the right hand side of the screen, and y_origin = -1.0 means that y is relative to the screen bottom. If x_origin is set to 0 or unspecified, then x is interpreted relative to the middle of the screen (duplicating the existing behaviour), and similarly for y_origin.)

The patch is too big to include inline, so is available here:

http://oolite.pastebin.com/f34ad437e

I've updated the default hud.plist to use y_origin to align the legends and dials to the screen bottom, even on tall aspect ratio displays.

The advantages of this approach:

• HUDs can easily anchor different objects to different parts of the screen (e.g. the crosshairs in the middle and the dials flush against the bottom edge), regardless of aspect ratio. This will work even if the crosshairs are sprites and even if the resolution or window size is changed at runtime, which was previously impossible.
• It's completely backwards compatible; all existing HUDs will work as well (or as badly) as they ever did.

Disadvantages:

• Although positions become quite flexible with this patch, there's no corresponding facility for sizes. (For instance, something like the Fighter HUD would probably like to be able to specify that the opaque glass image be sized to about 60% of the screen height.) That could be added later if necessary.
• I didn't update the constants in HeadUpDisplay.h to match the new hud.plist. Although it would be cleaner to change those to specify y_origin as well, there is a slight risk that doing so might break weird custom HUDs which assume that particular HUD items live at fixed positions without specifying them explicitly. If this patch is applied, then the constants should probably get updated eventually.

- Yet Another Jameson

[Kaks]

Looks very promising! We'll take it for a spin, and - barring accidents - you might just have found a way to give both Screet and pmw57 some extra peace of mind!

[Screet]

Looks very promising! We'll take it for a spin, and - barring accidents - you might just have found a way to give both Screet and pmw57 some extra peace of mind!

Everyone with a standard 19" TFT or 17" TFT with 19" resolution would benefit

How's testing going? I myself have trouble with the example since it's mixing the new and old revision, thus I don't have any idea how I could tell svn or some other program on how to modify my version according to the example...I'd really like to give it a try...

Screet

[Kaks]

Haven't started testing yet. This weekend I should have some free time, provided I can stop myself from taking on extra commitments...