I have restarted making my engine and have come to a important decision that has to be made now (deals with the core of the engine). My engine currently is single task program, game loop. Now i have a linked list that calls different update functions for various things, lighting, animation, objects, blah, blah, blah. Should i add multithreading into my engine for some tasks? Will it make my engine run faster or is it a waste of time.

If you have a multiprocessor/multicore/hyperthreading system, you should experience som speedup. Otherwise it is more a matter of program flow.

It's a timing issue, mainly. Multi-threading is mainly needed when processes need to run concurrently (say client updates to a server).

This probably won't be the case in a single linked list of objects. More likely is the need to run object functions at different times - say you have update functions that need only run once every 30th of a second, but animation functions that need to run every 60th of a second.

To accomplish that you just need to track two different "tick" counters. When you hit your 60th of a second tick you iterate through your list and only "fire" the functions that use that counter, ignoring the update functions that fire every 30th of a second. The NEXT time through, BOTH your counters will be valid, so you fire-off both types of functions.

You might want to stagger the timings on these counters so they don't both fire at once. So when your 30th/second counter fires, your 60th/second counter might be at say 45. Then you never have both updates and animation firing on the same pass through the list. Obviously you must be able to iterate through the list before the next "tick" occurs on either timer.

But however you handle this timing, iterating through the list is a sequential process - you aren't going to fire object A's update on a thread, then while that update is running continue through the list and fire object B's update. You will finish object A, then iterate to object B. The only case for multi-threading here is if you want to be able to run more than one iteration of the list at the same time - but generally your animations will change as a result of your updates, so it is better to stick to sequential processing. Just remember that if two functions in two separate threads access the same memory, the first to access it will have it locked, and the second thread will have to wait. This may actually degrade performance.

You will probably find the slight performance increase using threads this way to be not worth the complexity of management. A better way to use threads is for separate sub-systems: a thread for user input via keyboard and mouse, another thread for timing, etc. And these aren't processes that are connected to individual objects, but are components of the engine. they will usually work in entirely separate memory spaces, so memory locking and the idle time it can cause aren't a problem. Take the case of user input: it will ultimately update some properties/variables that will be applied to objects, but by careful thread management the user input thread will only WRITE these, and the object update thread will only READ them, keeping memory collision to a minimum.

ok i see what your saying. Putting user control onto a seperate thread sounds like a good bet and i can leave other parts of my engine alone for now. Another problem i come into is that OpenGL allows only 8 lights (what i hear). Now maybe its just me but that sounds low. Is there another alternative to traditional lights that give good effects or some kind of trick?

One thing you can do is additive blending. You can render the first 8 lights, then turn on blending and render the next 8, and the light from them will be added to the light from the first 8.

Pixel shaders (I think they're called "fragments" or some such in OpenGL?). If you need more lights than the fixed pipeline can give you you should go with shaders. Much more powerful and flexible in any case.