Multiple CPU cores in the future?

It is based off Supreme Commander's engine and as such should have native quad core support.  I'll take a peek to see if I notice this too.

No actually, this is a big problem.

It seems demigod does support "multiple cores" but its just like we are researching my parellel programming class, people don't know how to properly make a game multithreaded, they just bs some things and hope for the best.  You can see here, the load balance is totally off, 1 core shouldn't be stressed out while the other core is doing hardly anything.

Check it out:

http://img73.imageshack.us/my.php?image=dedon4.jpg

It won't let me upload images, so look at that link, you can see the load balance of processor 1 and 2.

So for the devlopers, is there a logical explanation for this load balance while playing the game and why its not properly distrbuted on each core?

Beta. Test. Version. One.

multi-threading if done improperly can actually make the game slower. dual cores and quadcores are for running more than 1 task at the same time, I think they are aimed at commercial/business pc's rather than gaming.

Plus as someone said, this is a beta. They are probably waiting until the get to the optimisation phase before adding multicore support.

Herewego. Got me a quick imageshack account.

http://img49.imageshack.us/my.php?image=taskmanagerdemigodbeta1nd1.jpg

As can be seen, basically zero activity on cores 1 thru 3 (I had some other programs running in the background). Again, I'm well aware this is beta, but it's the almost complete absence of activity on the other three cores that got my attention. Even SupCom's engine doesn't get anywhere near even-balance, but the attempt is certainly visible. This game right now... not yet.

If it's simply being bypassed, that's completely understandable. Consider this thread simply a heads-up for the sake of playability on lower-end systems.

Well I'm not a professional game devloper, but usually you don't change the engine that much, what you see is what you get.  If its not supporting threading now, its not just changing some code, and saying oh hai, its fixed!  multithreaded!

uhm typically the other core does seperate tasks.

The first will do gameplay and stuff, while the second like physics and yada yada.

I don't think it's easy to split up the gameplay between the cores and have it be even.

I've never seen a game that even.

And you can't just "spill over" onto the other core when one is over loaded.

I'm not expert, though.

no it shouldn't be exactly even, I wasn't saying that but having 1 core almost 100% and the other core 3% is not right.

The reaosn my other cores were even that high is probably because I was running a ton of stuff in the background, so it would have even been lower, almost 0% on the 2nd core if i had no background applications running.

Tomarrow I'll run the game again with no backround applications running like AIM/VENT/FireFox/Steam and again look at the load balance of the 2 cores while playing the game.

I currently have no background programs running and I get 90-97% on core 1 and 20-37% on core 2.  They definately have multicore support.  Not sure what else you want.  It will never be perfectly balanced or "spill over".  The program is clearly multithreaded and allowing the program to throw physics and what not to core 2 and maintain good frame rates.  This is the state of mulitcore gaming today, like it or not.  In a few years programs may be better optimized for multicore systems, but not today.

The render thread and simulation thread are the two most demanding threads and thus make up Core 1 and Core 2. You aren't going to split them up any further. Render thread will always fill up Core 1 while the other threads will use as much as necessary.

We've been over this multiple times in the GPG forums, so can we please, please not start this again?

It's entirely possible that the old SupCom optimization tools will work for Demigod to speed it up tremendously with minimal adjustments.

It's also possible (read likely) that they'll balance the threads better once they have an idea how intensive they'll be.

See supcom could put all the physics calculations with projecitles and such on the other core  There was a lot of load there.

What that is 25%-50% of the load could they have the other core be doing?..

Are particle effects done on the cpu, even?

like I said, AFAIK, there is only certain ways you can split things.  Commonly they put physics and AI on one.

And considering the low number of projectiles (especially seeing that arrows don't seem to be physics based) and the fact that for all but five characters in the game, the AI routine is a series of about seven waypoints with a list of stuff to kill if it sees it on the way, neither is a particular toaster roaster.

Its easy to see how this game will get busy though, especially on larger maps. More power, more power!...

That's what I would have figured too. But despite that, this game is still managing to load up one of my 4 Ghz cores to nearly 100%. Right now, there's probably some extra overhead due to debug code, and future optimizations are almost possible. But it's not unreasonable to expect larger and more complex maps in the future, so we'll have to see how things turn out.

It doesn't matter how fast your core is because the render thread will do it as fast as possible to provide the best FPS. The main problem will be the sim speed, but I haven't seen anyone drop below 4+ yet so I think we'll weather it through. I can forsee that it will be a major pain when someone with a slow computer joins a large game, since that was pretty damn common in SupCom.

I think this is the case, because I have a quick CPU (2.66 GHz C2D, pretty good for a laptop I don't want running hot) and if it really needs the 100% CPU I'm giving it, then all the people with P4s wouldn't even be able to think about playing.

just checked mine after playing a 30 minute game, my first core was about 30%, second was about 60%, 3rd and 4th were at about 20%