Source Code Project Mantis - FSSCP
View Issue Details
0003155FSSCPHUDpublic2015-04-05 19:562019-04-30 04:03
ReporterYarn 
Assigned To 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusnewResolutionopen 
PlatformOSOS Version
Product Version3.7.2 RC5 
Target VersionFixed in Version 
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.
related to 0002985resolved Yarn In-game text messages are missing pixels on the left and on the top when scaled beyond 768p 
Attached Files? mv_root-hdg.tbm (4,885) 2015-04-05 19:56
http://scp.indiegames.us/mantis/file_download.php?file_id=2680&type=bug
? test_4-hdg.tbm (2,613) 2015-04-06 21:14
http://scp.indiegames.us/mantis/file_download.php?file_id=2683&type=bug
? test_6-hdg.tbm (85) 2015-04-06 21:14
http://scp.indiegames.us/mantis/file_download.php?file_id=2684&type=bug
? test_7-hdg.tbm (2,634) 2015-04-07 01:11
http://scp.indiegames.us/mantis/file_download.php?file_id=2685&type=bug
? test_8-hdg.tbm (2,594) 2015-04-07 21:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2687&type=bug
? test_9-hdg.tbm (2,594) 2015-04-07 21:08
http://scp.indiegames.us/mantis/file_download.php?file_id=2688&type=bug

Notes
(0016598)
leoben   
2015-04-06 00:40   
I'm ready for testing
(0016599)
Yarn   
2015-04-06 01:11   
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.)
(0016601)
leoben   
2015-04-06 19:28   
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.
(0016602)
Yarn   
2015-04-06 21:14   
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.
(0016603)
leoben   
2015-04-06 21:55   
The plot thickens. Tests 4 and 6 failed. 5 is OK.
(0016604)
Yarn   
2015-04-06 22:41   
Oh yeah, I forgot to tell you to remove the first $Max line from Test 5. Do that and then try it again.
(0016605)
leoben   
2015-04-07 00:14   
OK, that screwed it up. So tests 4-6 all failed now.
(0016606)
Yarn   
2015-04-07 01:11   
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.
(0016607)
Yarn   
2015-04-07 14:30   
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.
(0016610)
leoben   
2015-04-07 20:22   
Yes, I'm very sure - thanks for checking. Test 7 - works OK, targeting brackets are normal.
(0016611)
Yarn   
2015-04-07 21:07   
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.)
(0016613)
leoben   
2015-04-07 21:42   
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).
(0016614)
MageKing17   
2015-04-07 22:05   
"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.
(0016615)
Yarn   
2015-04-07 22:06   
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.
(0016616)
leoben   
2015-04-07 23:06   
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 :)
(0016617)
Yarn   
2015-04-07 23:19   
Can you try a fullscreen window at 4K?
(0016618)
leoben   
2015-04-07 23:27   
Yes. Same as FS - bad. Only Windowed mode is good.
(0016619)
Yarn   
2015-04-07 23:40   
(Last edited: 2015-04-08 01: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?

(0016625)
leoben   
2015-04-08 21:59   
Tested a slightly lower (100x100) resolution in windowed mode - suddenly targeting brackets were gone.
(0016626)
leoben   
2015-04-08 22:19   
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.
(0016628)
Yarn   
2015-04-09 01:22   
If you reduce the horizontal resolution to less than 2665, do the brackets still stop working at 2000 vertical pixels?
(0016629)
leoben   
2015-04-09 19:34   
I'm lost now - 2664x1999 will also lose brackets. It just took more time to happen.
(0016630)
Yarn   
2015-04-09 20:53   
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.
(0016631)
leoben   
2015-04-09 20:57   
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.
(0016633)
Yarn   
2015-04-09 22:31   
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.
(0016637)
Italianmoose   
2015-04-10 18:12   
Hurrah. Confirmed replicated at 3840x2400 (Nvidia DSR) on Windows 7 64bit.
(0016661)
Goober5000   
2015-04-23 23:06   
Untargeting for 3.7.2, since it's out.
(0016922)
CP5670   
2018-10-22 01:32   
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.
(0016924)
mithi   
2019-04-30 04:03   
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.

Issue History
2015-04-05 19:56YarnNew Issue
2015-04-05 19:56YarnStatusnew => assigned
2015-04-05 19:56YarnAssigned To => Yarn
2015-04-05 19:56YarnFile Added: mv_root-hdg.tbm
2015-04-05 19:57YarnRelationship addedrelated to 0002985
2015-04-06 00:40leobenNote Added: 0016598
2015-04-06 01:11YarnNote Added: 0016599
2015-04-06 01:19YarnStatusassigned => feedback
2015-04-06 19:28leobenNote Added: 0016601
2015-04-06 21:14YarnNote Added: 0016602
2015-04-06 21:14YarnStatusfeedback => assigned
2015-04-06 21:14YarnFile Added: test_4-hdg.tbm
2015-04-06 21:14YarnFile Added: test_6-hdg.tbm
2015-04-06 21:55leobenNote Added: 0016603
2015-04-06 22:41YarnNote Added: 0016604
2015-04-07 00:14leobenNote Added: 0016605
2015-04-07 01:11YarnNote Added: 0016606
2015-04-07 01:11YarnFile Added: test_7-hdg.tbm
2015-04-07 14:30YarnNote Added: 0016607
2015-04-07 20:22leobenNote Added: 0016610
2015-04-07 21:07YarnNote Added: 0016611
2015-04-07 21:08YarnFile Added: test_8-hdg.tbm
2015-04-07 21:08YarnFile Added: test_9-hdg.tbm
2015-04-07 21:42leobenNote Added: 0016613
2015-04-07 22:05MageKing17Note Added: 0016614
2015-04-07 22:06YarnNote Added: 0016615
2015-04-07 23:06leobenNote Added: 0016616
2015-04-07 23:19YarnNote Added: 0016617
2015-04-07 23:27leobenNote Added: 0016618
2015-04-07 23:40YarnNote Added: 0016619
2015-04-08 01:36YarnNote Edited: 0016619bug_revision_view_page.php?bugnote_id=16619#r1030
2015-04-08 21:59leobenNote Added: 0016625
2015-04-08 22:19leobenNote Added: 0016626
2015-04-09 01:22YarnNote Added: 0016628
2015-04-09 19:34leobenNote Added: 0016629
2015-04-09 20:53YarnNote Added: 0016630
2015-04-09 20:53YarnStatusassigned => new
2015-04-09 20:53YarnAssigned ToYarn =>
2015-04-09 20:57leobenNote Added: 0016631
2015-04-09 22:31YarnNote Added: 0016633
2015-04-09 23:24YarnSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=1034#r1034
2015-04-10 18:12ItalianmooseNote Added: 0016637
2015-04-23 23:06Goober5000Note Added: 0016661
2015-04-23 23:06Goober5000Target Version3.7.2 =>
2018-10-22 01:32CP5670Note Added: 0016922
2019-04-30 04:03mithiNote Added: 0016924