Friday talks: Game engine written on functional language. Possible?

Hello!



While reading some articles about functional language, I came across a line where it was stated that a true power of a program written on functional language is that you do not have to think how to write a program so that it became multithreaded and uses all available cores - it is done automatically.



This is very neat for game engines, because there are a lot of things you want to run in parallel, right? But, of course, if you want this to work, you would have to write the whole engine and the rest of the code… how to say… functional way.



I just started research it, and there are a lot of questions unanswered for me right now, and my post here is rather to listen to your opinion whether it is possible or not to develop a game engine using functional programming (functional language). As for me, I am kind of thinking pessimistically right now… or it is because I got used to think object-oriented way :slight_smile:

Use entity system and asynchronous threading, works just as well. E.g. one loop puts in a component, another one checks for that component, totally thread safe and “automatically” multithreaded.

Actually its partly crap,



opengl can only work singlethreaded since its statebased, similar probably for directx.

So you will always have a main rendering loop that cannot split up in multiple threads!



Now the enqueue system jme uses is kinda similar to the message passing in functional languages.



(you should not forgett java is one of the best languages(that count as major languages) out there in terms of multithreading, since we only have to worry about high level stuff )

@EmpirePhoenix said:
opengl can only work singlethreaded since its statebased, similar probably for directx.
So you will always have a main rendering loop that cannot split up in multiple threads!

This is not really true. In OpenGL everything is paralleled and in the jME update loop there are also multiple threads working. One update loop != one thread really. But you are right in a way because the programming model works exactly as if they were one thread. And also yes, this solution and the ones we use and suggest are pretty much the standard way to deal with threading nowadays.

I mean more the rendering itself (i know the physic for example can run in a own parralel thread), You cannot multithread that , (like rendering two meshes sametime) since opengl internal uses states for rotationmatrices ect. and does not have a statestack per thread, but per opengl renderingsystem.

so as long as you only have one output stcreen, the rendering breaks always down to one thread somewhere.



For those of you capable of german language this might be very intresting in this context:

http://www.tomshardware.de/DirectX-OpenGL,testberichte-240159.html

Insbesondere die Seite über MultiThreadRendering