[Swifty]

Looks like it should be possible to keep it all 4:3 and not have to stretch the width, but it's going to take some work to rip out and redo all of the current scaling/resizing hacks.  The only real question would be how to handle the HUD, since with this newer method it would also stay 4:3, even though you would get the full width otherwise.

I think that would fix 80% of the widescreen issue; even 16:9 makes it somewhat tough to read the HUD.

Isn't there someone that is already working on redoing the HUD so that it will scale correctly even when the aspect ratios are changed?

I guess I should show some of my cards here. I've already told some people on #scp about this stuff but it's probably time to put it on the record.

One of the things that's part of the whole HUD rewrite is that I rebuilt hud_gauges.tbl to define different gauge layouts for different resolutions and for different aspect ratios. Just as the current HUD right now uses a 1024x768 or 640x480 base resolution to scale HUD gauges, I'm letting HUD designers modify this scale and apply it to resolutions that follow a set of designer-defined rules.

So you can, as an example, define a HUD layout to work exclusively for wide screen resolutions that range from 1280x720 to 1440x900 and base the scaling on, say, 1280x800. So, instead of a 1024x768 4:3 HUD stretched all the way to 1440x900 16:10 screen, we can have a 1280x800 16:9 HUD stretched to a 1440x900 screen or shrunk down to 1280x720.

And maybe you want to be more stringent than that. There's nothing stopping you from defining a rule that says a 1440x900 HUD layout can only be used for a 1440x900 screen size.

Or maybe you want to be more liberal than that. There's nothing stopping you from designing a HUD that's based on the typical GR_1024 scale, and apply that to all resolutions as we've always done.

Or we can go in between. Apply the default 1024x768 layout to only apply for full screen resolutions while supplying your own layout in a 1280x720 scale to only apply to wide screen resolutions

I'm just worried how kosher this solution will be based on the fact that this feature I concocted is based on manipulating the values of Gr_resize_x and Gr_resize_y and restoring the original values after drawing the HUD. It's the best solution I could think of without shaking the boat too much in the graphics department while giving the artists enough power over the FS2 hard coded HUD.

EDIT: Oh yeah, btw, I eliminated the hard coded constants for the HUD. Each fixed HUD gauge now draws relative to the top left corner of itself instead of the top left corner of the screen, which will, yes, let us do some serious feng shui with HUD gauges.

EDIT2: Oh and yes, the original FS2 retail HUD layout and scale will still be the same if no applicable HUD layout can be found. That means it's up to the modders/FSU to deliver a properly scaled HUD with this feature.

[Fury]

False.

It's both very CPU and GPU limited.

I have Q9550 and Radeon 4870. While FSO uses 100% of the second core, GPU hovers only around 30%. If I crank (box) AA and AF to max from CCC, GPU usage rises only about 2%. So I really can't say FSO is GPU limited by far, first and foremost the bottleneck is CPU.

Edit: 24x edge-detect AA is flat 10% increase, but still not even close to using 50% of 4870 GPU processing power.

[taylor]

I have Q9550 and Radeon 4870. While FSO uses 100% of the second core, GPU hovers only around 30%. If I crank (box) AA and AF to max from CCC, GPU usage rises only about 2%. So I really can't say FSO is GPU limited by far, first and foremost the bottleneck is CPU.

Edit: 24x edge-detect AA is flat 10% increase, but still not even close to using 50% of 4870 GPU processing power.

The CPU usage can be very deceptive.  It really depends on what options you are using and when you are measuring.  Using v-sync for instance can cause 100% CPU usage due to blocking calls.  Without v-sync, and using -no_fps_capping, it will use 100% of the CPU all of the time since it's rendering as much as it can as fast as it can (ie. 1000+ FPS).  That's not to say that CPU usage won't get high when in-game of course, but even my my slow machine it is common to have it at around 50-60% CPU on average, with MediaVPs.

[Fury]

I use BP WiH intro cutscene to measure FSO performance. CPU is definitely the first bottleneck far ahead GPU.

[castor]

I think you basically need a GPU that is beefy enough to handle the AA, and the rest will be up to CPU.
But with a lesser GPU it doesn't really help to up the CPU either.

[Vasudan Admiral]

<snip>

Now that sounds very very cool.

Also sounds like a massive leap towards custom 3d cockpit HUD layouts? Perhaps not actually 3d RTT stuff, but more in the sense of being able to define a HUD gauge layout to go with each cockpit model. Ie, a HUD layout profile designed for 1024x768 and 'TerranCockpit01' kind of thing to make it look like some of the HUD gauges are being rendered onto the ships computer screens.

