Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: High Max on March 18, 2010, 03:24:32 am
-
*_*
-
I think the main thing to worry about is your video card specs since computers these days make the video card do most of the game processing.
False.
FSO is CPU limited.
-
*_*
-
Then why is it that I have a quad core Phenom II 3.4GHz processor with 2MB L2 and 6MB L3 and sometimes when I have multiple capships with normal maps on the screen at once, the framerate gets a little worse? Also, why have other threads said that getting a 4xxx series Radeon HD video card would be faster and improve performance drastically than the HD 3870 I currently have? It doesn't make any sense for a game to have nothing to do with a video card. Plus, if it was purely CPU dependent, it wouldn't run so well on a P3 from 1998. So you confused me. Either it was a joke, or something just doesn't sound right. If that is the case, then there is no point upgrading my video card and not much I can do about the processor since it is one of the best out there and at least 30 times faster than a 500MHz P3.
Edit: Or do you mean that if the CPU is very good, then the video card will limit it since it will most likely not be nearly as good as the CPU? But it makes no sense to make the CPU do so much work. If it does use both the video card and CPU, I think that is less efficient and makes it slower. Why would people design FSO to rely so much on the main CPU? That defeats the purpose of the video card.
System instability, corrupt files, incompatibilities, or some combination. And FSO is processor-dependent because much of the original code is inefficient or buggy.
-
Because only one core of your quad-core Phenom is used by FSO.
If you have old single-core CPU that runs at 2GHz and a quad-core CPU that runs at 2GHz, the quad-core only has negligible performance lead because operating system and most other apps you have running can use all cores, but FSO does not.
You see zero performance increase in FSO by upgrading from 3870 to 4870.
-
Also, please remember that FSO's core architecture is from 1999, GPUs were far more specialized back then. Hardware Transform and Lighting, the technology we now refer to as HTL, and which is commonplace in modern graphics units, was just developed back then (I remember playing FS2 on an original GeForce card, which IIRC was one of the first ones to introduce HT&L to the market).
That core architecture has not been changed, and is in fact so hard to change, that doing so will take a very long time.
Now, High Max, I know you can't be bothered to learn technical details, but please try to remember this: If you are aware of these things, chances are, the guys working on it are aware of them as well (painfully so, in some cases), and are working on changing it. However, just like you can't transform a Truck into a Formula One racer over night, you can't transform a game engines core architecture from one paradigm to another by just snapping your fingers.
-
*_*
-
There are no plans whatsoever beyond "yeah, we should do something about it". Don't expect multi-core or GPGPU support in the next few years.
-
Yep, that's pretty much it. There is so much work to do just laying the groundwork for this sort of endeavour that giving any sort of estimate on when it's going to be completed or what it's going to look like when completed would be foolish.
-
*_*
-
Instead of discussing it all again in here, go read existing discussion in the now archived Rendering Project overhaul board.
http://www.hard-light.net/forums/index.php?topic=67715.0
If you want to discuss it further, feel free to post in the above link instead of going off-topic here.
-
Yahoo Answers (http://www.somethingawful.com/flash/shmorky/babby.swf) lol. I'd find a better source for your technical research :)
-
In my experience the biggest bottleneck in games today is memory bandwidth, getting information in and out of the CPU and GPU cores without stalling in cache misses. It would not surprise me one bit if you told me that the busy scene on a Quad Phenom II is bringing-down framerate because of all the texture uploads per frame.
-
I think the main thing to worry about is your video card specs since computers these days make the video card do most of the game processing.
False.
FSO is CPU limited.
False.
It's both very CPU and GPU limited.
On the GPU side: We run through many thousands of very expensive OpenGL state changes every frame that are just due to bad coding. Plus the engine has never really been updated to handle hi-poly models properly so we have massive amounts of overdraw. Having a faster video card can help compensate for these issues, but you aren't going to get a ton of benefit from it at this point in time.
On the CPU side: Same as with the GPU side basically, the code has simply never been upgraded properly to support hi-poly models. The engine was originally written for a software renderer and wastes a lot of time doing calculations that modern graphics cards could do faster. Also things like the collision detection code is extremely inefficient when dealing with more than a rather moderate amount of verts.
Everyone has been something stuff like multi-core support would fix all/most of this, but it won't. Old, inefficient code is going to be just as old and slow whether it's running on 1 core or 100. As the old code gets upgraded bit by bit everyone will start to see improvements regardless of the hardware they are using.
-
I think the main thing to worry about is your video card specs since computers these days make the video card do most of the game processing.
False.
FSO is CPU limited.
False.
It's both very CPU and GPU limited.
On the GPU side: We run through many thousands of very expensive OpenGL state changes every frame that are just due to bad coding. Plus the engine has never really been updated to handle hi-poly models properly so we have massive amounts of overdraw. Having a faster video card can help compensate for these issues, but you aren't going to get a ton of benefit from it at this point in time.
On the CPU side: Same as with the GPU side basically, the code has simply never been upgraded properly to support hi-poly models. The engine was originally written for a software renderer and wastes a lot of time doing calculations that modern graphics cards could do faster. Also things like the collision detection code is extremely inefficient when dealing with more than a rather moderate amount of verts.
Everyone has been something stuff like multi-core support would fix all/most of this, but it won't. Old, inefficient code is going to be just as old and slow whether it's running on 1 core or 100. As the old code gets upgraded bit by bit everyone will start to see improvements regardless of the hardware they are using.
Here's a question: will FSO support (or be supported, unofficially by) Eyefinity or the nVidia equivalent? More or less, will the code run on 30:16 or 27:16 resolutions? I spoke to someone and I know they had 3840x1080 running, but of course the GUI was horribly disfigured.
-
Here's a question: will FSO support (or be supported, unofficially by) Eyefinity or the nVidia equivalent? More or less, will the code run on 30:16 or 27:16 resolutions? I spoke to someone and I know they had 3840x1080 running, but of course the GUI was horribly disfigured.
Unofficially maybe, can't really say for sure how well it might work either way.
I have recently had some thoughts on how to address the GUI issue though (after advising Goober on how to fix something similar). 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.
-
*_*
-
Here's a question: will FSO support (or be supported, unofficially by) Eyefinity or the nVidia equivalent? More or less, will the code run on 30:16 or 27:16 resolutions? I spoke to someone and I know they had 3840x1080 running, but of course the GUI was horribly disfigured.
Unofficially maybe, can't really say for sure how well it might work either way.
I have recently had some thoughts on how to address the GUI issue though (after advising Goober on how to fix something similar). 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.
-
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?
-
Swifty has been tackling this issue right now actually. He's rewriting a big hunk of the HUD code, including the horribly hacked together custom gauges stuff.
-
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.
-
False.
It's both very CPU and GPU limited.
:wtf:
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.
-
:wtf:
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.
-
I use BP WiH intro cutscene to measure FSO performance. CPU is definitely the first bottleneck far ahead GPU.
-
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.
-
<snip>
Now that sounds very very cool. :D
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?
-
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. :P
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.
-
Squeee!
Brilliant. :D
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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).