[Stormkeeper]

most single cores being at least 2.5 Ghz

Fixed. And single cores aren't produced anymore.

Mine is a 1.98 Ghz single core. Runs FS2 fine, when paired with my Radeon.

[colecampbell666]

1.5 Ghz P4, 9550 Radeon 256 MB, 2 GB RAM.

[Flipside]

I can run Freespace on the server, which is a 1.4Ghz AMD thing with an AGP X1600 or something

The thing about multithreading is, how much is it needed? What would it do? I would have thought that multithreading anything that accesses the BSP tree for the models would be pointless, since just about everything uses the tree at some point, whether for placing, detecting or performing functions on in-game objects, so you'd run a real risk of two threads trying to alter the same pointer at the same time, which is bad.

Even now I have to cripple one of my cores to play Freespace 2 because the game just runs too fast on 2-cores, Freespace 2 wasn't designed to be multi-core, it was designed for computers about 1/10 of the speed of modern systems.

I personally feel that code-level optimisation is far more important than system-specific ones, for the kind of game it is.

[Fenrir]

I got freespace to run on my old laptop, which had 512 megs of ram and... Intel GMA900. It used a LOT of virtual memory. <_<

But on topic... Last time I tried making FS2 run on just one processor it ran slower than with the two. Well, not so much slower as choppier. Sorta weird, as in the past I`d heard of those who have had to change the affinity to just one for it to run better. Did the opposite in my case.

[blowfish]

*cough*offtopicandnotrelavant*cough*

Seriously, why has this thread descended into people just posting their system specs (aside from Flipside's post which was relevant)?  It used to be about multi-threading in the FSO engine (which is not going to happen)...

[Stormkeeper]

If it didn't run off topic, then I'd be slightly worried. In any case, we have established the fact that multi-threading for FSO is impossible without a complete rewrite of the engine, and even if the SCP got that bored, the benefits would be outweighed by the costs. Vastly outweighed, mostly due to the relative age of the game, that the most older, lower spec computers can run FSO in all its shiny glory with little to no trouble. Single cores run it fine, so no reason to fix what ain't broken.

[meego]

If it didn't run off topic, then I'd be slightly worried. In any case, we have established the fact that multi-threading for FSO is impossible without a complete rewrite of the engine, and even if the SCP got that bored, the benefits would be outweighed by the costs. Vastly outweighed, mostly due to the relative age of the game, that the most older, lower spec computers can run FSO in all its shiny glory with little to no trouble. Single cores run it fine, so no reason to fix what ain't broken.

Nothing to add. I fully agree.

[Flaser]

While I find the pro-contra discussion over multi/single core programming interesting, it has little to do with SCP development.

IIRC the most resource intensive part of the code right now is collision detection. That bears some thought, since our models have become a lot more complex and therefore the said code has to deal with even more data.

It's like a muscle car that just recieved a brand spanking new motor (HTL and now shader support) with great transmission system (the various media supports from TGA through DDS to EFF) with an old muffler (collision detection, the pof format) full of grease and debris...and now we're forcing the said muffler to handle the exhaust from a supercharged monster.

Talking about multi-threading the code is like wondering whether we should install turbo.

[castor]

But is the collision detection issue to be solved by adding horse powers, or by a new design?
Not that I'd know anything, I just can't recall the conclusion from the last discussion about it..

[karajorma]

It needs a code change. The models are getting higher poly about as fast as average horsepower increases.

[chief1983]

I don't know how much it's been looked at, but is the reason it's taken so long just that it's difficult to update, it would break backwards compatibility, or both?

[taylor]

It's just a whole lot of work.  I've tried optimizing the current code, but there is really just so much that can be done there.

Here is some of the changes that it needs to actually work well:

• Scene management.  This is a very basic idea, where collision detection is done for every object in a scene at one time.  If you look through the code you will see that it often does collision checks against the same object multiple times each frame.  What really needs to happen is to process all objects at once, store that info, and then reference that single source later.
  
  
• Cache collision info for models.  It currently has to walk the BSP tree every time it does a collision check on a model.  Given the complexity of the models it should help tremendously if the BSP tree was processed into a friendly chunk of data which is optimized specifically for collision detection.
  
  
• Use index buffer information for collision detection checks.  We set that stuff up to optimize rendering, but the same info can be used to optimize collision detection too since it will reduce the number of vertexes to run through.
  
  
• Change to POFs to use specific collision detection geometry.  This one is obvious.  This is a game and not some ultra-realistic physics demo engine, so accurate collision detection isn't really needed, much less wanted.  We need it fast, not accurate.  Doing collision checks against LOD1 is one way to go, but it can be even simpler than that in most cases.  The geometry for collision detection doesn't have to ever been seen except by the model maker, it just needs to work for collision checks.  It can be totally ugly to look at, so long as it basically covers the geometry that LOD0 uses.  A lot of existing LOD1s can't be used for collision detection since they don't really match up to LOD0 at all.  And a well optimized model for collision detection should require fewer verts than a LOD1, being more in the LOD2 area, but still basically accounting for all of the geometry in LOD0.

Any single one of those changes would help, but we need all of them for the code to really work well.

[karajorma]

I've already asked a couple of coders I know to look into the last of those Taylor. In fact I believe one of them said he was sending you a PM about it a few days ago. I'll point them in this direction though.

The problem with using a lower LOD is that you get invisible walls/flythrough surfaces with many of the LODs currently in existence (I know Wanderer tested that out earlier this week too). How hard would it be to use a separate special purpose mesh instead?

[Flipside]

In retrospect, it might have been a good idea to suggest people used detail boxes more heavily and do away with the standard LOD system. I know that's impossible, it's just conjecture, but that way you could have divided out just the 'hull' of the ship for ship collision detection, and ignored the details.

[taylor]

The problem with using a lower LOD is that you get invisible walls/flythrough surfaces with many of the LODs currently in existence (I know Wanderer tested that out earlier this week too).

And this is basically what I said to Wanderer in his PM.  Because of the geometry differences you couldn't use anything but LOD1 and even then only if it were a very well designed model and LOD setup.  It's not just the invisible surfaces problem though, it's things like decals, particle effects, laser hits, etc.  Collision detection not only tells you whether something hit but where it hit as well and those things are more interested in the "where".  But really, if all of the other things in the list were taken care of, the only models that would really need a separate collision model would be ones in the 40,000+ range.  Things like really large and detailed ships, planets, or terrain in other words.

If you take #2 to be converting the BSP data into an efficient octree for collision checking then you can end up cutting down on the number of verts to check to almost nothing in comparison.  Right now the collision code checks the bounding box and if that scores a hit then it will check each vert until it figures out the closest possible hit.  With an octree you can cut that down to just looking at a small group of verts that you know for sure is going to have a hit on it.  So this means that a 10,000 vert model may be able to pass through the collision detection code only having had to check about 100 verts.  That equals out to a massive time savings.  Combining that with scene management and using index buffers you end up with a haul-ass collision detection check.

And that is also where this gets on topic.  That octree setup will need to be done when a model is loaded, further increasing mission load times.  But most people seem to overlook model loading as a part of the code which could offer some of the most benefit from being multi-threaded.  It is largely contained so it should be one of the easiest parts of the code to convert (not that it would actually be "easy" though), bitmap loading is postponed until later on so OpenGL context issues should never be a problem, and it can take up over 90% of the load time if IBX files need to be generated (about 40% otherwise).  That way you get to load a model in the background and still have a responsive UI in the foreground.  It offers a speed advantage for multi-core users and better user experience for single core users.  In other words: win-win.

In retrospect, it might have been a good idea to suggest people used detail boxes more heavily and do away with the standard LOD system. I know that's impossible, it's just conjecture, but that way you could have divided out just the 'hull' of the ship for ship collision detection, and ignored the details.

I'm not sure that the collision detection code even knows anything about detail boxes actually.  Even if it did it doesn't change the fact that it gets walked during collision setup anyway.  It would offer some benefit, but in general not really enough to make any difference.

[CaptJosh]

As for using a separate collision mesh, that's an old school idea going back to collision masks on 2D sprites. I'm all to familiar with masks on sprites, actually. I've just recently been working with some for an older game.

[Stormkeeper]

While I find the pro-contra discussion over multi/single core programming interesting, it has little to do with SCP development.

IIRC the most resource intensive part of the code right now is collision detection. That bears some thought, since our models have become a lot more complex and therefore the said code has to deal with even more data.

It's like a muscle car that just recieved a brand spanking new motor (HTL and now shader support) with great transmission system (the various media supports from TGA through DDS to EFF) with an old muffler (collision detection, the pof format) full of grease and debris...and now we're forcing the said muffler to handle the exhaust from a supercharged monster.

Talking about multi-threading the code is like wondering whether we should install turbo.

An effective metaphor.

TBH, changing any part of a program built on a single core to something for multi cores will never be easy. And the point is, even if you do change the model loading code to take advantage of the extra core, how much faster will the missions load? Will the decrease in loading time justify the work needed to change the code?

[chief1983]

Maybe it wouldn't be as noticeable on a dual core, but what about quad and dual quad cores?  Core counts only seem to be increasing at this point.

[WMCoolmon]

Yes, it would be advantageous for Freespace 2 to take advantage of dual cores, or more cores, and be fully multithreaded. Nothing is going to change in that regard unless somebody who has the knowledge to do it starts doing something about it. It's a massive project and in the end you might find that it would be better to build a new engine from scratch that has some compatibility with the old engine data.

Nobody is going to deny that the number of cores on a chip are increasing or that spreading it out couldn't result in performance enhancements, if not now, then somewhere down the road, but it's not a bottleneck right now, and devoting the resources to it would be taking them away from other projects and other enhancements that do have an impact now, and do effect campaign releases now, and will have to be done anyway in order for them to be used, even if multithreading is implemented.

[chief1983]

I was only referring to mission loading, I'm well aware the overall engine update is inconceivable at this point.  SK said how much would it matter for mission loading to take advantage 'an extra core'.  I was merely stating that with 8 cores, the mission load time would drop considerably and allow the room for the enhancements Taylor mentioned to be less noticeable.