Youre right inestical (I said it before )
But I think its kind of stupid cause the cores arent in full use...

I can remember jcl speaking about threads while illustrating something.
If I'm right there is 3 threads.. or then not. Physics and entities were in their own thread indeed.

i thought a6 was a single threaded engine. try it yourself, open up the task manager and watch the thread count when running the engine.

Physics used an own thread in early A6 versions, but the latest versions (since 6.31) use the same thread as the engine. Videos still use an own thread, though.

Just out of interest - why doesn't the physics engine use its own thread anymore?

Because the physics engine is controlled by the script engine in real time. It would be awkward to send all control messages to a different thread.

Is multithreading being limited by Lite-C/C-script then? I don't know much about how one would pull of it, but it seems as though it's going to eventually be necessary.

I was thinking..

How about letting the user create the threads (of course, the 'hard parts' like variable/function locking and handling done by engine) so user could create his/her own system for making multithreaded games?

Sounds and is tricky and hard.. but suggestion in the end ^^

I dont think that the engine should do the functions in one thread...
If each thread has his own Temp and one thread does the AI another the movement and the next one animation....
This should work too, wouldn't it?

The short answer is, ideally, that your code will remain the same, and all the hard work is done by Conitec.

The most common solution to multi-threaded games is to split things up into large groups (sounds, physics, graphics, AI) and put each of those in their own thread.

Using this method, all of your C-script functions would run on a single thread (AI). They will run just like they do now but, instead of getting 5-10% of the CPU time each frame they can have 100%.