Do the Construct's games have the multi-core support?

This is the question...

What would they use it for?

perhaps the cores could be used for multithreaded loop processing

It works in parallel with the GPU, which is more important - in effect, the rendering is threaded on the graphics card, which is a big timesaver.

As for CPU cores, it's actually fairly difficult to utilise them because most of the runtime is sequentially executed. However, some candidates for possible multicoring is the Physics behavior, the RTS movement pathfinding, and maybe some other processing heavy plugins, but that's the best that can be managed I think.

I guess those two behaviors could utilise it, something to consider in the future.

could you do it on (non-ordered) for each object loops?

Hm... possibly... but it'd only affect very large loops, and it'd have to absolutely, certainly, without fail not access any shared memory or resources, otherwise it wouldn't work. I'm not sure the event engine could work with that.

4 people making the job are faster than 1 person making the same job.

Also, 4 cores can process 4 AIs or 4 physics bodies, or something else at the same time.

You can apply multi-threading in all kind of computations.

I repeat, 4 people makes a job faster than 1 person, so you can use threading to make more computations at the same time, so 4 times faster!

And this is important for complex games. Games that may use difficult and long IK computations, or massive physics or movement in general.

Also we are now on multicore era, and this would be an important feature.

p.s.: also you can check 4 events at a time instead of just 1.. Something like a block of events

also you can check 4 events at a time instead of just 1.. Something like a block of events

It's nowhere near that simple - multithreaded programming is a pretty complex area. If one of the events in any way depends on a result from a previous event, or in any way writes to or reads from any part of the computer's memory that is also accessed by one of the other events being executed, it will not work (due to out of order execution). Since events are defined as always being run from top to bottom, it's pretty difficult to thread that, since I reckon almost all events will depend on the events before them being completed.

[quote:2u0oyio1]I repeat, 4 people makes a job faster than 1 person, so you can use threading to make more computations at the same time, so 4 times faster!

Not if there's only one cookie cutter.

multithreaded programming is a pretty complex area.

Hear, hear!

I'd like first to see a game designed in a way that would benefit from multithreaded logic.

Then worry about if this or that engine supports it.

rendering is another issue and Construct does that quite well.

> also you can check 4 events at a time instead of just 1.. Something like a block of events

>

It's nowhere near that simple - multithreaded programming is a pretty complex area. If one of the events in any way depends on a result from a previous event, or in any way writes to or reads from any part of the computer's memory that is also accessed by one of the other events being executed, it will not work (due to out of order execution). Since events are defined as always being run from top to bottom, it's pretty difficult to thread that, since I reckon almost all events will depend on the events before them being completed.

I was actually thinking about this a while ago, and thought about something like possibly having separate "core event sheets", so to say, which would be run in parallel and if there are not enough cores for the various "core sheets" the user could define the order in which they are executed.

With separate event sheets the fact that you can't rely on events in the other core sheets would be clear for the end users and I think it would make multi-threaded event running pretty understandable for pretty much anyone too. From what I've understood from multi-core programming, you'd have to wait for all the core sheets to be executed before going through them again, but even if you'll have to wait for the slowest core sheet to be processed it'd still be faster if other parts of the code have been gone through already.

Then the users could just code some independent parts of their code in these "core sheets" - like AI processing in one core sheet, etc. I can't really say how useful it would be in the end, but I think it would have potential.

Even so, you wouldn't be able to refer to the same object in two threaded event sheets, the plugins would have to be specially written as to not use single threaded data, and even then the performance gain is nothing unless the threaded events are a significant time consumer.

i realize there are people who create things that slow down construct exe's, myself included, but for the most part, if your games have cpu induced slowdown, it's inefficient events. think about games that use multicores. crysis and dirt come to mind. if someone's pc can't handle the physics in a construct game, their cpu is probably to old to be multicore. if its something other than physics slowing a computer down in a construct game, optimize the events. it would be cool just to say "supports multicore processors", but i think the time it'd take to learn and implement a multicore event system would be wasted, especially since as i said before, if your cpu supports multicore, it will have no problem with a construct game. i have a fairly old dualcore athlon x2 4200+, and i can fill a large portion of the screen with 64x64 physics objects before i get slowdown. its just not really needed.

Multicore events would be PURE HELL.

Believe me, it would stop being easy.

I can agree with multicore physics calculations and stuff like that, but don't ever think of doing multicore event sheets.

Just google "race condition".