View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003155 | FSSCP | HUD | public | 2015-04-05 23:56 | 2021-01-10 00:10 |
Reporter | Yarn | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Product Version | 3.7.2 RC5 | ||||
Fixed in Version | 21.0.0 | ||||
Summary | 0003155: Some HUD tables break targeting brackets at 4K resolutions | ||||
Description | As 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 Reproduce | Download 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 Information | I 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. | ||||
Tags | No tags attached. | ||||
|
|
|
I'm ready for testing |
|
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.) |
|
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. |
|
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. |
|
|
|
|
|
The plot thickens. Tests 4 and 6 failed. 5 is OK. |
|
Oh yeah, I forgot to tell you to remove the first $Max line from Test 5. Do that and then try it again. |
|
OK, that screwed it up. So tests 4-6 all failed now. |
|
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. |
|
|
|
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. |
|
Yes, I'm very sure - thanks for checking. Test 7 - works OK, targeting brackets are normal. |
|
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.) |
|
|
|
|
|
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). |
|
"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. |
|
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. |
|
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 :) |
|
Can you try a fullscreen window at 4K? |
|
Yes. Same as FS - bad. Only Windowed mode is good. |
|
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? |
|
Tested a slightly lower (100x100) resolution in windowed mode - suddenly targeting brackets were gone. |
|
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. |
|
If you reduce the horizontal resolution to less than 2665, do the brackets still stop working at 2000 vertical pixels? |
|
I'm lost now - 2664x1999 will also lose brackets. It just took more time to happen. |
|
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. |
|
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. |
|
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. |
|
Hurrah. Confirmed replicated at 3840x2400 (Nvidia DSR) on Windows 7 64bit. |
|
Untargeting for 3.7.2, since it's out. |
|
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. |
|
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. |
|
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? |
|
Same situation with knossos and FSO-3.8.0-3, but probably this should be tracked via github now. |
|
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 |
|
According to the GitHub version of this issue, it has been fixed sometime in 2019. |
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 |