I've not been keeping up with your plans about the HUD and cockpits etc, so you might have something much better in mind already?

[Swifty]

Also sounds like a massive leap towards custom 3d cockpit HUD layouts? Perhaps not actually 3d RTT stuff, but more in the sense of being able to define a HUD gauge layout to go with each cockpit model. Ie, a HUD layout profile designed for 1024x768 and 'TerranCockpit01' kind of thing to make it look like some of the HUD gauges are being rendered onto the ships computer screens.

I've not been keeping up with your plans about the HUD and cockpits etc, so you might have something much better in mind already?

Oh yeah. That.

Yeah, you can define HUD layouts per ships.

Cockpit display based HUD gauges using render to texture targets is still on the table as it's a major milestone for a certain project I'm working on. I have some proof of concept code working for that already that use the new HUD framework.

[Vasudan Admiral]

Squeee!

Brilliant.

[Bob-san]

Looks like it should be possible to keep it all 4:3 and not have to stretch the width, but it's going to take some work to rip out and redo all of the current scaling/resizing hacks.  The only real question would be how to handle the HUD, since with this newer method it would also stay 4:3, even though you would get the full width otherwise.

I think that would fix 80% of the widescreen issue; even 16:9 makes it somewhat tough to read the HUD.

Isn't there someone that is already working on redoing the HUD so that it will scale correctly even when the aspect ratios are changed?

I guess I should show some of my cards here. I've already told some people on #scp about this stuff but it's probably time to put it on the record.

One of the things that's part of the whole HUD rewrite is that I rebuilt hud_gauges.tbl to define different gauge layouts for different resolutions and for different aspect ratios. Just as the current HUD right now uses a 1024x768 or 640x480 base resolution to scale HUD gauges, I'm letting HUD designers modify this scale and apply it to resolutions that follow a set of designer-defined rules.

So you can, as an example, define a HUD layout to work exclusively for wide screen resolutions that range from 1280x720 to 1440x900 and base the scaling on, say, 1280x800. So, instead of a 1024x768 4:3 HUD stretched all the way to 1440x900 16:10 screen, we can have a 1280x800 16:9 HUD stretched to a 1440x900 screen or shrunk down to 1280x720.

And maybe you want to be more stringent than that. There's nothing stopping you from defining a rule that says a 1440x900 HUD layout can only be used for a 1440x900 screen size.

Or maybe you want to be more liberal than that. There's nothing stopping you from designing a HUD that's based on the typical GR_1024 scale, and apply that to all resolutions as we've always done.

Or we can go in between. Apply the default 1024x768 layout to only apply for full screen resolutions while supplying your own layout in a 1280x720 scale to only apply to wide screen resolutions

I'm just worried how kosher this solution will be based on the fact that this feature I concocted is based on manipulating the values of Gr_resize_x and Gr_resize_y and restoring the original values after drawing the HUD. It's the best solution I could think of without shaking the boat too much in the graphics department while giving the artists enough power over the FS2 hard coded HUD.

EDIT: Oh yeah, btw, I eliminated the hard coded constants for the HUD. Each fixed HUD gauge now draws relative to the top left corner of itself instead of the top left corner of the screen, which will, yes, let us do some serious feng shui with HUD gauges.

EDIT2: Oh and yes, the original FS2 retail HUD layout and scale will still be the same if no applicable HUD layout can be found. That means it's up to the modders/FSU to deliver a properly scaled HUD with this feature.

Looking towards the future, there would be a LOT of different HUD aspect ratios.

4:3
5:4
8:5
16:5
24:5
30:16

And that's assuming that x:10 can be scaled down properly to x:9. Or, perhaps a better choice would be to forget x:10 and have "black bars" for x:10 using x:9.

[CP5670]

The CPU usage can be very deceptive.  It really depends on what options you are using and when you are measuring.  Using v-sync for instance can cause 100% CPU usage due to blocking calls.  Without v-sync, and using -no_fps_capping, it will use 100% of the CPU all of the time since it's rendering as much as it can as fast as it can (ie. 1000+ FPS).  That's not to say that CPU usage won't get high when in-game of course, but even my my slow machine it is common to have it at around 50-60% CPU on average, with MediaVPs.

