Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: colecampbell666 on May 30, 2008, 06:48:42 pm
-
Are there any plans to make FSO support multiple cores? More and more people are getting dual-cores, and I've seen three support requests today that have symptoms of dual-core-ism.
-
having 4 cores, this subject interests me.
*strokes goatee*
-
As far as I know, Freespace runs as a single process, and so can only ever fully utilize one core. In Task Manager, though, you can change process affinities so that, say, Outlook and Firefox always run on Core 2 and Freespace always runs on Core 1.
-
It would probably require the entire engine to be rewritten from scratch to multi-thread everything.
All I know, is that the joystick is polled using a separate thread. All of the AI logic, graphics, physics, sound, loading, etc. is done in the same thread.
-
Never had a problem one either my Pentium D, Core2duo or Core2quad. I leave it on all cores and not a single problem related to that yet. Could this be more of a chipset or motherboard thing than a multiple processor problem? Strange that some people can run it just fine and others can't.
-
There are two issues here. Having FS2_Open work on machines with multiple cores without bugs and having it actually make use of the other cores.
The former is supposedly fixed in 3.6.10 builds. Were any of the problems reported on/fixed by using recent 3.6.10 builds?
The latter basically requires a complete engine redesign as the game continually makes the assumption that only one process can be modifying data at a time.
-
Multi threading will require the total rebuild of the game engine, because at the time of its publishing, dual cores were near non-existent on the consumer side, and making programs use multithreads was an issue previously. To the best of my knowledge, few games support multi threading. Supreme Commander, for example, will split its load between the cores evenly, and without need for configuration.
-
Multi threading will require the total rebuild of the game engine, because at the time of its publishing, dual cores were near non-existent on the consumer side, and making programs use multithreads was an issue previously. To the best of my knowledge, few games support multi threading. Supreme Commander, for example, will split its load between the cores evenly, and without need for configuration.
They were nonexistent period, in 1999, unless you're talking about NASA or Area 51 or some Chinese teenager or something.
And that's what I thought, I wanted a coder's point of view.
-
If it were to magically become multithreaded, it would just open up the way to painful concurrency issues when changing anything.
-
Wasn't the Pentium Pro multi core or was it just a precursor to the multi core processor?
-
I know that Pentium, I think, is coming up with the Penryn processor, some kind of smart multi core that will moniter usage of the cores and turn off inactive ones.
-
The Pentium Pro had SMP support, but it was not dual core. It was also their first pure 32bit (and i686, the Pentium/MMX was i586) cpu I believe, designed for the NT operating system. SMP is much older than dual core, and there were SMP systems in consumer hands around that time, because the Celeron was found to be capable of being run in SMP configurations, with a little motherboard hackery. The Abit BP6 was famous because of this, it enabled power gamers to buy two Celerons for less than one Pentium 3 and get better performance. So, while dual core was barely a dream to a few scientists, SMP was definitely around, and being taken into consideration by many programmers. But it's difficult to take advantage of all those cores, threading an application properly takes a lot of work, and needs to be planned from the start more than likely.
-
I can't think of any way you would do it gracefully; I'm skeptical if even scripting is abstracted enough for you to be able to do anything else while something is going.
The fact that nobody knows what it would take seems like the biggest obstacle to me.
It is something that seems like it's going to become something quite a bit more relevant in the coming years, so if anybody knows someone who loves multithreading already-coded applications... :D
-
If I managed to find a decompiler and decompile Forged Alliance's code, we might be able to see something.
-
You giving up and crying after looking at the FS2 code? :p
The problem isn't that the team don't know how to write multithreaded code. It's that we don't want to. We'd have to rewrite the entire engine from scratch.
-
If I managed to find a decompiler and decompile Forged Alliance's code, we might be able to see something.
mov edx,len
mov ecx,msg
mov ebx,1
mov eax,4
int 0x80
mov ebx,0
mov eax,1
int 0x80
-
I know you need an understanding of how every piece of the code interacts with every other piece, whether that be an individual or collectively. Collectively makes it even more difficult, and that's the more likely scenario here since it wasn't designed with a multi-threaded infrastructure in the first place. Every piece would have to be analyzed and re-fractored into a thread-aware, thread-safe version. At a minimum. It could be that it's simply not possible without rewriting from the ground up. Right now, every frame gets taken care of linearly. You do some physics, some graphics, some scripting checks, and each of these happens in a pre-defined order. They all have been coded with this assumption. You take that assumption away, and all hell will break loose. When you have graphics and physics and scripting all trying to do their own thing independently, and report back to some master process, it would probably be ugly right now. And that's just one method of how to break it up. The very howto of multithreading a game is still up for debate. What gets its own thread? With a game like this it's especially difficult. Is it even worth multi-threading? Is there enough overhead on all fronts to warrant it, or is it mostly graphics these days? The other areas, physics, AI, etc, are old, and probably eat up an insignificant amount of a modern cpu.
-
Collision detection is eating up a massive amount according to Taylor's profiling a while back.
-
Actually, what I meant when i said about looking about Forged Alliance's code was how to make multi threading work, but yea, it would be impossible to do it without rewriting the engine.
Collision detection is eating up a massive amount according to Taylor's profiling a while back.
How much exactly ? I know that I lag a bit when I ram into enemy ships.
-
FYI, I have a dual core (an Intel and an AMD) and I have never had any issues with running FSO with both cores.
I also just built an AMD Quad Core for a friend of mine who's running XP 64bit with 8gb of ram, and that machine is also running FSO just fine. We've even had plenty of lan multi-player games.
-
Wait what? The problem isn't any sort of incompatibility, it's about taking advantage of them. By it's nature it's probably only utilizing one core for just about everything it does while running, leaving the other one sitting idle. It's a single threaded app, the thread attaches to one core and stays there. So it's not that anything is broken, it's that it could allow the game to make better use of the now-commonly available resources.
-
Yea, it'll run fine on multicores, but it doesn't do multi threading, which is using different cores for different processes, for example, using one core to handle collision detection and another to render. This way, it reduces stress on your primary core, and allows programs to run smother. However, few programs have multi-threading.
-
Yeah, basically all that it would make sense for is an app that is going to utilize every bit of cpu it can get for a long time. So things like render farms, games, physics sims, etc. Not your typical day to day computer stuff. The only use they get is that the OS should be affiliating different programs with different cores, keeping the load balanced whenever you're doing a lot of things at once.
-
Or games with 25km X 25km maps with hundreds of units crawling around it trying to lay the smack down on the only two piloted walkers in the whole game.
-
Mutexes involving atomic X86 instructions are ridiculously slow! Spin-locks are faster, but still too slow! (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf) Clearly the only answer is to split this engine into a half-dozen threads, and let God sort out the race conditions!
In all seriousness, I would be extremely surprised to find FS2 CPU-limited on anything but the fastest graphics cards. Srsly. If you want your multi-core CPU to give you more warmth while you play, encode videos at the same time or something.
-
I could see dividing the playing field up into zones where ships don't really act with each other and doing those threads simultaneously.
But then you would have the problem of ships crossing over zones, or AI responding to events in other zones (Which wouldn't be so bad, since AI doesn't have to respond instantaneously and it could be globally managed every five frames or so), or scripting/SEXPs that reference events in zones. The problem is that your ship handles could become invalidated in the middle of a SEXP or script, so even if you checked for it starting out (even in the code) there's no telling that the pointer will be good later without rewriting _everything_ to go through some sort of sync system conducted at the end of each frame.
Or something. Just pontificating for the hell of it here. :)
-
FYI, I have a dual core (an Intel and an AMD) and I have never had any issues with running FSO with both cores.
I also just built an AMD Quad Core for a friend of mine who's running XP 64bit with 8gb of ram, and that machine is also running FSO just fine. We've even had plenty of lan multi-player games.
Dude... That isnt what we are talking about.
FSOpen only uses ONE core at a time. Some games like Supreme Commander, Oblivion (To an extent), WoW, and others can use both cores. For example, load half the game using one core and load the other half using the other core.
Makes the game a LOT more efficient, but a pain in the ass to recode the entire game. Hell, it's a pain in the ass to code the game from scratch to use multi-threading.
-
The Pentium Pro had SMP support, but it was not dual core. It was also their first pure 32bit (and i686, the Pentium/MMX was i586) cpu I believe, designed for the NT operating system. SMP is much older than dual core, and there were SMP systems in consumer hands around that time, because the Celeron was found to be capable of being run in SMP configurations, with a little motherboard hackery. The Abit BP6 was famous because of this, it enabled power gamers to buy two Celerons for less than one Pentium 3 and get better performance. So, while dual core was barely a dream to a few scientists, SMP was definitely around, and being taken into consideration by many programmers. But it's difficult to take advantage of all those cores, threading an application properly takes a lot of work, and needs to be planned from the start more than likely.
[off topic]
I was going by a Novell support article. The Pentium D uses the same multi processing system as the Pentium Pro did so Netware 6 will run on it but will not run on a Core2. Never ran windows on a Pentium Pro. [/off topic]
Still none of this really answers the question of why some people have trouble running on a system with multiple cores until they manually set affinity to one core and others don't.
-
Ah I'd forgotten about that issue. Yeah I don't have a clue there.
-
I know for AMD procs there is a multi-core optimizer that essentially load-balances the activities that would normally max out 1 core to split across 2, 3 or 4. While I get the logistics of the benefits to multi-threading FSO, care has to be given to the fact of scalability. Some single-cores can multi-thread but not as well as multi-cores, and if the two are not conditioned properly, you will loose out on any one that hasn't yet obtained the hardware. There still has to be "Retail" compatibility for FSPort for those who cannot run FSO with or without HT&L capabilities, are we to cast them out? And just because something is present to take advantage of, doesn't necessarily mean that it is the best idea to do so. If the issue is not with compatability, then it obviously is not broken, and there are a lot more features than just this coming down the line. At some point, they will inevitably merge.
While it does frustrate me to no end the amount of concessions against progress for sake of compatibility, it has to be even more frustrating to the coders. They want to create and share, and no one should be left behind. That makes for hard decisions and often recriminations when it doesn't go well. So tot that end, I trust the coders to do what they will do, because I know they will do it to the best that they can with an eye towards seeing that as many people as possible can share in it.
-
The issue isn't compatibility. The issue (as we've told you several times) is that you have to re-write the entire engine for it to work. Let me give an example of an everyday event run as a single thread and then as a multi-threaded one.
Suppose you want to go to the shops and buy a pint of milk. You walk to the shop. You see the shop is open. The shopkeeper is a little annoyed cause he was about to close. You walk in the shop. You see if there is any milk. There's one carton left. You pick up the milk just before someone else does. They look a little annoyed when they see there is no milk. You pay for the milk. You walk home. Simple. Now let's try multi-threaded.
First you walk to the shop. You go to walk in the shop. You check if the shop is open. It is. Meanwhile in another thread the shopkeeper checks if there is anyone in the store. There is no one in the store. The shopkeeper starts closing the store. You walk in. In the first thread you are now in the store. The shopkeeper at the same time is closing the store. You look for milk. While you entered the store another person also turned up running in a different thread. They also want milk. Both of you check if there is milk. Both of you see one carton of milk left. You both pick it up. You get there first. You laugh as the guy walks past you, calls the shopkeeper over and tries to pay for a carton of milk he doesn't have. You stop laughing when the storekeeper throws a fit as can't get the scanner to read the non-existent bar code and refuses to serve you until he's dealt with the other customer. So you all stand in the shop with the lights off and the doors closed forever.
There are ways to prevent what happened in that example from happening of course. You say that certain tasks can only be performed by one person at a time. But the point is that FS2 doesn't do those checks at the moment. Since only one thread ran at a time checking if the store was open was enough. The shopkeeper wouldn't be checking if it was time to close at the same time, the game would handle you seeing the shop is open, walking into the shop and then have the shopkeeper do his check.
But FS2 doesn't do those checks. It never needed to do them. And the number and complexity required to do them all means that we might as well re-make the entire game. As you can also probably see if we forget a single check there is a chance of locking up the game under certain conditions. That might happen often or only on very rare (and therefore hard to fix) occasions. Furthermore as you may have realised doing all the extra checking takes time. Multi-threading isn't always automatically good. All the checking can take so long that the resulting program is actually slower than the single-threaded task.
It is possible that there may be tasks in the game sufficiently distanced from everything else that we can shunt them into another thread. But the majority of the engine can't be.
-
normally your computer uses the 2 core (or 4) when launching FSO. and it uses the 2 cores ,but not the same way as multi threaded program do (see post above for why).
the truth is, put your game at maximum details, run it normally you'll have a certain amount of FPS (let's say 50), then use the task manager to set affinity to one core only, in most of the cases you'll see your FPS dropping (almost divided by 2, 30-40 for me). So, unless core affinity does slow the game, I guess the OS manage the 2 core to use them adequately with single core application. That means, no need to develop a multi core support for FSO since it wouldn't benefit the game at all.
many old games runs with the same system (that's why I guess it's OS related, or even hardware related)
-
Remember FreeSpace2 worked fine with a Pentium 200. I don't know much about the inner workings of FS:SCP, but my guess is the CPU-dependent part (AI, physics, scripts) mustn't have grown much from the original code in terms of processing requirements. Even if it grew by a x2 factor, which would be a lot, most single cores being at least 1Ghz, we'd still be in the clear by far.
Correct me if I'm wrong but it really seems multithreading would serve no purpose at this point.
-
when I look rom average distance 3-4 capital HTL ships I have 20-30 FPS while when I'm looking at nothing I have 60FPS,
if my computer was that powerfull for this game, wouldn't there be no loss of FPS ?
(maybe I'm wrong, I'm not omnipotent)
-
Most of that depends on your Graphics card. Go buy the latest graphics card and try that again... ;7
-
with a geforce 8600GS I have more power than with the graphics cards I had when freespace 2 was released.....
-
most single cores being at least 2.5 Ghz
Fixed. And single cores aren't produced anymore.
with a geforce 8600GS I have more power than with the graphics cards I had when freespace 2 was released.....
Not to be rude, but no ****. That is a monster compared to a TNT2 (my first). (look at this (http://www.tomshardware.com/reviews/graphics-cards,1942-7.html) chart)
-
Fixed. And single cores aren't produced anymore.
Weren't some dual-core low freq Celeron produced?
[googling] Yep. http://en.wikipedia.org/wiki/Intel_Celeron#Celeron_Dual-Core_.28Core.29 (http://en.wikipedia.org/wiki/Intel_Celeron#Celeron_Dual-Core_.28Core.29)
Anyway, 1.6Ghz sounds enough.
-
Those are dual cores. Single-cores now (or a short while ago) were all more that 2 Ghz. A lot of older duals (especially for laptops) are less that 2, or even less than 1.
-
Ok. I think we agree on the resulting point that every multicore CPU ever released can run FS:SCP just fine, even with only one active core, hence the lack of need for multithreading.
Edit: btw what dual-core cpus are <1Ghz? I can't seem to remember of seeing one.
-
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.
-
1.5 Ghz P4, 9550 Radeon 256 MB, 2 GB RAM.
-
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.
-
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.
-
*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)...
-
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.
-
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.
-
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.
-
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..
-
It needs a code change. The models are getting higher poly about as fast as average horsepower increases.
-
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?
-
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.
-
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?
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
Still, that probably is too much hassle for the expected gain. Loading times aren't that bad currently. At least, that's my opinion.
-
Loading times aren't that bad currently
Right, again, that's why I mentioned Taylor's suggested changes to the mission loading code, which _would_ probably increase mission load times significantly.
-
is it possible to lod detail boxed subobjects? personally, i would like per subobject lod-ing (with their own set of lod distance settings). i like the collision model idea. that way turret lods can be adjusted independantly of the main ship. would do wonders for the dante.
as for cores, how well is the rendering code isolated? possible to make that use a different thread?
-
So how does multi-threading work? I assume that it sends every instruction to a different core. (e.g in1c1 in2c2 in3c1)
-
Think of a thread as a separate program coexisting within the same memory space as 1) the main process and 2) any other threads
So the instructions from one thread are actually (ignoring the operating system moving threads around cores) all being run on the one core, while instructions in another thread might all be run on another core, or time sliced by the operating system on the same core. You can even have multithreaded applications on a single core, although they may actually suffer a slight performance decrease thanks to the CPU cache being invalidated regularly
Because they're in the same space, you've gotta be careful with reading and writing memory, because you can overwrite other threads data, and there might be no way of telling whether that is the case. (The example given by (taylor?) above using the milkshop analogy is really good for seeing how this works)
This is the reason why any multithreaded application needs to be designed from the ground up to have threads, and you've gotta be awake when you're implementing them (there are some veryvery easy to make mistakes which will cause all sorts of havok)
-
OK. Thanks.
-
Ah, the joys of things breaking due to some unrelated code in another thread.
I believe the splitting of instructions to multiple processors was sort of done with the Itanium, with pipelines rather than cores.
-
Still, that probably is too much hassle for the expected gain. Loading times aren't that bad currently. At least, that's my opinion.
Making it load faster wouldn't be the point. The point is that during model load the game can't do anything else, it just freezes. Making it multi-threaded means that the UI would remain responsive during load and we would better be able to communicate to the user what is going on.
Remember that multi-threading isn't actually about making something faster, it's about delegating tasks so that you can do more than one thing at once.
-
Thereby taking multitasking to its next logical extension.
-
It is technically impossible to start adding "multithreading" to the Freespace 2 core, the way the code is written and also how the data is read your asking for a lot of trouble into getting it functional. There is a reason why so many companies just make new game engines from the ground up that use multithreading. The way the Freespace2 engine is written is by using a single core. Your beter of to rewrite the entire game engine from scratch then to try and figure out what is going on splitting up the functionalitity adn then making sure your not causing deadlocks because physics is waiting for the rendering to give back the information about the current models in the rendering pipe etc..
-
Yeah, we figured that one out further back.
:welcome:
And why do you have that huge space below your post?
-
Oh, another new member coming straight from Game Warden. Welcome! :D
-
Yeah, we figured that one out further back.
:welcome:
And why do you have that huge space below your post?
and why do you ask stupid questions?
-
Why`s it so stupid? That big space could contain all sorts of mysteries...
-
It is technically impossible to start adding "multithreading" to the Freespace 2 core, the way the code is written and also how the data is read your asking for a lot of trouble into getting it functional. There is a reason why so many companies just make new game engines from the ground up that use multithreading. The way the Freespace2 engine is written is by using a single core. Your beter of to rewrite the entire game engine from scratch then to try and figure out what is going on splitting up the functionalitity adn then making sure your not causing deadlocks because physics is waiting for the rendering to give back the information about the current models in the rendering pipe etc..
Rewriting the game from scratch is not a feasible option to add multicore threading to FS2Open. It is a feasible option to write a newer, more modern game engine that would not be directly backwards compatible with FS2Open. There are just too many hacks and hardcoded ways of doing things in the FS2Open for it to ever be 100% backwards compatible. Too many missions that expect minor bugs and flaws to be present for them to even be beatable.
However that feasible option thing is only if there are coders to actually implement it.