Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Macfie on March 31, 2014, 08:22:12 pm
-
It would nice to make this an option. It "fixes" a problem I really did not notice and still don't see by shrinking everything and creating black bars on either side of the menus. At first I thought there was something wrong with my computer. The fix looks much worse than the problem I never noticed before. At least you can override it with the command line.
-
Agreed, this should default off.
-
Oh... I quite like it defaulting to on.
Hrmmm.... I can live with having to enable it via command-line, but I think it's essential for multi-screen layouts to have it on by default. Maybe it could choose the default on/off based on the current res (i.e.10:4 and higher aspect ratios would default to on?) and retain the command line option to override (although in a perfect world it could be settable in an in-game menu).
-
Yeah, I agree that FS2's menus shouldn't be stretched by default, especially considering their content.
I never really understood why so many people strongly prefer a distorted image over some pillarboxing. I mean, nobody's complaining about letterboxing anymore; what's so much worse about the opposite?
At least the option to stretch is there.
-
Yeah, I agree that FS2's menus shouldn't be stretched by default, especially considering their content.
I never really understood why so many people strongly prefer a distorted image over some pillarboxing. I mean, nobody's complaining about letterboxing anymore; what's so much worse about the opposite?
At least the option to stretch is there.
I agree with these sentiments. The stretched screens look stupid - a world populated by short fat people? What is this, Dwarf Fortress?
-
I'd also prefer not stretching by default, but arguably the interface gets cut off in an ugly manner at the sides by the pillarboxes.
I wonder, are there some retail textures that could be re-used to fill in the sides? Some sort of pattern or vertical thingy to hide the interface cutoff, whether using textures or basic drawing ops? And of course it'd be moddable.
-
Just so long as we don't use that godawful edge-blurring effect that so many TV networks use when airing old SD footage.
(And yeah, color me confused by the opposition to pillarboxing too. Seeing 4:3 content stretched horizontally makes me start twitching involuntarily.)
-
My vote for defaulting non-stretched menus. It's better this way, really.
-
If the menu is only slightly stretched it is not noticable, however the shrunk and pillared version is very noticable. The resolution on my screen has an 8:5 ratio which is close to the original 4:3. Unfortunately it is just enough to trigger the ugly pillared version.
However I think niffiwan has the best solution:
"Maybe it could choose the default on/off based on the current res (i.e.10:4 and higher aspect ratios would default to on?) and retain the command line option to override (although in a perfect world it could be settable in an in-game menu)."
-
A smart default like that can't work as long as there's only one launcher flag, it'd need more or different options.
-
I'd also prefer not stretching by default, but arguably the interface gets cut off in an ugly manner at the sides by the pillarboxes.
No part of the interface is being "cut off." It's just like how letterboxing does not cut off any part of a widescreen movie.
I wonder, are there some retail textures that could be re-used to fill in the sides? Some sort of pattern or vertical thingy to hide the interface cutoff, whether using textures or basic drawing ops? And of course it'd be moddable.
The FS2 interface background could be stitched together and be used for the side borders, maybe with some slight modification.
I'll look into adding support for borders in the near future. I'm not sure how exactly it will be utilized, though.
-
I'd also prefer not stretching by default, but arguably the interface gets cut off in an ugly manner at the sides by the pillarboxes.
No part of the interface is being "cut off." It's just like how letterboxing does not cut off any part of a widescreen movie.
Well I meant visually, not technically. And while letterboxing is the same thing, it's so much more ubiquitous that it doesn't really draw attention in the same way as pillarboxing. I still think non-stretched is miles better than stretched (at least on widescreen ratios), it's just that the retail interface art isn't exactly an ideal match for it.
I wonder, are there some retail textures that could be re-used to fill in the sides? Some sort of pattern or vertical thingy to hide the interface cutoff, whether using textures or basic drawing ops? And of course it'd be moddable.
The FS2 interface background could be stitched together and be used for the side borders, maybe with some slight modification.
It's nice that retail data is eternal and unchanging, so one can potentially do some creative frankensteining from bits and pieces. I might even fancy trying to come up with something myself. :nervous:
-
Ok, here's a simple mock-up, using only two pieces of retail interface.
Example 1:
Current (https://dl.dropboxusercontent.com/u/63964618/fs/interface_unstreched_edges.png)
With added borders (https://dl.dropboxusercontent.com/u/63964618/fs/interface_unstreched_edges_decos.png)
Example 2:
Current (https://dl.dropboxusercontent.com/u/63964618/fs/interface_unstreched_edges2.png)
With added borders (https://dl.dropboxusercontent.com/u/63964618/fs/interface_unstreched_edges_decos2.png)
The background can be lifted from 2_WeaponLoadout and the vertical border from a bunch of places (I forgot which) and tiled vertically. It's hacky, but since the retail images don't change, there ought to be no downsides to the hackiness.
-
Okay, so, here's my problem:
We had this thread: http://www.hard-light.net/forums/index.php?topic=86617.0 where people were strongly in favour of this being a default-on setting. Now, we have this thread right here, where apparently people are now upset that it was made a default-on setting.
What are we to do?
-
I vote for default on too - this is the behaviour the game should have had all along. People have just gotten used to the dodgy stretching - they'll get unused to it too, or just turn this off. Although, I will admit the bordered debrief looks very nice.
-
I vote for it being non-stretched by default. If the option is there to not stretch it, IDK what people are fussing about.
e: will mods have the ability to overrun the player's choice?
-
For the patterned borders, what's going to happen with mods? Remember this doesn't just affect FS2.
-
This is all just patchwork to an old fso limitation. I'd rather just pick a default and deal with it until something like the chromium enabled builds can be used to build a real wide-screen interface through and through!
If textured borders are to be added, though, I'll place my vote for moddability.
EDIT: :eek:
I was on my phone for the original post and didn't view all the links. I am strongly opposed to borders on the mainhall screen or uh... something.. it just worries me because mainhalls are a highly specific interface. What if I make animorphic mainhalls and the player wants to use that but also wants non-stretched rest of the interface?
More importantly, what about all those mainhalls out there that are just menus and work great as widescreen, fullscreen, or whateverscreen? I guess my point is that there's a reason mainhalls have their own table opposed to the rest of the interface, they are a special situation and I suggest they be considered as such. I do realize that people with supermadawesometriplemonitor setup will still want non stretched mainhalls. And I don't know what to do about it except to reiterate that this whole idea is a limitation to a limitation. It does nothing to actually open FSO's super-limited interface code to the real future needs.
-
I doubt hardcoding the borders in the engine would be accepted based on the reactions on #scp, so presumably it'd be done for example by a script in MediaVPs (nothing too tricky about it), and other mods could similarly do whatever they please. Of course, in that case there's naturally no need to do it by abusing retail assets.
-
I've noticed one other problem with this.
I wanted to do screen shots with the menus streched and not stretched. I had put the -stretch_menu custom command line in.
I'm not sure if this is a launcher problem or a problem with the build but the command line does not appear in the custom command line in the WXlauncher and I can't modify or remove it. It appears to be treated as if it is an option that can be selected. This could be a problem for custom mods if people want to switch back and forth between stretched and non stretched.
I can understand the desire for people with wide screen or multiple monitors to want this on by default as well as those like myself that would want it off by default. Perhaps we should do a survey to determine the relative number of people with each set up.
-
I ran into this while working on the HLPCoin builds. Without the stretching, the FSO interface shrank to a regular 1024x768 block in the corner of my screen. This should not be the default behavior. Remember, FSO's Prime Directive is to remain compatible with retail, and this falls under that umbrella, from a conceptual and usability perspective if not a performance perspective.
If a new user plays GOG, and then later decides to play FSO, he will be presented with a shrunken offset interface. He might conclude that there's something wrong with FSO and decide not to investigate further. Without coming to HLP and browsing some obscure threads, he wouldn't know about the special command-line option to bring things back to the way he wants them.
-
Without the stretching, the FSO interface shrank to a regular 1024x768 block in the corner of my screen.
Just for the record, you seem to be referring to something no one's described so far, so a screenshot ought to be helpful.
-
If a new user plays GOG, and then later decides to play FSO, he will be presented with a shrunken offset interface. He might conclude that there's something wrong with FSO and decide not to investigate further. Without coming to HLP and browsing some obscure threads, he wouldn't know about the special command-line option to bring things back to the way he wants them.
Wait a minute :wtf:
If I launch the the retail GOG version of FS2, it has black borders on the left and on the right, because FS2 retail only supports 4:3 aspect ratio resolutions (and my GPU control panel keeps the original aspect ratio, but scales to the up-down edge of the monitor). Now that FSO has non-stretched menus, you get those EXACT same borders with 16:9 resolutions, which is good, because it resembles 100% the original behaviour.
Maybe you have some odd GPU control settings? Because what you say doesn't make any sense.
-
What if I make animorphic mainhalls and the player wants to use that but also wants non-stretched rest of the interface?
Animorphic mainhalls seem to be a very specific and rare case. I haven't seen even one so far, even though I have played dozens of mods, many of them using custom mainhalls. To me, the case of animorphic mainhalls seems as a lame excuse, because they are practically non-existent.
Besides, what if a support for genuine 1920x1080 mainhalls is added in the future? Would you still insist making animorphic mainhalls?
-
What if I make animorphic mainhalls and the player wants to use that but also wants non-stretched rest of the interface?
Animorphic mainhalls seem to be a very specific and rare case. I haven't seen even one so far, even though I have played dozens of mods, many of them using custom mainhalls. To me, the case of animorphic mainhalls seems as a lame excuse, because they are practically non-existent.
Besides, what if a support for genuine 1920x1080 mainhalls is added in the future? Would you still insist making animorphic mainhalls?
What are you trying to argue? Of course I wouldn't want to make animorphic mainhalls if we had true resolution support. The whole idea of animorphic mainhalls only came up after I started recreating the retail mainhalls, which in the life of FSO is still quite recent. My point is that mainhalls have always been a special interface case and should be treated as such. It doesn't make much sense to argue that rare examples should be excluded given this whole patch set came out of trying to support the rare triple monitor setups. As long as we are making changes to support rare and specific cases, we probably shouldn't implement a broad-strokes, all or nothing approach.
Essentially, I think we can do better than to add a choose-your-limitation toggle to an already highly limited part of the code.
-
Well, my point in its simplicity is that when weighing the pros and cons of this non-stretch patch (which IMHO should have been implemented 7-8 years ago when widescreen monitors started to get more common), the pros outweigh the cons. The only "con" being that it messes up plans for animorphic mainhalls which didn't even exist in the first place.
What matters here is what the player sees. Stretching is ugly. It will always be ugly. When I play old games, I first try to find widescreen mods, and if they don't exist, I'll put a custom resolution of 1440x1080 and I'm totally fine with black bars. In FSO however there are two phases in the game. A 16:9 resolution gets a better fov in-game, but stretches menus, while 4:3 resolutions get smaller fov in-game but have correctly scaled menus. In-game is still more important than menus, so in the end players want to use their whole widescreen resolutions. Which means - sooner or later - something has to be done with the menus.
Anything that avoids a forced stretching is a MUST. Since FSO is a constantly evolving project, I DON'T expect that black bars are the final solution (since I sincerely hope for genuine high resolution / widescreen mainhall support implementation in the future), but as a temporal solution, it is million times better than stretching.
-
If you are working on anamorphic mainhalls maybe you should request the -stretched_menu flag to be supported as a mod.ini flag (like -ship_choice_3d), so it could be forced by default for your specific mod.
However I do find the non-stretched interface much better than the old one for retail.
-
Well, my point in its simplicity is that when weighing the pros and cons of this non-stretch patch (which IMHO should have been implemented 7-8 years ago when widescreen monitors started to get more common), the pros outweigh the cons. The only "con" being that it messes up plans for animorphic mainhalls which didn't even exist in the first place.
What matters here is what the player sees. Stretching is ugly. It will always be ugly. When I play old games, I first try to find widescreen mods, and if they don't exist, I'll put a custom resolution of 1440x1080 and I'm totally fine with black bars. In FSO however there are two phases in the game. A 16:9 resolution gets a better fov in-game, but stretches menus, while 4:3 resolutions get smaller fov in-game but have correctly scaled menus. In-game is still more important than menus, so in the end players want to use their whole widescreen resolutions. Which means - sooner or later - something has to be done with the menus.
Anything that avoids a forced stretching is a MUST. Since FSO is a constantly evolving project, I DON'T expect that black bars are the final solution (since I sincerely hope for genuine high resolution / widescreen mainhall support implementation in the future), but as a temporal solution, it is million times better than stretching.
I still don't understand what you are arguing for. It looks to me that you are actually arguing for no change to the behavior as-is and that people just deal with it until a better solution comes along. (Your reasoning seems to fall under your suggestion that all players everywhere agree with your distaste for stretching, but that is a whole separate point entirely.)
I could be misunderstanding, but your argument isn't adding anything to the discussion at hand. This is about tweaking the behavior, not removing it. This is about expanding it to be inclusive and not forcing it to exclusive. Surely you aren't saying you see harm in that.
If you are working on anamorphic mainhalls maybe you should request the -stretched_menu flag to be supported as a mod.ini flag (like -ship_choice_3d), so it could be forced by default for your specific mod.
However I do find the non-stretched interface much better than the old one for retail.
Given the complete lack of interest in expanding mainhalls at all except from a drive-by patch (seen here (http://www.hard-light.net/forums/index.php?topic=86888.0)), I find myself thinking it would be a waste of time to make anymore mainhall requests, no matter what badass trickery I could come up with.
-
Your reasoning seems to fall under your suggestion that all players everywhere agree with your distaste for stretching, but that is a whole separate point entirely.)
I'm pretty confident that majority of people prefer viewing audiovisual content as it was meant to be, whether we are talking about movies or video games. Stretching is a way of distorting original content. But yeah, as you said, this is a whole point entirely. Not going to continue arguing with this one.
I could be misunderstanding, but your argument isn't adding anything to the discussion at hand. This is about tweaking the behavior, not removing it. This is about expanding it to be inclusive and not forcing it to exclusive. Surely you aren't saying you see harm in that.
Well then, I must have misunderstood something. When I read this segment that you previously wrote...
I do realize that people with supermadawesometriplemonitor setup will still want non stretched mainhalls. And I don't know what to do about it except to reiterate that this whole idea is a limitation to a limitation. It does nothing to actually open FSO's super-limited interface code to the real future needs.
... I thought that you were opposing the patch in its entirety, because "it limits" the code. Players really don't care how limited or crude looking the code is; they only care about the end result.
But if you are not opposing this patch, but only debating about the default launch parameters, then there is really nothing to argue about :P
-
I'm saying the patch as-is is a knee jerk band-aid to a legitimate problem and that it needs further in-depth thought to implement properly.
-
Well, in that case, good luck for those attempting to enhance this patch :)
-
Since very few things have hardcoded positions in main halls, it's not hard to add support for main halls of any resolution and aspect ratio; in fact, the patch below does just that. Just keep in mind that the size of text changes with the resolution, so think twice before you use any 4K main halls! (Maybe I should add support for definable fonts in main halls...)
(And don't forget to change the value of +Tooltip Y appropriately!)
This patch also does the same thing with the preload screen.
Index: code/freespace2/freespace.cpp
===================================================================
--- code/freespace2/freespace.cpp (revision 10550)
+++ code/freespace2/freespace.cpp (working copy)
@@ -8692,16 +8692,20 @@
int width, height;
bm_get_info(Game_title_bitmap, &width, &height);
+ gr_set_screen_scale(width, height);
+
// draw it in the center of the screen
- gr_bitmap((gr_screen.max_w_unscaled - width)/2, (gr_screen.max_h_unscaled - height)/2, GR_RESIZE_MENU);
- }
+ gr_bitmap(0, 0, GR_RESIZE_MENU);
- if (Game_title_logo != -1)
- {
- gr_set_bitmap(Game_title_logo);
+ if (Game_title_logo != -1)
+ {
+ gr_set_bitmap(Game_title_logo);
- gr_bitmap(0, 0, GR_RESIZE_MENU);
+ gr_bitmap(0, 0, GR_RESIZE_MENU);
+ }
+
+ gr_reset_screen_scale();
}
}
Index: code/graphics/2d.cpp
===================================================================
--- code/graphics/2d.cpp (revision 10550)
+++ code/graphics/2d.cpp (working copy)
@@ -88,35 +88,39 @@
static int GL_cursor_nframes = 0;
// Pre-computed screen resize vars
-static float Gr_full_resize_X = 1.0f, Gr_full_resize_Y = 1.0f;
-static float Gr_resize_X = 1.0f, Gr_resize_Y = 1.0f;
-static float Gr_menu_offset_X = 0.0f, Gr_menu_offset_Y = 0.0f;
+static screen_scale Gr_resize;
+screen_scale Gr_save_resize;
-float Gr_save_full_resize_X = 1.0f, Gr_save_full_resize_Y = 1.0f;
-float Gr_save_resize_X = 1.0f, Gr_save_resize_Y = 1.0f;
-float Gr_save_menu_offset_X = 0.0f, Gr_save_menu_offset_Y = 0.0f;
-
bool Save_custom_screen_size;
+void gr_set_screen_scale(screen_scale ss)
+{
+ Gr_resize = ss;
+
+ Save_custom_screen_size = gr_screen.custom_size;
+
+ gr_screen.custom_size = true;
+}
+
void gr_set_screen_scale(int w, int h)
{
- Gr_full_resize_X = (float)gr_screen.max_w / (float)w;
- Gr_full_resize_Y = (float)gr_screen.max_h / (float)h;
+ Gr_resize.full_resize_X = (float)gr_screen.max_w / (float)w;
+ Gr_resize.full_resize_Y = (float)gr_screen.max_h / (float)h;
if (!Cmdline_stretch_menu) {
float aspect_quotient = ((float)gr_screen.max_w / (float)gr_screen.max_h) / ((float)w / (float)h);
- Gr_resize_X = Gr_full_resize_X / ((aspect_quotient > 1.0f) ? aspect_quotient : 1.0f);
- Gr_resize_Y = Gr_full_resize_Y * ((aspect_quotient < 1.0f) ? aspect_quotient : 1.0f);
+ Gr_resize.resize_X = Gr_resize.full_resize_X / ((aspect_quotient > 1.0f) ? aspect_quotient : 1.0f);
+ Gr_resize.resize_Y = Gr_resize.full_resize_Y * ((aspect_quotient < 1.0f) ? aspect_quotient : 1.0f);
- Gr_menu_offset_X = (aspect_quotient > 1.0f) ? ((gr_screen.max_w - gr_screen.max_w / aspect_quotient) / 2.0f) : 0.0f;
- Gr_menu_offset_Y = (aspect_quotient < 1.0f) ? ((gr_screen.max_h - gr_screen.max_h * aspect_quotient) / 2.0f) : 0.0f;
+ Gr_resize.menu_offset_X = (aspect_quotient > 1.0f) ? ((gr_screen.max_w - gr_screen.max_w / aspect_quotient) / 2.0f) : 0.0f;
+ Gr_resize.menu_offset_Y = (aspect_quotient < 1.0f) ? ((gr_screen.max_h - gr_screen.max_h * aspect_quotient) / 2.0f) : 0.0f;
} else {
- Gr_resize_X = Gr_full_resize_X;
- Gr_resize_Y = Gr_full_resize_Y;
+ Gr_resize.resize_X = Gr_resize.full_resize_X;
+ Gr_resize.resize_Y = Gr_resize.full_resize_Y;
- Gr_menu_offset_X = 0.0f;
- Gr_menu_offset_Y = 0.0f;
+ Gr_resize.menu_offset_X = 0.0f;
+ Gr_resize.menu_offset_Y = 0.0f;
}
Save_custom_screen_size = gr_screen.custom_size;
@@ -126,11 +130,11 @@
void gr_set_screen_scale(int w, int h, int max_w, int max_h)
{
- Gr_resize_X = Gr_full_resize_X = (float)max_w / (float)w;
- Gr_resize_Y = Gr_full_resize_Y = (float)max_h / (float)h;
+ Gr_resize.resize_X = Gr_resize.full_resize_X = (float)max_w / (float)w;
+ Gr_resize.resize_Y = Gr_resize.full_resize_Y = (float)max_h / (float)h;
- Gr_menu_offset_X = 0.0f;
- Gr_menu_offset_Y = 0.0f;
+ Gr_resize.menu_offset_X = 0.0f;
+ Gr_resize.menu_offset_Y = 0.0f;
Save_custom_screen_size = gr_screen.custom_size;
@@ -137,16 +141,21 @@
gr_screen.custom_size = true;
}
+screen_scale gr_get_screen_scale()
+{
+ return Gr_resize;
+}
+
void gr_reset_screen_scale()
{
- Gr_full_resize_X = Gr_save_full_resize_X;
- Gr_full_resize_Y = Gr_save_full_resize_Y;
+ Gr_resize.full_resize_X = Gr_save_resize.full_resize_X;
+ Gr_resize.full_resize_Y = Gr_save_resize.full_resize_Y;
- Gr_resize_X = Gr_save_resize_X;
- Gr_resize_Y = Gr_save_resize_Y;
+ Gr_resize.resize_X = Gr_save_resize.resize_X;
+ Gr_resize.resize_Y = Gr_save_resize.resize_Y;
- Gr_menu_offset_X = Gr_save_menu_offset_X;
- Gr_menu_offset_Y = Gr_save_menu_offset_Y;
+ Gr_resize.menu_offset_X = Gr_save_resize.menu_offset_X;
+ Gr_resize.menu_offset_Y = Gr_save_resize.menu_offset_Y;
gr_screen.custom_size = Save_custom_screen_size;
}
@@ -171,22 +180,22 @@
float xy_tmp = 0.0f;
if ( x ) {
- xy_tmp = (*x) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X) + ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_X : 0.0f);
+ xy_tmp = (*x) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X) + ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_X : 0.0f);
(*x) = fl2i(xy_tmp);
}
if ( y ) {
- xy_tmp = (*y) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y) + ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_Y : 0.0f);
+ xy_tmp = (*y) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y) + ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_Y : 0.0f);
(*y) = fl2i(xy_tmp);
}
if ( w ) {
- xy_tmp = (*w) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = (*w) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*w) = fl2i(xy_tmp);
}
if ( h ) {
- xy_tmp = (*h) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = (*h) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*h) = fl2i(xy_tmp);
}
@@ -211,22 +220,22 @@
float xy_tmp = 0.0f;
if ( x ) {
- xy_tmp = ((*x) - ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_X : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = ((*x) - ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_X : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*x) = fl2i(xy_tmp);
}
if ( y ) {
- xy_tmp = ((*y) - ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_Y : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = ((*y) - ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_Y : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*y) = fl2i(xy_tmp);
}
if ( w ) {
- xy_tmp = (*w) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = (*w) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*w) = fl2i(xy_tmp);
}
if ( h ) {
- xy_tmp = (*h) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = (*h) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*h) = fl2i(xy_tmp);
}
@@ -253,22 +262,22 @@
float xy_tmp = 0.0f;
if ( x ) {
- xy_tmp = (*x) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X) + ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_X : 0.0f);
+ xy_tmp = (*x) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X) + ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_X : 0.0f);
(*x) = xy_tmp;
}
if ( y ) {
- xy_tmp = (*y) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y) + ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_Y : 0.0f);
+ xy_tmp = (*y) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y) + ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_Y : 0.0f);
(*y) = xy_tmp;
}
if ( w ) {
- xy_tmp = (*w) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = (*w) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*w) = xy_tmp;
}
if ( h ) {
- xy_tmp = (*h) * ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = (*h) * ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*h) = xy_tmp;
}
@@ -293,22 +302,22 @@
float xy_tmp = 0.0f;
if ( x ) {
- xy_tmp = ((*x) - ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_X : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = ((*x) - ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_X : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*x) = xy_tmp;
}
if ( y ) {
- xy_tmp = ((*y) - ((resize_mode == GR_RESIZE_MENU) ? Gr_menu_offset_Y : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = ((*y) - ((resize_mode == GR_RESIZE_MENU) ? Gr_resize.menu_offset_Y : 0.0f)) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*y) = xy_tmp;
}
if ( w ) {
- xy_tmp = (*w) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_X : Gr_resize_X);
+ xy_tmp = (*w) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_X : Gr_resize.resize_X);
(*w) = xy_tmp;
}
if ( h ) {
- xy_tmp = (*h) / ((resize_mode == GR_RESIZE_FULL) ? Gr_full_resize_Y : Gr_resize_Y);
+ xy_tmp = (*h) / ((resize_mode == GR_RESIZE_FULL) ? Gr_resize.full_resize_Y : Gr_resize.resize_Y);
(*h) = xy_tmp;
}
@@ -476,23 +485,23 @@
mode = GR_OPENGL;
}
- Gr_save_full_resize_X = Gr_full_resize_X = (float)width / ((res == GR_1024) ? 1024.0f : 640.0f);
- Gr_save_full_resize_Y = Gr_full_resize_Y = (float)height / ((res == GR_1024) ? 768.0f : 480.0f);
+ Gr_save_resize.full_resize_X = Gr_resize.full_resize_X = (float)width / ((res == GR_1024) ? 1024.0f : 640.0f);
+ Gr_save_resize.full_resize_Y = Gr_resize.full_resize_Y = (float)height / ((res == GR_1024) ? 768.0f : 480.0f);
if (gr_screen.custom_size && !Cmdline_stretch_menu) {
float aspect_quotient = ((float)width / (float)height) / (4.0f / 3.0f);
- Gr_save_resize_X = Gr_resize_X = Gr_full_resize_X / ((aspect_quotient > 1.0f) ? aspect_quotient : 1.0f);
- Gr_save_resize_Y = Gr_resize_Y = Gr_full_resize_Y * ((aspect_quotient < 1.0f) ? aspect_quotient : 1.0f);
+ Gr_save_resize.resize_X = Gr_resize.resize_X = Gr_resize.full_resize_X / ((aspect_quotient > 1.0f) ? aspect_quotient : 1.0f);
+ Gr_save_resize.resize_Y = Gr_resize.resize_Y = Gr_resize.full_resize_Y * ((aspect_quotient < 1.0f) ? aspect_quotient : 1.0f);
- Gr_save_menu_offset_X = Gr_menu_offset_X = (aspect_quotient > 1.0f) ? ((width - width / aspect_quotient) / 2.0f) : 0.0f;
- Gr_save_menu_offset_Y = Gr_menu_offset_Y = (aspect_quotient < 1.0f) ? ((height - height * aspect_quotient) / 2.0f) : 0.0f;
+ Gr_save_resize.menu_offset_X = Gr_resize.menu_offset_X = (aspect_quotient > 1.0f) ? ((width - width / aspect_quotient) / 2.0f) : 0.0f;
+ Gr_save_resize.menu_offset_Y = Gr_resize.menu_offset_Y = (aspect_quotient < 1.0f) ? ((height - height * aspect_quotient) / 2.0f) : 0.0f;
} else {
- Gr_save_resize_X = Gr_resize_X = Gr_full_resize_X;
- Gr_save_resize_Y = Gr_resize_Y = Gr_full_resize_Y;
+ Gr_save_resize.resize_X = Gr_resize.resize_X = Gr_resize.full_resize_X;
+ Gr_save_resize.resize_Y = Gr_resize.resize_Y = Gr_resize.full_resize_Y;
- Gr_save_menu_offset_X = Gr_menu_offset_X = 0.0f;
- Gr_save_menu_offset_Y = Gr_menu_offset_Y = 0.0f;
+ Gr_save_resize.menu_offset_X = Gr_resize.menu_offset_X = 0.0f;
+ Gr_save_resize.menu_offset_Y = Gr_resize.menu_offset_Y = 0.0f;
}
Index: code/graphics/2d.h
===================================================================
--- code/graphics/2d.h (revision 10550)
+++ code/graphics/2d.h (working copy)
@@ -59,6 +59,12 @@
ubyte lookup[256];
} shader;
+typedef struct screen_scale {
+ float full_resize_X = 1.0f, full_resize_Y = 1.0f;
+ float resize_X = 1.0f, resize_Y = 1.0f;
+ float menu_offset_X = 0.0f, menu_offset_Y = 0.0f;
+} screen_scale;
+
#define AC_TYPE_NONE 0 // Not an alphacolor
#define AC_TYPE_HUD 1 // Doesn't change hue depending on background. Used for HUD stuff.
#define AC_TYPE_BLEND 2 // Changes hue depending on background. Used for stars, etc.
@@ -575,8 +581,10 @@
#define GR_RESIZE_MENU 2
#define GR_RESIZE_MENU_NO_OFFSET 3
+void gr_set_screen_scale(screen_scale ss);
void gr_set_screen_scale(int x, int y);
void gr_set_screen_scale(int x, int y, int max_x, int max_y);
+screen_scale gr_get_screen_scale();
void gr_reset_screen_scale();
bool gr_unsize_screen_pos(int *x, int *y, int *w = NULL, int *h = NULL, int resize_mode = GR_RESIZE_FULL);
bool gr_resize_screen_pos(int *x, int *y, int *w = NULL, int *h = NULL, int resize_mode = GR_RESIZE_FULL);
Index: code/menuui/mainhallmenu.cpp
===================================================================
--- code/menuui/mainhallmenu.cpp (revision 10550)
+++ code/menuui/mainhallmenu.cpp (working copy)
@@ -74,6 +74,10 @@
// background bitmap handle
int Main_hall_bitmap;
+// background bitmap dimensions
+int Main_hall_bitmap_w;
+int Main_hall_bitmap_h;
+
// background bitmap mask handle
int Main_hall_mask;
@@ -350,6 +354,7 @@
// blit some small color indicators to show whether ships.tbl and weapons.tbl are valid
// green == valid, red == invalid.
// ships.tbl will be on the left, weapons.tbl on the right
+/*
int Mh_ship_table_status[GR_NUM_RESOLUTIONS][2] = {
{ 1, 479 },
{ 1, 767 }
@@ -358,15 +363,16 @@
{ 3, 479 },
{ 3, 767 }
};
+*/
void main_hall_blit_table_status()
{
// blit ship table status
gr_set_color_fast(Game_ships_tbl_valid ? &Color_bright_green : &Color_bright_red);
- gr_line(Mh_ship_table_status[gr_screen.res][0], Mh_ship_table_status[gr_screen.res][1], Mh_ship_table_status[gr_screen.res][0], Mh_ship_table_status[gr_screen.res][1], GR_RESIZE_MENU);
+ gr_line(1, Main_hall_bitmap_h - 1, 1, Main_hall_bitmap_h - 1, GR_RESIZE_MENU);
// blit weapon table status
gr_set_color_fast(Game_weapons_tbl_valid ? &Color_bright_green : &Color_bright_red);
- gr_line(Mh_weapon_table_status[gr_screen.res][0], Mh_weapon_table_status[gr_screen.res][1], Mh_weapon_table_status[gr_screen.res][0], Mh_ship_table_status[gr_screen.res][1], GR_RESIZE_MENU);
+ gr_line(3, Main_hall_bitmap_h - 1, 3, Main_hall_bitmap_h - 1, GR_RESIZE_MENU);
}
/**
@@ -468,10 +474,15 @@
}
}
+ Main_hall_bitmap_w = -1;
+ Main_hall_bitmap_h = -1;
+
// load the background bitmap
Main_hall_bitmap = bm_load(Main_hall->bitmap);
if (Main_hall_bitmap < 0) {
nprintf(("General","WARNING! Couldn't load main hall background bitmap %s\n", Main_hall->bitmap.c_str()));
+ } else {
+ bm_get_info(Main_hall_bitmap, &Main_hall_bitmap_w, &Main_hall_bitmap_h);
}
bg_type = bm_get_type(Main_hall_bitmap);
@@ -620,6 +631,8 @@
{
int code, key, snazzy_action;
+ gr_set_screen_scale(Main_hall_bitmap_w, Main_hall_bitmap_h);
+
// need to ensure ambient is playing, since it may be stopped by a playing movie
main_hall_start_ambient();
@@ -834,6 +847,7 @@
#endif
gr_flip();
+ gr_reset_screen_scale();
// see if we have a missing campaign and force the player to select a new campaign if so
extern bool Campaign_room_no_campaigns;
@@ -1458,7 +1472,7 @@
gr_set_color_fast(&Color_bright);
gr_get_string_size(&w,&h,Main_hall_notify_text);
- gr_printf_menu((gr_screen.max_w_unscaled - w)/2, gr_screen.max_h_unscaled - 40, Main_hall_notify_text);
+ gr_printf_menu((Main_hall_bitmap_w - w)/2, Main_hall_bitmap_h - 40, Main_hall_notify_text);
}
}
}
@@ -1526,7 +1540,7 @@
// print the string near the lower left corner
gr_set_color_fast(&Color_bright_white);
- gr_string(5, gr_screen.max_h_unscaled - 24, version_string, GR_RESIZE_MENU);
+ gr_string(5, Main_hall_bitmap_h - 24, version_string, GR_RESIZE_MENU);
}
/**
@@ -1563,7 +1577,7 @@
gr_shade(0, shader_y, gr_screen.clip_width_unscaled, (gr_screen.clip_height_unscaled - shader_y), GR_RESIZE_MENU);
gr_set_color_fast(&Color_bright_white);
- gr_string((gr_screen.max_w_unscaled - w)/2, Main_hall->region_yval, Main_hall->region_descript.at(text_index), GR_RESIZE_MENU);
+ gr_string((Main_hall_bitmap_w - w)/2, Main_hall->region_yval, Main_hall->region_descript.at(text_index), GR_RESIZE_MENU);
}
}
@@ -1603,7 +1617,7 @@
gr_set_color_fast(&Color_bright_white);
gr_set_shader(&Main_hall_tooltip_shader);
gr_shade(0, 0, gr_screen.max_w_unscaled, (2*Main_hall_tooltip_padding[gr_screen.res]) + h - y_anim_offset, GR_RESIZE_MENU);
- gr_string((gr_screen.max_w_unscaled - w)/2, Main_hall_tooltip_padding[gr_screen.res] /*- y_anim_offset*/, str, GR_RESIZE_MENU);
+ gr_string((Main_hall_bitmap_w - w)/2, Main_hall_tooltip_padding[gr_screen.res] /*- y_anim_offset*/, str, GR_RESIZE_MENU);
}
/**
Index: code/popup/popup.cpp
===================================================================
--- code/popup/popup.cpp (revision 10550)
+++ code/popup/popup.cpp (working copy)
@@ -820,6 +820,9 @@
screen_id = gr_save_screen();
+ screen_scale old_scale = gr_get_screen_scale();
+ gr_reset_screen_scale();
+
while(!done) {
int k;
@@ -871,6 +874,8 @@
gr_flip();
}
+ gr_set_screen_scale(old_scale);
+
popup_close(pi,screen_id);
return choice;
}
-
Can you provide a little more documentation on what that does/how it works?
-
Can you provide a little more documentation on what that does/how it works?
Are you referring to code comments? If so, then I'll add more when I update the patch. (The fish tank cheat doesn't work correctly with custom-resolution main halls, so I need to fix that. I might end up changing the implementation a bit in the process.)
-
I mean documentation for us non-coder types.
As the resident main hall expert, how would I make use of this? Just change the tooltip y to 1920 and then adjust my animation coords?
Would FSO choose between 1024 and 1920 like it would between 1024 and 640? When would it choose a wide screen version over a full screen? How would I maximize compatibility for the many screen resolutions out there?
-
With the patch above, you define your custom-resolution main hall in the 640x480 or 1024x768 section (usually the latter). The resolutions of the background bitmap and the mask should match each other, but they can otherwise be any resolution. Animation coordinates are based on the actual resolution of the background bitmap. +Tooltip Y should be about 13 pixels less than the main hall's height, assuming you're using the default font.
I understand that this isn't ideal, so I'll look into ways to define more resolutions, among other things. It will probably take some time, though.
-
If I launch the the retail GOG version of FS2, it has black borders on the left and on the right, because FS2 retail only supports 4:3 aspect ratio resolutions (and my GPU control panel keeps the original aspect ratio, but scales to the up-down edge of the monitor). Now that FSO has non-stretched menus, you get those EXACT same borders with 16:9 resolutions, which is good, because it resembles 100% the original behaviour.
Really? :wtf: Because I agree, that is good -- resembling the original behavior is 100% what we want. Perhaps I'm experiencing a build-specific problem.
Maybe you have some odd GPU control settings? Because what you say doesn't make any sense.
See the attached image. This is on a 1920x1200 monitor, playing at 1024x768. It's only with m!m's browser build (which is based on Antipodes); regular trunk builds display properly.
To be clear, I have no objection to pillarboxing or letterboxing around the main hall in order to get it to display properly in nonstandard resolutions.
[attachment deleted by an evil time traveler]
-
Antipodes (r10488) doesn't have Yarns no-stretch-menus patch (trunk r10544) so it's probably a different issue.
-
See the attached image. This is on a 1920x1200 monitor, playing at 1024x768. It's only with m!m's browser build (which is based on Antipodes); regular trunk builds display properly.
To be clear, I have no objection to pillarboxing or letterboxing around the main hall in order to get it to display properly in nonstandard resolutions.
:wtf: Is this also a problem with the antipodes builds or the standard chromium builds? Maybe I screwed something up when I hacked that webpage display in there.
-
I'd need an antipodes build to check. I don't have an antipodes project currently set up on my machine and I need to dedicate my coding time to filling some of Mjn's overdue requests.
EDIT: The same shrunken bug occurs in your standard chromium build.
-
That patterned border mockup looked very nice. As long as mods can do custom ones I'd prefer to see that as a default.
-
I don't care at all if it's default or not. What I care for is the readability of recommendation texts, that usually come in red and are barely readable anymore. Not sure if it's build related or not though, but this glitch is new to me. The font is so heavily blurred that people with slight viewing discrepancies really get in trouble to read the affected texts.
-
I've noticed one other problem with this.
I wanted to do screen shots with the menus streched and not stretched. I had put the -stretch_menu custom command line in.
I'm not sure if this is a launcher problem or a problem with the build but the command line does not appear in the custom command line in the WXlauncher and I can't modify or remove it. It appears to be treated as if it is an option that can be selected. This could be a problem for custom mods if people want to switch back and forth between stretched and non stretched.
WxLauncher only saves what flags were entered, not how they were entered. In the case of -stretch_menu, you can toggle it just like most of the other flags; it's called "Stretch interface to fill screen" and is found in the Gameplay section.
Also, I couldn't get the [settings] stuff to work at all. For example, I tried inserting the following in the mod.ini file of the 2014 MediaVPs, and no matter what launcher I used (I tried Launcher 5.5g and wxLauncher), I didn't get ship models in the ship-select screen. (And yes, I did select the MediaVPs directly, not a mod that used them.)
[settings]
flags = -ship_choice_3d;
Oh, and I'm almost ready to release a patch that, among other things, includes features to address some of Mjn's concerns, including a way to define more than two (or even just one) resolutions for main halls, as well as a zoom feature that allows a single main hall entry to support a range of aspect ratios without black bars or stretching. (The latter feature is a bit more sophisticated than "zoom in until main hall fills screen completely," and it doesn't do anything unless the modder chooses to utilize it.) I just have to write some documentation first and maybe fix up a few things.
EDIT: Forgot to reply to this:
I don't care at all if it's default or not. What I care for is the readability of recommendation texts, that usually come in red and are barely readable anymore. Not sure if it's build related or not though, but this glitch is new to me. The font is so heavily blurred that people with slight viewing discrepancies really get in trouble to read the affected texts.
Can you provide a screenshot showing the problem? (And please provide it as PNG, not JPG.)
-
Just so you know, there is already a library out there that can handle parsing of quite a few 3D formats, including DAE: https://github.com/assimp/assimp
EDIT: Sorry wrong thread...
-
EDIT: Forgot to reply to this:
I don't care at all if it's default or not. What I care for is the readability of recommendation texts, that usually come in red and are barely readable anymore. Not sure if it's build related or not though, but this glitch is new to me. The font is so heavily blurred that people with slight viewing discrepancies really get in trouble to read the affected texts.
Can you provide a screenshot showing the problem? (And please provide it as PNG, not JPG.)
(http://s7.directupload.net/images/140407/arso9kj6.png)
It seems that it's everything but a bug or strange feature concerning the builds, but a problem with my new 42" flatscreen that I use as monitor. When I look at this image on my 22" monitors (got two of them) it looks just fine, the red words are readable just fine. Sorry if I panicked the wrong people. Will have to find out what the reason for this is myself.
-
Just so you know, there is already a library out there that can handle parsing of quite a few 3D formats, including DAE: https://github.com/assimp/assimp
Uh, I think you meant to post that in this thread (http://www.hard-light.net/forums/index.php?topic=87282.0). We're not discussing 3D models here.
-
(http://s7.directupload.net/images/140407/arso9kj6.png)
The skinny FotG font is pretty indistinct over that grey background. I could definitely see that being a problem on some monitors. The red might also cause problems for red-green color blind people as it looks pretty faint.
-
OK, the patch is finally ready. With it, you can define any number of resolutions for main halls, as well as when and how each resolution is displayed. Here it is:
https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/main_hall_enhancement.patch (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/main_hall_enhancement.patch)
And here is a build, based on revision 10842:
https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/main_hall_enhancement_build.zip (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/main_hall_enhancement_build.zip)
I have also made a mod (here) that includes two simple main halls for testing this feature, each with its own campaign file:
https://dl.dropboxusercontent.com/u/89353583/FreeSpace/main_hall_test.zip (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/main_hall_test.zip)
Details are in the campaign descriptions.
Now, on to the documentation. This feature adds some additional parameters to mainhall.tbl. Below is a sample table showing each of these parameters, with the new ones marked. More details on these are provided below the table.
;file-wide parameter
$Num Resolutions: 1 ;*new*
;main halls start here
$Main Hall
+Name: mymainhall
+Min Resolution: 1024 768 ;*new*
+Min Aspect Ratio: 1.2 ;*new*
+Bitmap: whatever ;pretend that the resolution of this bitmap is 1920x1080, although any resolution is valid
+Mask: whatever-m
+Music: something
+Substitute Music: something-else
+Help Overlay: anything
+Help Overlay Resolution Index: 2 ;*new*
+Zoom To: 1440 1080 ;*new*
;sounds and animations go here
+Font: 2 ;*new*
+Tooltip Padding: 7 ;*new*
+Tooltip Y: 1065 ;not new, but see note
;more main halls go here
#end
(All of the parameters below are optional unless otherwise noted.)
$Num Resolutions:
Defines the number of resolutions of each main hall in this file. Other main-hall tables are not affected, so you can have, say, two resolutions in mainhall.tbl and three in extrahalls-hall.tbm without messing up the former table.
If there are multiple resolutions, the game will pick the last one that is valid for the screen resolution and aspect ratio. If none are valid, or only one resolution exists, then the first one is used. This is done per main hall, not globally.
The default value is 2.
+Min Resolution:
Defines the minimum valid resolution for this main-hall configuration. Has no effect if this configuration is for the first resolution.
The default value is 0 0 for the first resolution and 1024 600 for subsequent resolutions.
+Min Aspect Ratio:
Defines the narrowest valid aspect ratio for this main-hall configuration. The argument is a single floating-point number that is the quotient of width / height. Has no effect if this configuration is for the first resolution.
Because of possible rounding errors, avoid setting this to a value that exactly matches a common aspect ratio (e.g., 1.6 for 16:10). Instead, set it to a slightly lower value (e.g., 1.59).
The default value is 0.0.
+Help Overlay Resolution Index:
Sets which overlay resolution to use. (With this patch, help.tbl entries are no longer limited to just two resolutions; they can now have just one, three, or more. See the end of this post for details.)
The default value is 0 for the first main-hall resolution, 1 for the second, 2 for the third, and so on.
+Zoom To:
If set, tells the game to zoom in to this area of the main hall, cropping off the edges if necessary. This parameter allows you to make a single main-hall configuration that supports a range of aspect ratios without black bars or stretching.
In the example table above, the background bitmap is 1920x1080, but the zoom area is 1440x1080 (a 4:3 resolution). In this instance, if the screen aspect ratio is narrower than 16:9 but not narrower than 4:3, then the sides are cropped off so that the screen can be filled. If the aspect ratio is narrower than 4:3, then the main hall is still cropped to the 4:3 area, leaving black bars if -stretch_menu is not set. The reverse is also possible; the background could be 1280x960 with the zoom area being 1280x720. One of the main halls in the example mod even combines these examples!
If you do use this parameter, then make sure that all of the doors (or buttons) are inside the zoom area. If you don't, then they may go offscreen, making them impossible to click!
+Font:
Defines the font used for the text in this main hall. The number here points to a font entry in fonts.tbl, with 0 pointing to the first one. Does not affect pop-up messages or the F1 overlay.
The default value is 0 (normally font01.vf).
+Tooltip Padding:
Defines how much the shading area should extend above the tooltips. Also affects the "Press F1 for help" text at the top.
This was previously hardcoded as two values, one for each resolution: 4 for 640x480 and 7 for 1024x768. These are still used as the default values.
+Tooltip Y:
EDIT: This parameter is no longer required in my patch. If it's omitted, then the game will place tooltips at the bottom of the visible main-hall area.
This parameter isn't new; in fact, it's been required since retail, and it still is. However, because main halls can now use resolutions other than 640x480 and 1024x768, and because perhaps only two people other than Volition employees have even looked at it, it deserves attention. The value here tells the game where to place the tooltips, which appear when you hover your mouse over a door. This value works like the Y values of the animations, meaning the tooltips are actually placed on a specific part of the main hall, not a certain number of pixels from the bottom of the screen! Because of this, you may need to adjust this to suit your main hall's resolution. To get a good value for this parameter, I suggest using the following formula:
height - ((height - zh) / 2) - fh - 4
...where:
height = the height of the main hall
zh = the height of the zoom area; if no zoom area is defined, then use the main hall's height instead
fh = the height of the font (9 for font01, 18 for font02, and 11 for font03)
Help.tbl/*-hlp.tbm has also been extended to support more than two resolutions. Two new optional parameters have been added, both of which belong at the beginning of a section, just after the section name. Here they are:
+resolutions
Defines the number of resolutions in this overlay. May be 1 or greater.
If this is set to anything other than 2, then all other parameters in this overlay that normally take two sets of values must now have a set of values for each resolution. For example, if an overlay has four resolutions, then any bracket parameter must have four pairs of values instead of two.
The default value is 2.
+font
Defines the font used for the text in this overlay. The number here points to a font entry in fonts.tbl, with 0 pointing to the first one. Takes one value for each resolution.
The default value for each resolution is 0 (normally font01.vf).
Oh, and this patch allows preload screens to be any resolution and aspect ratio, not just 640x480 and 1024x768. However, the two-resolution limit is still there, and the resolutions are chosen in the same manner as before, with 1024x600 being the minimum for the higher resolution.
-
I would love to test this. Any chance you could provide builds?
-
(http://s7.directupload.net/images/140407/arso9kj6.png)
The skinny FotG font is pretty indistinct over that grey background. I could definitely see that being a problem on some monitors. The red might also cause problems for red-green color blind people as it looks pretty faint.
No idea what your monitor does, Belisarius, but some video compression algorithms have serious problems with red, and make it very blurry. Youtube's compression is an example. (although the text there doesn't play well with the bright background, but that's more an interface issue than a FSO issue)
-
I would love to test this. Any chance you could provide builds?
A link to some builds has been added to my previous post.
-
Finally tested this out. This is very, very good. The premise is great. I toyed around a bit with my assets and things work as I would expect. One question, your MainHallTest2-hall.tbm does not define mainhalls for 640x480 or 1024x768. How is the code handling that? Is it actually scaling the graphics to fit into the lower resolutions?
The ability to define a 16:9 mainhall that can also be used for full screen setups is brilliant. This patch gets my vote.
Tooltip Y: don't care what you do.. makes no difference from a design perspective to me.
Help.tbl stuff.. do people use help overlay? :p I realize it needs to be considered.. so whatever works best there.
What are the next steps to get this in? (Obviously post 3.7.2, which is sad.)
-
One question, your MainHallTest2-hall.tbm does not define mainhalls for 640x480 or 1024x768. How is the code handling that? Is it actually scaling the graphics to fit into the lower resolutions?
If a main hall has only one resolution, then the game uses that for every resolution, scaling down if necessary. (I'll add this to the documentation.)
Tooltip Y: don't care what you do.. makes no difference from a design perspective to me.
In that case, I'll go ahead with my proposed change.
-
I think we can make an exception and put it into 3.7.2. Given that I have no idea how long it's going to be until the next stable release, putting people in a situation where they can't use trunk for released (or soon to be released) campaigns is something I want to avoid.
-
With the new automated release stuff, I'm kind of just waiting for people to say 'go' and I can have a release out shortly, assuming all the computers are behaving that day.
-
I updated the patch and build to make +Tooltip Y optional and to fix an assertion that I forgot to change. I also removed the +Tooltip Y line in MainHallTest2-hall.tbm.
-
Looks good to me. What's left on this.. possible help.tbl stuff?
-
*Tap* *Tap* *Tap* Hellooooooooo? Is this thing on?
RC2 is out and nothing further has been discussed or finished on this.
-
The only thing left to do is add support for more than two resolutions in help.tbl. Before I try that, though, I'm waiting for my help.tbl patch in Mantis 2812 (http://scp.indiegames.us/mantis/view.php?id=2812) to be committed. I'm waiting because if I make a patch for this feature now, then it would almost certainly conflict with the Mantis 2812 patch.
-
I'll do my best to review & commit mantis2812 by the end of this weekend...
Edit: I've reviewed the code, run some tests, and it all looks good. There's just one thing to be resolved and that is that the patch needs updating to apply cleanly to the latest trunk. Could you do that, I'll have a final look, and then I'll commit it.
Edit2: The fix for mantis2812 has been committed in r10739.
-
I updated the patch so that it applies cleanly to the current trunk. The build has also been updated. Help overlays are still limited to two resolutions; I'm working on fixing this now, although I'm having some difficulty with getting the correct lines to be drawn. If I can't sort this out, then I'll just post what I've got and let you guys find out what's wrong.
-
I have updated the patch and build again. Help.tbl has now been upgraded to support more than two resolutions; see this post (http://www.hard-light.net/forums/index.php?topic=87253.msg1743626#msg1743626) for details. The example mod has also been modified to utilize this feature. (Creating an overlay without a graphical editor is a real PITA, so the mod's overlays don't have a label for every button.)
If no bugs are found, then this patch is ready for review.
-
I know it's not a brilliant solution, but I found the "help_reload" function in the debug console made it a lot easier to modify the help overlays. i.e. instead of
1) start FSO, choose pilot, press F1, exit FSO, modify table, restart
you can do:
2) press F1, modify table, start debug console, type "help_reload" (or up-arrow), press F1
Anyway, if Mjn can test the feature, I can review the code.
-
I made a slight tweak to the patch: Instead of +Help Overlay Resolution Index defaulting to 0 for the first main-hall resolution and 1 for the others, it's now the same as the main hall's own resolution index (0 for the first, 1 for the second, 2 for the third, etc.). (If the overlay is not available in the requested resolution, then no overlay will appear.)
Now I think the patch is really ready for review.
-
I'm not all too familiar with the help stuff.. but I did some basic tests and everything seems to work quite nicely! I've no complaints.
-
I'm also liking the change very much and haven't noticed anything broken, though I still need remember to access the options screen while in mission. Cause I keep forgetting.
-
I have a slight problem with the current patch:
(http://deviance.duckish.net/pictures/fs2_open_3_7_1_SSE2%202014-06-20%2018-08-11-98.png)
Other than that, it all looks good to me.
-
I updated the patch and builds again to fix the problem that AdmiralRalwood described above.
-
The patch looks good to me. I guess this can be put into trunk.
-
I've finally reviewed the patch (sorry about the tardiness :nervous:).
Overall it looks good, both test mods seem to run fine on Linux when testing with 4:3, 16:9 & 5:4 resolutions (all tested in a window).
On the code, I've got a few comments (uh oh).
1)
+ //mprintf(("Found text %d on overlay %d - location (%d,%d) @ 640x480 :: location (%d,%d) @ 1024x768\n", currcount, overlay_id, help_overlaylist[overlay_id].textlist[GR_640][currcount].x_coord, help_overlaylist[overlay_id].textlist[GR_640][currcount].y_coord, help_overlaylist[overlay_id].textlist[GR_1024][currcount].x_coord, help_overlaylist[overlay_id].textlist[GR_1024][currcount].x_coord));
...
+ //mprintf(("Found rbracket %d on overlay %d - location (%d,%d) @ 640x480 :: location (%d,%d) @ 1024x768\n", currcount, overlay_id, help_overlaylist[overlay_id].rbracketlist[GR_640][currcount].x_coord, help_overlaylist[overlay_id].rbracketlist[GR_640][currcount].y_coord, help_overlaylist[overlay_id].rbracketlist[GR_1024][currcount].x_coord, help_overlaylist[overlay_id].rbracketlist[GR_1024][currcount].y_coord));
...
+ //mprintf(("Found lbracket %d on overlay %d - location (%d,%d) @ 640x480 :: location (%d,%d) @ 1024x768\n", currcount, overlay_id, help_overlaylist[overlay_id].lbracketlist[GR_640][currcount].x_coord, help_overlaylist[overlay_id].lbracketlist[GR_640][currcount].y_coord, help_overlaylist[overlay_id].lbracketlist[GR_1024][currcount].x_coord, help_overlaylist[overlay_id].lbracketlist[GR_1024][currcount].y_coord));
Maybe remove the commented out mprintf's, or convert them to nprintf's? (maybe Parse or a new category called Help?)
(I know these are existing comments, but a cleanup would be good).
2)
In the following places the code should probably be removed rather than commented out.
code/menuui/mainhallmenu.cpp (line 354->363, and 1762->1779, approx 1970)
3)
When setting a custom font for a mainhall, should the font be saved first (with gr_get_current_fontnum()) and restored to the previous value instead of always setting it back to FONT1?
i.e. this is used several times
gr_set_font(Main_hall->font);
(code)
gr_set_font(FONT1);
(Or it is known that the font is always FONT1 prior to this point?)
4)
These statements don't compile using GCC:
(code/gamehelp/contexthelp.cpp)
+ SCP_vector<SCP_vector<help_pline>> plinelist;
+ SCP_vector<SCP_vector<help_text>> textlist;
+ SCP_vector<SCP_vector<help_left_bracket>> lbracketlist;
+ SCP_vector<SCP_vector<help_right_bracket>> rbracketlist;
Just add a space between the >> and it's fine; i.e.
+ SCP_vector<SCP_vector<help_pline> > plinelist;
+ SCP_vector<SCP_vector<help_text> > textlist;
+ SCP_vector<SCP_vector<help_left_bracket> > lbracketlist;
+ SCP_vector<SCP_vector<help_right_bracket> > rbracketlist;
Otherwise it looks good :)
-
On the code, I've got a few comments (uh oh).
...
Regarding your first comment, it's probably a good idea to delete those lines, considering that they assume that only two resolutions exist (which isn't necessarily true with this patch). I'll make this change and the other changes that you suggested in the next version of the patch, which should be ready within 24 hours. EDIT: It's updated now!
-
Thanks! The new patch looks good, I'll commit it tonight (unless someone else gets there 1st)
-
I'd like (for the sake of OCD) to suggest that lines 208 & 226 see a slight change for the actual commit:
+ if (overlay_id >= 0 && overlay_id < num_help_overlays && resolution_index >= 0 && resolution_index < help_overlaylist[overlay_id].num_resolutions) {
...
+ if ( overlay_id >= 0 && (Help_overlay_flags & (1<<overlay_id)) && resolution_index >= 0 && resolution_index < help_overlaylist[overlay_id].num_resolutions ) {
into:
+ if ( (overlay_id >= 0) && (overlay_id < num_help_overlays) && (resolution_index >= 0) && (resolution_index < help_overlaylist[overlay_id].num_resolutions) ) {
...
+ if ( (overlay_id >= 0) && (Help_overlay_flags & (1<<overlay_id)) && (resolution_index >= 0) && (resolution_index < help_overlaylist[overlay_id].num_resolutions) ) {
This will help in readability at a minimum even if it affects nothing else.
-
Committed in r10844, including Zacam's suggestion, a minor line-breaks addition from me on the same lines and all trailing whitespace removed. Thank you Yarn :)
-
Unfortunately, the patch (r10844) seems to break cockpit displays (http://www.hard-light.net/wiki/index.php/Ships.tbl#.24Cockpit_Display:). I suspect the changes to hud.cpp, but haven't confirmed if it's that or something else; I do see some traces of the HUD elements on the cockpit (in the wrong places), which is why I think it has something to do with stretching/scaling going wrong. I don't have a testcase to provide though.
-
I'm guessing you didn't create a mantis ticket with a test case.
-
Aaand here's even a ticket with a testcase. (http://scp.indiegames.us/mantis/view.php?id=3078)
-
Is this changed? I play on some old Nightly of 3.7.1 to have my interface unstreched. Sorry guys for being lazy asshat, but four pages of text caused tl;dr syndrome :P
-
Is this changed? I play on some old Nightly of 3.7.1 to have my interface unstreched. Sorry guys for being lazy asshat, but four pages of text caused tl;dr syndrome :P
This patch has been in trunk since r10844. I'm not sure what you mean by "some old Nightly of 3.7.1 to have my interface unstretched", unless... are you saying you've been using an old version of FSO to avoid pillarboxing? That is what the -stretch_menu (http://www.hard-light.net/wiki/index.php/Command-Line_Reference#-stretch_menu) command-line option is for (and would be the opposite of "unstretched").
-
To be precise I'm using 10451 to avoid black bars on either side of the game window in newer builds. I was thinking that something is wrong with my PC and I'm looking for some solution. Custom flag worked, thanks for the help.