View Issue Details

IDProjectCategoryView StatusLast Update
0003155FSSCPHUDpublic2021-01-10 00:10
ReporterYarn Assigned To 
PrioritynormalSeveritymajorReproducibilitysometimes
Status closedResolutionfixed 
Product Version3.7.2 RC5 
Fixed in Version21.0.0 
Summary0003155: Some HUD tables break targeting brackets at 4K resolutions
DescriptionAs leoben pointed out in this thread (http://www.hard-light.net/forums/index.php?topic=89450.0), Blue Planet 2's HUD table is causing targeting brackets, as well as almost everything else that follows the brackets, to be missing or displayed improperly at very high resolutions like 3840x2160. More common resolutions like 1920x1080 appear to be unaffected.

Plain FS2 does not exhibit the problem, and neither do the 2014 MediaVPs. However, if BP2's HUD table is stripped of its custom gauges and fonts and is then used with plain FS2, then the problem occurs. Thus, the problem is not specific to BP2.

The culprit was determined to be revision 10990, which was meant to fix Mantis 0002985 by introducing proper rounding to the gr_[re|un]size_screen_pos(f) functions. (The problem also existed between revisions 10844 [inclusive] and 10868 [exclusive] whenever the HUD was scaled, regardless of the resolution.)
Steps To ReproduceDownload the attached table (which uses the BP2 layout but is compatible with plain FS2) to FreeSpace2\data\tables and play a mission at 3840x2160 resolution without mods. The targeting brackets and perhaps other things like the lead indicator will be either missing or placed at the wrong part of the screen.
Additional InformationI still don't know what part of the HUD table is triggering the problem, why this only occurs at very high resolutions, or how this can be fixed without ditching rounding. I intend to work with leoben in this ticket to find out. Help from others who can run the game in 4K is also welcome.
TagsNo tags attached.

Relationships

related to 0002985 resolvedYarn In-game text messages are missing pixels on the left and on the top when scaled beyond 768p 

Activities

Yarn

2015-04-05 23:56

developer  

mv_root-hdg.tbm (4,885 bytes)

leoben

2015-04-06 04:40

reporter   ~0016598

I'm ready for testing

Yarn

2015-04-06 05:11

developer   ~0016599

Here are the first builds that I want you to try:

Test 1: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_1_SSE2.zip
Test 2: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_2_SSE2.zip
Test 3: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/fs2_open_3_7_1_mantis_3155_test_3_SSE2.zip

All three builds are based on revision 11296 with these changes:

Test 1: Simple revert of revision 10990.
Test 2: Changed fl2ir() (the rounding function) to round up instead of away from zero in halfway cases (like 3.5).
Test 3: Changed fl2ir() to use C++11's round() function. (For the sake of compatibility with older compilers, this change won't be committed even if it does work, but it's still worth trying.)

leoben

2015-04-06 23:28

reporter   ~0016601

Build 1 - works OK
Build 2 - bad, just as before
Build 3 - bad, but worse than before. Rather than the brackets disappearing only after the first time your target moves out of your screen (until you do that, all other faulty builds worked OK), with this build you begin with the brackets being off screen immediately and/or in one of the corners of your screen, though your target is smack in the middle.

Yarn

2015-04-07 01:14

developer   ~0016602

I expected Test 1 to work. It's not optimal, though, since it reintroduces 0002985, which I'm hoping to avoid.

It's odd that Test 3 made things worse. At least we don't have to worry about that for now.

Next, I want you to try some HUD tables using the latest nightly build without mods. To try a table, place it in FreeSpace2\data\tables and rename it to "mv_root-hdg.tbm". (And make sure that Windows Explorer is not hiding file extensions, or else you might inadvertently name it "mv_root-hdg.tbm.tbm", which will not work with the game.)

Here are the tables that I want you to try:

Test 4: The file "test_4-hdg.tbm", which is attached to this report. It's basically the built-in HUD in the form of a table.
Test 5: The file "mv_root-hdg.tbm" that's attached to Mantis 0002672.
Test 6: The file "test_6-hdg.tbm", which is attached to this report. This one has a HUD configuration with no gauges defined. All the gauges should still work, though.

Yarn

2015-04-07 01:14

developer  

test_4-hdg.tbm (2,613 bytes)

Yarn

2015-04-07 01:14

developer  

test_6-hdg.tbm (85 bytes)

leoben

2015-04-07 01:55

reporter   ~0016603

The plot thickens. Tests 4 and 6 failed. 5 is OK.

Yarn

2015-04-07 02:41

developer   ~0016604

Oh yeah, I forgot to tell you to remove the first $Max line from Test 5. Do that and then try it again.

leoben

2015-04-07 04:14

reporter   ~0016605

OK, that screwed it up. So tests 4-6 all failed now.

Yarn

2015-04-07 05:11

developer   ~0016606

Here's another table to try:

Test 7: The file "test_7-hdg.tbm", which is attached to this report. Same as Test 4, but with scaling disabled.

Yarn

2015-04-07 05:11

developer  

test_7-hdg.tbm (2,634 bytes)

Yarn

2015-04-07 18:30

developer   ~0016607

Are you sure that you're testing with no mods whatsoever (not even the MediaVPs and definitely not BP2) and that you only have one *-hdg.tbm file in the FreeSpace\data\tables folder at any given moment? If not, then please do these things and run tests 4-7 again.

leoben

2015-04-08 00:22

reporter   ~0016610

Yes, I'm very sure - thanks for checking. Test 7 - works OK, targeting brackets are normal.

Yarn

2015-04-08 01:07

developer   ~0016611

Two more tables to try:

Test 8: The file "test_8-hdg.tbm", which is attached to this report. Same as Test 4, except the base resolution is 3840x2160. Scaling isn't explicitly disabled, but it should work anyway since the base resolution matches your resolution.

Test 9: The file "test_9-hdg.tbm", which is attached to this report. Same as Test 4, except the base resolution is 3200x2048. This will test whether just a little scaling at very high resolutions causes the problem.

I also want you to try a bunch of resolutions between 3840x2160 and 1920x1080 using either Test 4 or Test 6. This should give me an idea as to how high the resolution must be for this problem to occur. (Remember that you can use resolutions that your system doesn't support in full-screen mode by using windowed mode and the -res flag.)

Yarn

2015-04-08 01:08

developer  

test_8-hdg.tbm (2,594 bytes)

Yarn

2015-04-08 01:08

developer  

test_9-hdg.tbm (2,594 bytes)

leoben

2015-04-08 01:42

reporter   ~0016613

OK, both 8 and 9 check out fine. Note however that I didn't see any scaling on HUD elements (not sure if I should've seen any). Test 4 fails only at 4K resolution. 1440p is fine. Not sure what the point is of trying anything between the two, as there are no monitors that have native resolutions between those two (at least not that I'm aware of).

MageKing17

2015-04-08 02:05

developer   ~0016614

"Not sure what the point is of trying anything between the two, as there are no monitors that have native resolutions between those two (at least not that I'm aware of)."

To see what level of scaling starts to cause problems. It's intended to narrow down the cause of the issue, not provide testing of real-world use conditions.

Yarn

2015-04-08 02:06

developer   ~0016615

There should be scaling in Test 9, although it might be hard to notice a difference since there really isn't much scaling at all (only about 5.5%).

Yes, there is a point in testing non-standard resolutions. If, for example, the problem starts at around 2048x1536 (a good resolution to test, actually), then that would suggest that the problem occurs when the HUD is scaled 2x or more. You don't have to (and shouldn't) limit yourself to native resolutions of monitors that you can find.

leoben

2015-04-08 03:06

reporter   ~0016616

OK, interesting find. I remembered I never tested in windowed mode until I tried a custom resolution - didn't want to drive my monitor to insanity to resolutions it didn't support in overlay mode. So I tried your suggested resolution, it worked fine. Then I tried 4K again in FS mode just to make sure I'm still using the right tbm file. In FS mode, it immediately produced the issue. But when I tried 4K in windowed mode, the problem never surfaced. So - chew on that for a while :)

Yarn

2015-04-08 03:19

developer   ~0016617

Can you try a fullscreen window at 4K?

leoben

2015-04-08 03:27

reporter   ~0016618

Yes. Same as FS - bad. Only Windowed mode is good.

Yarn

2015-04-08 03:40

developer   ~0016619

Last edited: 2015-04-08 05:36

Perhaps windowed mode is working because a small portion of the window is off the screen. This time, play in windowed mode, but use the -res parameter to shrink the resolution just enough so that the entire window, border included, fits within the screen. If the brackets still work, then try a fullscreen window at that same resolution.

EDIT: Can you also test various resolutions (including non-standard ones) in a fullscreen window?

leoben

2015-04-09 01:59

reporter   ~0016625

Tested a slightly lower (100x100) resolution in windowed mode - suddenly targeting brackets were gone.

leoben

2015-04-09 02:19

reporter   ~0016626

OK - I think I'm getting on to something. I tried a gazillion custom resolutions now. Turns out once you go over 2000 pixels vertically, the brackets start disappearing. So for example, a 3840x1999 resolution would work just fine, once you go to 3840x2000, it's screwed up. This was done using FS window mode.

Yarn

2015-04-09 05:22

developer   ~0016628

If you reduce the horizontal resolution to less than 2665, do the brackets still stop working at 2000 vertical pixels?

leoben

2015-04-09 23:34

reporter   ~0016629

I'm lost now - 2664x1999 will also lose brackets. It just took more time to happen.

Yarn

2015-04-10 00:53

developer   ~0016630

Yeah, I'm completely lost too. It appears that the changes in revision 10990 aren't directly responsible for your problem; rather, they probably only exposed an existing bug. Considering that the brackets work fine when no table is used yet don't work with Test 6's table (both of which should produce the same result), and that running in a bordered window that doesn't fit the screen somehow makes the brackets work, it seems highly improbable that revision 10990 is the real culprit.

Since this issue is most likely beyond my expertise (and I don't have access to a 4K display), I'm unassigning this issue. Additionally, because the SCP team wants to release 3.7.2 Final soon, very few players will run into this issue, and there's a (admittedly not ideal) workaround for this issue (play in 1080p), I'm clearing the Target Version field.

The only thing left that I can think of is for you to ensure that your video driver is up to date.

leoben

2015-04-10 00:57

reporter   ~0016631

Since I work for one of the two companies that create high-end GPUs, this goes without saying :)

Thanks for the help, I guess I'll use an earlier build that doesn't have scaling.

Yarn

2015-04-10 02:31

developer   ~0016633

Um, ALL builds (except for very early ones) have scaling, which is necessary to support resolutions other than 640x480 and 1024x768. Just use a pre-10990 build until this can be fixed.

Italianmoose

2015-04-10 22:12

reporter   ~0016637

Hurrah. Confirmed replicated at 3840x2400 (Nvidia DSR) on Windows 7 64bit.

Goober5000

2015-04-24 03:06

administrator   ~0016661

Untargeting for 3.7.2, since it's out.

CP5670

2018-10-22 05:32

reporter   ~0016922

It's been a while since this was posted, but I was encountering this issue too. I am using 3.8.0 and 3.8.1 with the 3.8 MVPs. I notice that it occurs with both 4K resolution and $Scale Gauges: Yes in mv_root-hdg.tbm, but not otherwise. The targeting brackets look fine initially but either vanish or get stuck in the top left screen corner after a few minutes of gameplay, typically after a targeted ship is destroyed while being off screen. Once they become messed up, they stay that way even in new missions until the game is restarted.

This actually does not occur with the default HUD settings in the 3.8 MVPs (which have Scale Gauges: No but $Force Scaling Above: (1920, 1080), making the HUD smaller than it would be with Scale Gauges: Yes but still reasonable and not too small). However, this may help in diagnosing the issue.

mithi

2019-04-30 08:03

reporter   ~0016924

Maybe I can shed some light on this issue. I've compiled a recent git version and debugged my way through the code. I'm using the first Diaspora mission for my tests if that's relevant using a resolution of 3840x2160 (4k). At first the error does not occur an the brackets are properly rendered. However at some point the error occurs.

Whats happening is the following: HudGaugeBrackets::renderObjectBrackets calls model_find_2d_bound_min, which in turn calls g3_project_vertex. The assignment of p->screen.xyw.x resp p->screen.xyw.y relies on the values of Canvas_width and Canvas_height. Normally, I'd expect them to be 3840 resp. 2160. They are however 180 resp 135.

Using a data breakpoint on those variables I can see that they are set during game_render_frame -> g3_start_frame_func to the expected values of 3840x2160. However they are overwritten by a callchain of game_render_hud -> hud_render_all -> hud_render_gauges -> HudGaugeTargetBox::render -> HudGaugeTargetBox::renderTargetShip -> HudGaugeTargetBox::renderTargetSetup -> g3_start_frame_func to the unexpected lower values of 180x135.

Since the call to HudGaugeBrackets::renderObjectBrackets happens after HudGaugeTargetBox::renderTargetShip and the Canvas_width/Canvas_height is not reset to proper values (at least in the error case) the error occurs.

My best guess is that HudGaugeTargetBox::render should not modify global state without restoring it upon leaving. How to implement that is however beyond my expertise with this code.

Perhaps someone can make more sense of it than me.

kvorg

2019-12-28 19:58

reporter   ~0016952

I can confirm that I can replicate the behaviour consistently on two computers with 4k screens. The behaviour matches the description by CP5670: "The targeting brackets look fine initially but either vanish or get stuck in the top left screen corner after a few minutes of gameplay, typically after a targeted ship is destroyed while being off screen."
The systems are running under Linux Mint, I am using FreeSpace2 3.7.2+repack-1build1 with knossos 0.13.3-1~bionic1 to update and run mods, with last FSPort 1.0.0 with MediaVP 3.7.2 and no .fs2_open/data/tables.
Since more and more screens and lpatops will run at 4k, I consider this is becoming a real issue. Can anyone suggest how we can assist in debugging? Has anyone been able to check the HudGaugeTargetBox::render problem described by mithi?

kvorg

2019-12-28 20:25

reporter   ~0016953

Same situation with knossos and FSO-3.8.0-3, but probably this should be tracked via github now.

mithi

2019-12-28 22:18

reporter   ~0016954

I agree, this should move to github and in fact it already did. I have further debugged the issue with some help of a more seasoned developer and committed a fix that has been merged to master in May 2019. Try a recent nightly build and see if that works for you.

If you're interested in the details, please read https://github.com/scp-fs2open/fs2open.github.com/issues/1827

MjnMixael

2021-01-10 00:10

manager   ~0017087

According to the GitHub version of this issue, it has been fixed sometime in 2019.

Issue History

Date Modified Username Field Change
2015-04-05 23:56 Yarn New Issue
2015-04-05 23:56 Yarn Status new => assigned
2015-04-05 23:56 Yarn Assigned To => Yarn
2015-04-05 23:56 Yarn File Added: mv_root-hdg.tbm
2015-04-05 23:57 Yarn Relationship added related to 0002985
2015-04-06 04:40 leoben Note Added: 0016598
2015-04-06 05:11 Yarn Note Added: 0016599
2015-04-06 05:19 Yarn Status assigned => feedback
2015-04-06 23:28 leoben Note Added: 0016601
2015-04-07 01:14 Yarn Note Added: 0016602
2015-04-07 01:14 Yarn Status feedback => assigned
2015-04-07 01:14 Yarn File Added: test_4-hdg.tbm
2015-04-07 01:14 Yarn File Added: test_6-hdg.tbm
2015-04-07 01:55 leoben Note Added: 0016603
2015-04-07 02:41 Yarn Note Added: 0016604
2015-04-07 04:14 leoben Note Added: 0016605
2015-04-07 05:11 Yarn Note Added: 0016606
2015-04-07 05:11 Yarn File Added: test_7-hdg.tbm
2015-04-07 18:30 Yarn Note Added: 0016607
2015-04-08 00:22 leoben Note Added: 0016610
2015-04-08 01:07 Yarn Note Added: 0016611
2015-04-08 01:08 Yarn File Added: test_8-hdg.tbm
2015-04-08 01:08 Yarn File Added: test_9-hdg.tbm
2015-04-08 01:42 leoben Note Added: 0016613
2015-04-08 02:05 MageKing17 Note Added: 0016614
2015-04-08 02:06 Yarn Note Added: 0016615
2015-04-08 03:06 leoben Note Added: 0016616
2015-04-08 03:19 Yarn Note Added: 0016617
2015-04-08 03:27 leoben Note Added: 0016618
2015-04-08 03:40 Yarn Note Added: 0016619
2015-04-08 05:36 Yarn Note Edited: 0016619
2015-04-09 01:59 leoben Note Added: 0016625
2015-04-09 02:19 leoben Note Added: 0016626
2015-04-09 05:22 Yarn Note Added: 0016628
2015-04-09 23:34 leoben Note Added: 0016629
2015-04-10 00:53 Yarn Note Added: 0016630
2015-04-10 00:53 Yarn Status assigned => new
2015-04-10 00:53 Yarn Assigned To Yarn =>
2015-04-10 00:57 leoben Note Added: 0016631
2015-04-10 02:31 Yarn Note Added: 0016633
2015-04-10 03:24 Yarn Steps to Reproduce Updated
2015-04-10 22:12 Italianmoose Note Added: 0016637
2015-04-24 03:06 Goober5000 Note Added: 0016661
2015-04-24 03:06 Goober5000 Target Version 3.7.2 =>
2018-10-22 05:32 CP5670 Note Added: 0016922
2019-04-30 08:03 mithi Note Added: 0016924
2019-12-28 19:58 kvorg Note Added: 0016952
2019-12-28 20:25 kvorg Note Added: 0016953
2019-12-28 22:18 mithi Note Added: 0016954
2021-01-10 00:10 MjnMixael Status new => closed
2021-01-10 00:10 MjnMixael Resolution open => fixed
2021-01-10 00:10 MjnMixael Fixed in Version => 21.0.0
2021-01-10 00:10 MjnMixael Note Added: 0017087