Irrlicht Engine

AI is indeed a very good candidate for parallelization, I don't have an AI system myself yet, but I already use the system for animation, physics and audio updates
Once I build a DX11 driver it could become possible to apply it to rendering jobs too

About code commenting. It's true that having good variable and class names can do the trick. However, it's not the full solution. The problem comes when you write the functions. I learned that a good comment not only helps you remember whet the function does. But when you have a fellow programmer, both can be on the same wave. and you save time. So I comment code as I program, then I edit the comments to make it more professional.

At my university we mostly use a programming paradigm called 'Nominal Programming' or 'Design by Contract Programming', which requires you to write formally formatted comments with details about every single thing your function does and all conditions which have to be met when a function is called, you could even say that they pay more attention to the code comments than to the actual code
I pretty much hate this kind of programming though, comments are great, but nominal programming is not fool proof since it expects that the client using your code always gives perfectly correct input (so no exceptions or special case handling), causing crashes when faulty input is given (which is completely unacceptable in real-time systems)
Huge commenting also makes your code less manageable since most of the time you have to search where the comments end and where your actual function declaration starts

It's all about finding an ideal standard for commenting, don't over-do it but don't ignore it at all either

I'm trying to learn D at the moment, and just yesterday stumbeled upon contract programming. Maybe 'Design by contract programming' and actuall contract programming is different though, i dont know :P
D makes it very simple to implement though, as it's a feature of the language and not something that is embedded in comments..

..., but nominal programming is not fool proof since it expects that the client using your code always gives perfectly correct input (so no exceptions or special case handling), causing crashes when faulty input is given (which is completely unacceptable in real-time systems)

I'd like to counter this with another quote, from http://www.digitalmars.com/d/2.0/dbc.html

The idea of a contract is simple - it's just an expression that must evaluate to true. If it does not, the contract is broken, and by definition, the program has a bug in it.

Of course, a crash may be unacceptable in some real-time systems, but the cause of the crash is a bug. If one ignores this and blames the contract for making the application crash, then one is doing it wrong.
So, if anything, dont blame contract programming, but the language that doesn't support it properly? ;]

Luben wrote:So, if anything, dont blame contract programming, but the language that doesn't support it properly? ;]

Of course a crash is a bug (and a serious one too), but the thing that bothers me is that as a developer of a library using the nominal paradigm you can write bug free code, but you can still have clients messing up and crashing a program (by their own fault of course) through your function, since they broke the contract you have set up

When using total or defensive programming you can handle exceptional cases, by handling them in the function itself (total) or by throwing an exception (defensive) causing the program to maybe show an error message or at least notify the client that something went wrong, but in the end it will still continue on with execution (if possible)

I think these last two paradigms are perfect for game programming, since you can't afford to let an external asset crash your complete app for example (eg. file not found error, file corruption, etc.)
This of course puts more responsibility with the original programmer(s), but the system will be easier to maintain and support, since clients will not be able to mess up your internal workings

And I believe there are extensions available for different languages to support contract programming, but I don't think I'm going to bother with those, I concluded that I like the total paradigm better

people, PEOPLE STOP IT!!

MULTITHREADING ROCKS! Multithreading Nightmare rumour has been invented by semi potent developers who cannot afford multi-core set-ups or EVIL database linear search boring f**kers.
If you dont get threading, go write shitloads of shaders, that will get you thinking parallel.
There are simple rules to follow:

0) KNOW WHAT FUNCTIONS MODIFY THE SAME GLOBAL VARIABLE, either dont thread them or look at point no. 2

1) Do not run more than NumberOfCores*2 threads, if you think you need to... make a task queue. Trust me you dont need to, even running audio engine like cAudio, you can group it in the same thread with networking.

2) DO NOT HAVE TWO OR MORE THREADS POSSIBLY MODIFYING THE SAME OBJECT!!!! Use mutexes (mutual exclusion locks) so only one thread has access to the modified object at a time (I append to one mesh buffer with possibly 4 threads). Remember non blocking locks exist like trylock in pthreads which means you can make the thread get on with something else while it waits for the mutex. If you are modifying simple integers you can use atomic operators.

3) it is completely okay to write to variable in one thread and only read it in another

4) Make the thread pthread_yield() whenever you need to wait for something and have no work to do (gives up core for other threads). THIS WILL HELP YOU IF YOU HAVE BEEN DUMB ENOUGH TO HAVE MORE THREADS THAN DOUBLE YOUR CORE COUNT!!!

