[High Max]

*_*

[Fury]

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.

[High Max]

*_*

[Bob-san]

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.

[Fury]

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.

[The E]

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.

[High Max]

*_*

[Fury]

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.

[The E]

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.

[High Max]

*_*

[Fury]

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.

[chief1983]

Yahoo Answers lol.  I'd find a better source for your technical research

[Genghis]

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.

[taylor]

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.

[Bob-san]

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.

[taylor]

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.

[High Max]

*_*

[Bob-san]

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.

[Iss Mneur]

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?

[chief1983]

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.