Hallo I just came up with a pretty simple idea. Mutlithreaded rendering. I know that with DDraw, only one write can be performed once on a given surface, and therefore i came up with the following.... Assume that we have an Iso engine, the can render in multiple viewports, as we define ''em (already have this). Then we launch 3 threads that each one will render a part of the full viewport. Ie. +-------------------+ / Drawn by Thread 1 / +-------------------+ / Drawn by Thread 2 / +-------------------+ / Drawn by Thread 3 / +-------------------+ And then blitted all together on the same buffer. Do you think that this will produce faster rendering?? Any ideas on the concept? RFC post Paris Theofanidis X-treme DevTeam ( http://www.x-treme.gr/ )

I don''t think it''ll be faster cause you''re using the 2d card after all, so if it could work that fast, even without thrad it will run that fast.
Instead, you could use double or tripple buffering.
And you case uses threads for music, input, sound and graphics, with a timer and some priority rules...

Correct me if I''m wrong.

-* Sounds, music and story makes the difference between good and great games *-

No matter how many or how few threads you have, you still only have one CPU (usually) and it can only go so fast. I doubt if you would gain any speed by having different threads render different things, but you would have to duplicate a lot of code most likely.

If you want to experiment with threads, try having one handle all the rendering and another one handle user input. This is a common practice.

Even if you are using one CPU, multi-threading can be faster. Windows allocates CPU usage per application. Multi-threading can use more CPU power if done correctly. I do not use multi-threading. I like to use setproirotyclass and setthreadpriority. Some function like that.

I believe you''re right about the graphics board not being able to do parallel blitting to the same surface, but can it do parallel(simultaneous) blitting to different surfaces?
If not, how does double or triple buffering speed the rendering?

DirectDraw is thread-safe, and will impose mutex locks on touching the buffer you''re blitting to. So, you would have the effect of serializing the blits, and the additional overhead of thread synchronization, so it''ll probably be a bit slower.

Remember, vary rarely does multithreading a CPU intensive application (like a game) give a speed-up.

The beneficial of triple buffering is due to the fact that the monitor had a refresh rate, and the image is only blit when the scan pass.
I''ll try to explain this better or to find a good article about the advantage of triple buffering.
Basicaly your card will wait less time for the vsync, and thus you can gain up to 100% fps.

(not a very good explanation, I know)

-* Sounds, music and story makes the difference between good and great games *-

Maybe it is a good idea to make a lighting calculation thread for example?
or a particle system update thread, a lot of special fx can be done very good in a new thread I think.

Anyway, just brainstorming

- John van der Burg
Programmer of Oxygen3D
http://www.mysticgd.com

I have two threads in my engine. One continuously updating the screen from a smaller "render queue" as fast as it can.
The second thread runs X times per second and runs through all objects in the game updating there positions etc. If they''re on or very close to where the screen is in the game world the object is added to the render queue so that it is drawn by the first thread.

This allows the user to scroll about and select objects while the game engine is updating information in the background.

hm... maybee if each thread blits to a diferent surface, and at the end, all the 3 surfaces are blitted to the backbuffer.....


The waste will be the blit time diference that there is between the Videocard blit, and the software blitting, plus the final blitting of the 3 pieces together...


Yes, i think that having the effects on a different thread is better, hence you don''t blit directly to the Video memory, using normal blitting, but you blit each pixel yourself. (Unless you use a 3Dfx chip )