5)Remember you main thread main() has to work too, and is yet another thread on your CPU, you have a dual core with hyperthreading?? create 3 threads and not 4, make your main() do some work.

6)Remember of pthread_join()??? waits for threads, threads can be scheduled too... if you want

7)Measure the relative load between your threads, some can be working hard while other slack off/sleep for half the execution time. Balance the load! Profile Threads!

DONT GO THREAD HAPPY like Intel

9) OPENGL IS NOT THREADABLE!!!!! CREATING BUFFERS/TEXTURES/DRAWING must occur in main thread

10) ADDING SCENENODES IN IRRLICHT MODIFIES AN INTERNAL LIST OF SCENE NODES, MANY SIMILAR THINGS HAPPEN, SO DONT THREAD THEM OR MUTEX THEM

11) IF THE OBJECT HAS NO GLOBAL CONNECTION, YOU CAN THREAD. i.e. YOU CAN ANIMATE AN IANIMATEDMESH AS LONG AS YOU PREVENT IT FROM BEING DRAWN WHILE YOU ARE DOING IT (OTHER MESHES CAN BE DRAWN)

You just gotta know which functions called AT ONCE will overwrite each others data. I just wrote a multithreaded grass generator. all 4 threads

@devsh

i like how you start at 0 with your list

and thanks for tips. i was a bit confused of multithreading because of what some "semi potent" coders say.

Just saying "use mutexes" will very likely result in slower code than a single-threaded one. Even if you up the count to 4, 8, 16 or more.

Always, always measure if you're getting any improvement at all. Scaling is hard.

devsh wrote:...

The MASTER has SPOKEN, all bow down before HIM and HIS limitless knowledge, power of CAPS and rudeness!

(SERIOUSLY, you could at least TRY to give the IMPRESSION of not being a little KID)

Obviously you are THE MOST experienced computer whiz on these forums, so i find it kinda OFFENSIVE when you DELIBERATELY try to MISLEAD people and RIDICULE others.

You are, OF COURSE, just as awesome as you THINK you are. I just think the world isn't READY TO HANDLE the sheer amount of godliness that is DEVSH. please go easy on us, mmkay?

</rage>
before i go, i'll just leave this here.
http://www.opengl.org/wiki/OpenGL_and_multithreading

Luben wrote:

Pwnd

Maybe I'd take Luben a bit more seriously if he had a better profile picture - hehe joking, no offence intented... it funny how you are the less mature one by trying to contradict/ridicule everything I say

devsh wrote:Maybe I'd take Luben a bit more seriously if he had a better profile picture - hehe joking, no offence intented... it funny how you are the less mature one by trying to contradict/ridicule everything I say

Not trying to provoke a flame war here, but I have to agree with luben
You might be a good programmer for your age devsh, but there's no need to act like you're god's gift to the world whenever you post

Most of your posts consist of either rudely giving 'advice' (with lots of caps to give a wow-effect), or of how awesome a programmer you believe yourself to be whenever you implement something new

If you have something to show, that's great, if you have any advice to give, that's great too, but some modesty could never hurt

I swear not use CAPS every again (oops I failed).

To get the discussion back to threads (OK, still OT ): I am well aware that threads can be useful, but there are some things you should consider before using them:

- know what you're doing
- don't create threads that wait for each other most of the time
- get a stable and threadsafe message queue as first goal

I am (still) planning to multithread my IrrOde wrapper. This would mean one thread for Irrlicht, one for ODE and maybe some others for network and such. The main problem at the moment is a temporary lack of motivation

main concern is, "is it worth threading?"

i.e. multithreading I/O polls in the EventManager would most likely take away vital performance and queueing them serially after each frame wotn hurt you as the human using the computer is not likely to type at >60hz

Brainsaw wrote:I am (still) planning to multithread my IrrOde wrapper. This would mean one thread for Irrlicht, one for ODE and maybe some others for network and such. The main problem at the moment is a temporary lack of motivation

Are you sure a 'one thread per system' approach is the way to go? It might be easier to design and implement, but it won't be scalable to the amount of CPUs in a machine and will definitely cause an overhead on machines with only dual-core or even single-core setups

Scalability and adaptability of a multithreading system has always been a priority to me personally, but maybe you see it differently

I think the approach is best for this case. I am also planning to have an option to disable multithreading (either at compiletime or at runtime). And yes, it won't really scale, but at the current single thread approach it doesn't gain any benefits from more than one CPU.