Non-standard aspect ratio - now solved for Fighter HUD

[Y A J]

Hi, folks!

Here is a patch against SVN trunk which moves only the "bottom" part of the HUD (i.e., the dials and legends, but not crosshairs or any other part of the display) to the screen bottom edge. This is what I understand screet and pwm57's suggestions to be.

The patch seems to work for me under GNUstep. It is NOT implemented for Cocoa (it would be easy enough to guess what should be changed, but I have no way to test it). I haven't tried it with any OXPs, either.

Code: Select all

Index: src/SDL/MyOpenGLView.m
===================================================================
--- src/SDL/MyOpenGLView.m      (revision 2632)
+++ src/SDL/MyOpenGLView.m      (working copy)
@@ -357,6 +357,12 @@
 }
 
 
+- (GLfloat) hud_offset
+{
+       return hud_offset;
+}
+
+
 - (GameController *) gameController
 {
        return gameController;
@@ -702,10 +708,13 @@
 #endif
        OOLog(@"display.initGL", @"Created a new surface of %d x %d, %@.", (int)viewSize.width, (int)viewSize.height,(fullScreen ? @"fullscreen" : @"windowed"));
 
-       if (viewSize.width/viewSize.height > 4.0/3.0)
+       if (viewSize.width/viewSize.height > 4.0/3.0) {
                display_z = 480.0 * bounds.size.width/bounds.size.height;
-       else
+               hud_offset = 0.0;
+       } else {
                display_z = 640.0;
+               hud_offset = 320.0 * bounds.size.height/bounds.size.width - 240.0;
+       }
 
        float   ratio = 0.5;
        float   aspect = bounds.size.height/bounds.size.width;
Index: src/SDL/MyOpenGLView.h
===================================================================
--- src/SDL/MyOpenGLView.h      (revision 2632)
+++ src/SDL/MyOpenGLView.h      (working copy)
@@ -114,6 +114,7 @@
 
        NSSize                          viewSize;
        GLfloat                         display_z;
+       GLfloat                         hud_offset;
 
     double                             squareX,squareY;
        NSRect                          bounds;
@@ -159,6 +160,7 @@
 
 - (NSSize) viewSize;
 - (GLfloat) display_z;
+- (GLfloat) hud_offset;
 
 - (GameController *) gameController;
 - (void) setGameController:(GameController *) controller;
Index: src/Core/HeadUpDisplay.m
===================================================================
--- src/Core/HeadUpDisplay.m    (revision 2632)
+++ src/Core/HeadUpDisplay.m    (working copy)
@@ -373,11 +373,13 @@
 {
        OOGL(glLineWidth(_crosshairWidth * line_width));
        [self drawCrosshairs];
-
+       OOGL(glPushMatrix());
+       OOGL(glTranslatef(0, -[[UNIVERSE gameView] hud_offset], 0));
        OOGL(glLineWidth(line_width));
        [self drawLegends];
 
        [self drawDials];
+       OOGL(glPopMatrix());
        CheckOpenGLErrors(@"After drawing HUD");
 }

Bye for now,
- Yet Another Jameson

[JensAyton]

This will not achieve the desired result for HUDs that use sprites to add detail to the crosshairs, or add a “real” HUD (like the fighter HUD).

[pmw57]

This will not achieve the desired result for HUDs that use sprites to add detail to the crosshairs, or add a “real” HUD (like the fighter HUD).

Are you asking the developers to allow sprites for the crosshairs?

[DaddyHoggy]

This will not achieve the desired result for HUDs that use sprites to add detail to the crosshairs, or add a “real” HUD (like the fighter HUD).

Are you asking the developers to allow sprites for the crosshairs?

Ahruman IS a developer - he's telling you YAJ's fix will not work for HUDs that already use sprites to enhance the standard crosshair.

[Kaks]

An independently adjustable secondary sprite for the crosshairs is the only show stopper for the things you and Screet were asking the Fighter HUD to do: the fighter hud is one huge sprite, and the bottom of the sprite isn't flush to the bottom of the screen with El Viejo (& others) aspect ratios. You can already edit the HUD definition to move the whole sprite downwards, but then the predrawn crosshairs won't be aligned with the centre of the screen and the lasers will shoot upwards of where you expect them to go.

If someone were to redraw the Fighter HUD specifically for whatever aspect ratio it is, I believe it will work. And Cmdr Wyvern seems to agree, & he has the same boxy aspect ratio on his computer.

If the crosshairs are actually drawn using Oolite's HUD api - something done in quite a few HUDs - then there wouldn't be any need to redesign the HUD. As another_commander has already pointed out, we can move non-sprite crosshairs at will.

To my mind, using something like the gimp to redraw the big Fighter HUD sprite for the boxy aspect ratio, (so its predrawn crosshairs are centered while it still touches the bottom of the screen) still sounds like the simplest solution.

[Cody]

Well, it seems that the slap round the face that I gave myself earlier (another thread) has done something to my brain.
I've cured my aspect ratio problem. Yes, I know, I can't quite believe it either.

In Fighter HUD config there are two hud.plists - hud1280x1024.plist and hud.plist.
First I removed hud.plist then I renamed hud1280x1024.plist to hud.plist.

It took two tries with shift held down, but now it appears to fit my display perfectly. I'm off out now for more testing. (It works in trunk also).

I really wish I'd tried that before (I did tinker a fair bit, but to no avail); I could have saved some good and busy people some valuable time.
<Shuffles off to stand on the naughty step> There's a lesson there, for me at least.
I wonder now if 1.72x was somehow doing it itself. (I did seem to have a "strange" version of 1.72)

My apologies and my thanks to all who have tried to help.


Regards

[Y A J]

This will not achieve the desired result for HUDs that use sprites to add detail to the crosshairs, or add a “real” HUD (like the fighter HUD).

True. Like I said, I haven't bothered testing the patch with different OXPs, but I would expect they would roughly fall into one of three categories:

1. Some HUDs assume only that y=-240 aligns with the bottom of the screen, and use the builtin crosshairs. These should work perfectly with the patch above. They include the builtin HUD, and others like "trekhud".
2. Other HUDs do use the builtin crosshairs, but also assume that y=0 is centred vertically. (For instance, "fighter".) These ones will mostly work, and the main body of the crosshairs will be correct, but some cosmetics (and crosshair backgrounds) will be misaligned.
3. Lastly, other HUDs use a "legend" element to render their own crosshairs (like "milspechud"). These won't work at all; the entire crosshairs will be misaligned.

To my mind, using something like the gimp to redraw the big Fighter HUD sprite for the boxy aspect ratio, (so its predrawn crosshairs are centered while it still touches the bottom of the screen) still sounds like the simplest solution.

I agree that would be simplest, but it still feels a little bit unsatisfying. Being forced to edit the HUD to change resolution is somewhat annoying, and it wouldn't work properly in windowed (i.e. resizable) mode.

Unfortunately, no change to the core would be compatible with all current OXPs, since each of the following assumptions are made by at least one:

1. y=0 is centred
2. y=-240 is the bottom of the screen
3. x=-320 and/or x=320 is visible
4. pixels are square

and (at least for some resolutions) those are mutually exclusive.

I think a better solution would be to change the hud.plist definition slightly, so that at least future HUDs could work properly in any resolution. For instance, either add a new "crosshair" element (alongside the existing legends and dials), or add an optional "coordinate system" field (next to the x/y pairs for each legend or dial). The first solution feels a bit cleaner, but the second has the advantage that it would be easier to maintain backward compatibility (new HUDs could work better, and old ones wouldn't appear any worse.)

- Yet Another Jameson

[Cmdr Wyvern]

Lastly, other HUDs use a "legend" element to render their own crosshairs (like "milspechud"). These won't work at all; the entire crosshairs will be misaligned.

This is the sort of issue I was aiming to solve with MilHUDv3.

Milspechud was created for Oolite 1.65. 1.65 had a bug which misaligned the background graphic, and HUDmakers compensated. Fighterhud, DrHUD, and startrekhud were made for 1.65 as well.

Later I made an update, MilHUD, with versions for 1.65 and the then-new 1.7.x series.

Now it's MilHUDv3, the final version, that uses multiple, small graphics elements instead of one big one. This is to make the HUD easily configurable for any screen res, or to just as easily customize in myriad ways, using features that came up in 1.73.x. It is, to my knowledge, the first and so far only HUD to do so.

My fellow HUDmakers: Update, update! You're losing the state of the art!

[Kaks]

What Commander Wyvern said.

Y A J, your patch would force a lot of HUDs to be redesigned, and in that sense it could be 'fun' to add it to the codebase. Still, we don't really want to force change down people's throats.

If the Fighter HUD was designed now, using the 1.73 extra HUD support features, I'm fairly sure that it would adjust automagically already, without having to manually switch its configuration files depending on aspect ratio.

If there's a patch you can come up that doesn't actually break any of the old fashioned HUD designs - and compatible across the 3 platforms already - then we'd add it to the code base in a split second. As your patch is in itself a bit of a work in progress, we'll consider it, but I really don't know when/if we can spare the time to actually ensure that it shows at least 95% of existing HUDs the way their original creators intended.

At least that's my take on it.

Ahruman, am I making any sense here?

Cheers,

Kaks.

PS: good to know that the Figther HUD redesign I was talking about was already (at least partially) there! Wish I'd been clever enough to notice!

[Y A J]

Y A J, your patch would force a lot of HUDs to be redesigned, and in that sense it could be 'fun' to add it to the codebase. Still, we don't really want to force change down people's throats.

I agree: it shouldn't be added to the default source as it is. It improves some existing HUDs at the expense of making others worse (even unusable). I mainly posted it out of curiosity to see if it would help El Viejo's HUD (I didn't know which one that was at the time).

If there's a patch you can come up that doesn't actually break any of the old fashioned HUD designs - and compatible across the 3 platforms already - then we'd add it to the code base in a split second.

Hmmm... I'll think about that. I'm going to be offline for a few days, but I am definitely interested having improved HUDs on narrow displays (OK, OK, so I have a 1280x1024 screen, and this is purely selfish). But since it is essentially impossible for any new code to improve ALL existing HUDs, my preference would be for any change made to the mainline code to keep exactly the existing behaviour for any unmodified HUD (to avoid nasty surprises), and add optional facilities to allow future HUDs to compensate for aspect ratio if they want to.

Bye for now,
- Yet Another Jameson

[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. it does have a bit around the gunsight, but this was as much to create a lighter/more visible area as it was to tart up the image. i'm prepping a new HUD for the Dominatrix ~ if i include similar elements will i end up w/ the same gap at the bottom of the screen?

[Cody]

If my memory serves, it was Capt. Kev who designed the Fighter HUD.

He wrote two HUD plists, identical except for the position co-ords.
Now I've worked it out, it seems like a good way to go.

I'm wondering if that might be a template for you, KW.

Another illusion? After a fair bit of in-game testing, I could swear that my laser is now ever so slightly more accurate,
especially at long range, now my HUD is correctly positioned. (Yeah I know, just an old man's imagination! Hey Ho!).

[Killer Wolf]

doing the HUD as-is and doing coordinates taking into account the gap at the bottom isn't a problem, the problem is the backward compatibility of my vampire HUD. it used to sit snugly at teh bottom of the screen and was coordinated accordingly. it now sits 5mm up and all the coordinates are off. i could redo it, but apart from anything else i think the gap at the bottom ruins the visual look. i'm assuming my new HUD will do the same, so i'll coordinate it accordingly, i was just wondering if i'm going to have to put up w/ the gap at the bottom.

[Cody]

What I was trying to say is: two plists - one for 1280x1024 and one for so-called standard aspect ratios.
I think only the "y" co-ords have to be changed, and by the same amount for each item.
It works in Fighter HUD. Download Fighter HUD and have a look, maybe.

The gap at the bottom does ruin the effect...I'm much happier now it's gone.

[JensAyton]

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.