FS2's performance is rather strange in general. It runs nicely most of the time, but if a mission has a lot of stuff going on, the framerate consistently drops to the 40-50 range, regardless of the hardware used. I have gotten essentially the same performance on a couple of generations of CPUs and video cards now, so there is no obvious bottleneck in either of them. The E said it might be the collision detection code bogging things down, but the game doesn't seem to respond at all to increases in single-threaded CPU speed.

[The E]

And that's assuming that x:10 can be scaled down properly to x:9. Or, perhaps a better choice would be to forget x:10 and have "black bars" for x:10 using x:9.

An even better choice would be to read what Swifty said, and understand it. With this new system, creating a new HUD Layout for those display aspect ratios is not a problem at all.

And since 16:10 seems to be very popular for PC monitors, using black bars to get it down to 16:9 is the most horrible solution possible.

[Bob-san]

And that's assuming that x:10 can be scaled down properly to x:9. Or, perhaps a better choice would be to forget x:10 and have "black bars" for x:10 using x:9.

An even better choice would be to read what Swifty said, and understand it. With this new system, creating a new HUD Layout for those display aspect ratios is not a problem at all.

And since 16:10 seems to be very popular for PC monitors, using black bars to get it down to 16:9 is the most horrible solution possible.

What I meant was blank bars; having it scale at aspect. So a 16:9 hub would leave the top 16:.5 and the bottom 16:.5 "blank"; without having the HUB overlaid. And the problem now, looking forward, is 16:10 is being replaced in favor of 16:9. Why? I haven't got a clue; I prefer more vertical space.

[The E]

But the question is, why would you do this in the first place? The new code gives you the opportunity to create layouts for _every aspect ratio possible_, why not use that?

[Bob-san]

But the question is, why would you do this in the first place? The new code gives you the opportunity to create layouts for _every aspect ratio possible_, why not use that?

4:3
8:3
12:3
3:4
6:4
9:4
5:4
10:4
15:4
4:5
8:5
12:5
16:9
32:9
48:9
9:16
18:16
27:16
10:16
20:16
30:16
etc

Because there are literally dozens of different aspect ratios. Defining the aspect ratio is actually a lot easier than the resolutions.
4:3; 640x480, 800x600, 1024x768, 1280x960
5:4; 1280x1024
16:9; 1280x720, 1366x768, 1600x900, 1920:1080
16:10; 1280x800, 1440x900, 1680x1050, 1920x1200, 2560x1600
etc
Scaling seems to be the better choice. Alternatively, how about a rewrite where individual boxes can be assigned a position relative to, for example, the overlay or the entire screen resolution? I'm not a programmer, but it DOES seem that there'd be a good bit of work to get every combination working. My list of aspect ratios is only going up to 3 monitors being placed horizontally; it's not including other many-screen possibilities like a second row of monitors.

[The E]

Okay, of those, which ones actually do have a significant user base? It's something where we can create default ones for 4:3, 5:4, 16:9 and 16:10, and others on demand.

[Swifty]

Right now, my code only distinguishes between wide and full aspect ratios. Meaning, if the width divided by height results in a quotient of less than 1.5, it'll assume it's full screen dimensions. If it's greater than 1.5, it assumes it's wide. So that would mean that 16:9 and 16:10 resolutions will be included when specifying a HUD layout for wide screen resolutions. 4:3 and 5:4 resolutions will be included when specifying a HUD layout for full screen resolutions.

It'll be trivial to patch in more specific aspect ratio selectors in my code. I already mentioned that you can select from a range of resolutions (e.g. 1280x720 to 1920x1080) and/or select by aspect ratio (Full or Wide). The resolutions that will be applied to are intersection of the two conditions specified by the designer. I wouldn't make a huge fuss about this, really.

[Bob-san]

My code only distinguishes between wide and full aspect ratios right now. Meaning, if the width divided by height results in a quotient of less than 1.5, it'll assume it's full screen dimensions. If it's greater than 1.5, it assumes it's wide. So that would mean that 16:9 and 16:10 resolutions will be included when making a HUD layout specified for wide screen resolutions for a given range. Or 4:3 and 5:4 resolutions will be included when making a HUD layout specified for full screen resolutions.

It'll be trivial to patch in more specific aspect ratio selectors in my code. I already mentioned that you can select from a range of resolutions (1280x720 to 1920x1080) and/or select by aspect ratio (Full or Wide). The resolutions that will apply will be the union of those conditions specified. I wouldn't make a huge fuss about this, really.

Sounds good to me, though I might suggest adding in "super-wide" (>2.0:1) and "ultra-wide" (>3.0:1).