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

New releases and general discussions.

Post » Tue Jun 09, 2009 7:29 pm

[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![/quote:2u0oyio1]

Not if there's only one cookie cutter.
Image Image
B
161
S
48
G
90
Posts: 7,347
Reputation: 66,749

Post » Thu Jun 11, 2009 11:12 pm

[quote="Ashley":3h1di6sr]multithreaded programming is a pretty complex area.[/quote:3h1di6sr]
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.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Wed Jun 24, 2009 4:36 pm

[quote="Ashley":2vicbnt8][quote="Genesys":2vicbnt8]also you can check 4 events at a time instead of just 1.. Something like a block of events[/quote:2vicbnt8]
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:2vicbnt8]

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.
B
16
S
8
G
4
Posts: 136
Reputation: 3,144

Post » Wed Jun 24, 2009 4:48 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,948
Reputation: 178,532

Post » Wed Jun 24, 2009 5:16 pm

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.
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Mon Jun 29, 2009 11:23 pm

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".
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Fri Jul 03, 2009 1:42 am

[quote="Ashley":1j22yzxw]some candidates for possible multicoring is the Physics behavior, the RTS movement pathfinding[/quote:1j22yzxw]

Plugins can be multicore with no issues, right? given it's C++
There's OpenMP and soon OpenCL to use...
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Previous

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests