Pages: [1]
  Print  
Author Topic: Multiple Theads, are they a possibillity?  (Read 1292 times)
Offline (Unknown gender) MrGriggs
Posted on: January 27, 2011, 09:12:38 AM

Member
Joined: Dec 2010
Posts: 128

View Profile Email
I don't know if there's any point discussing this, if it's even considered.

I know not of the validity in my statement but I propose that it would give advantage to ENIGMA if it used a single thread for each process, such as the Draw process being on a seperate thread, the sound process, and step process.

Collision process maybe? I know there's many things that could be assigned to different threads, but i'd like it as follows.

Step

Draw

Sound

Collisions
Logged
Offline (Unknown gender) luiscubal
Reply #1 Posted on: January 27, 2011, 09:46:17 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
I believe sound(OpenAL) is already in a separated thread.

Multithreading would break compatibility with GM, although some kind of limited multithreading support might be possible in the physics subsystem(hspeed, vspeed, gravity, friction and collisions).

Multithreading the draw event might be problematic, even if no sane person would make the Draw event change variables like position, etc.
Logged
Offline (Unknown gender) MrGriggs
Reply #2 Posted on: January 27, 2011, 10:22:36 AM

Member
Joined: Dec 2010
Posts: 128

View Profile Email
It wouldn't break compatabillity as multi threading is not addressed until the information is parsed to ENIGMA, the .Gmk or whatever, would remain the same, the user has no access to defining threads, just an .exe compiled with ENIGMA uses pre-defined threads as determined in the engine.
Logged
Offline (Unknown gender) luiscubal
Reply #3 Posted on: January 27, 2011, 12:31:51 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
Let me put it this way.
Say 2 instances access each other x and y.

var tmp = other_inst.x;
other_inst.x = self.x;
self.x = tmp;

In GM, this means the two x are swapped. Since the code is executed twice(2 instances), this code effectively does nothing in GM.
Now, consider a perfect parallel synchronized execution.
inst1.x = 5;
inst2.x = 10;
Now, each instance reads the x of the other to its own local tmp variable.
Now, each instance changes the position of the other. Right now, we have inst1.x = 10; inst2.x = 5;
Now, they are going to set their own x from the tmp variable. So we now have inst1.x = 10; inst2.x = 5; again.

So the end results are different. Therefore, compatibility with GM is broken.
Logged
Offline (Female) IsmAvatar
Reply #4 Posted on: January 27, 2011, 12:58:18 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 891

View Profile Email
Not to mention, different behaviors each run if they aren't in perfect parallel sync.
Logged
Offline (Male) Rusky
Reply #5 Posted on: January 27, 2011, 02:50:29 PM

Resident Troll
Joined: Feb 2008
Posts: 960
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
GM compatibility (and programmer sanity) requires serialized instances rather than parallelizing them, but it would be possible to put some things in separate threads. Sound, networking, etc. could have utility threads to let game logic use it when it's ready. Drawing could be separated but it would be complicated and its usefulness would be debatable.

GPU-style parallelization could probably work with some things as well, but then again hardware accelerated graphics are the biggest candidate for that and are already implemented. CUDA/OpenCL/DirectCompute would be cool for particle systems, but those are rather out of the way and people can use them directly through C++.
Logged
Offline (Male) Josh @ Dreamland
Reply #6 Posted on: January 28, 2011, 12:48:07 AM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2946

View Profile Email
What I was thinking about doing is adding threading by the same mechanism that I can add instance deactivation. Basically, I would keep a new tree and shit for each thread (deactivated instances get placed in thread -1, which is never processed).

Threading an object would be as simple as saying instance_thread(inst,thread).
Users would be allowed to figure out for themselves that sometimes life isn't as easy as putting everything in its own thread and hoping depth and shit stay in order.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) MrGriggs
Reply #7 Posted on: January 28, 2011, 05:05:32 AM

Member
Joined: Dec 2010
Posts: 128

View Profile Email
I understand how a thread functions, and the inconsistencies it may cause when used with particular methods.

But if things such as sound/particles and the like where to be put into seperate threads it wouldn't matter if there was a slight deviation from the norm.
Logged
Pages: [1]
  Print