I can help too. I hope

[tech]

Just you to know if you need some of my skills:

I'm a student, fascinated by low-level programming: I had a little OS'dev project, but it got frozen cause I was alone, writing it in asm, had no much time. Now I do some researches about information security. To my regret I haven't started yet learning driver coding, but I'll do my best. If you need some low-level implementation, I'm here.

I know asm (fasm syntax). Also I know C/C++, but I used them long time ago, cause my favourite language is asm.

[greebo]

Hey there.

 

I'm not sure we have much use for hardcode assembler coding in the mod. The only place where assembler is used in signficant amounts is in the SIMD class hierarchy (you might want to check up with MoroseTroll about the status of that one).

 

Help with programming in C++ is always welcome, but beware that I've grown very hesitant to have new folks signed up and to lead them by the hand. I've done it dozens of times and I just don't have the time for that anymore. If you are willing to help, prove it to yourself that you are able to handle the TDM codebase, by picking one of the issues on the bugtracker, diving into the code and trying to fix it. Asking questions is always ok, of course, but don't expect anybody to do your "homework" (= reading the code, trying to find a solution that is not hopefully not just a dirty hack).

 

I'm probably coming across more harshly than I actually am, but I've seen too many people sign up and disappear after little more than two weeks. I'm not intending to discourage you, just go ahead and test your skills on an actual problem on the tracker.

 

Generally, you don't need to be a team member or have access to SVN or the team forums. Everything you need to get started is freely availabe: the code, the bugtracker, the wiki including compilation guides in all three supported platforms. Just get cracking!

[tech]

When I have free time (weekends, I suppose), I'll look for some bugs.

I don't try to declare myself as an active project member, but sometimes I can do some job, if I have an appropriate mood and free time.

[MoroseTroll]

greebo: I'm waiting for the source of Doom 3. Not sure that my implementation of idSIMD would help TDM, but who knows...

 

tech: I think, TDM needs some optimization, but by multithreading (not by using asm, as I was thinking before). As all we know, almost all modern CPUs are multicore, but Doom 3 (and TDM) almost doesn't use multithreading. So if someone would parallelize it, it would be wonderful .

[i30817]

No, it would actually be buggy.

 

Trust me.

[greebo]

I've already spent one or two days to hack multithreaded AI thinking into the game code (I think it was sometime in 2010) and it was a disaster, since most low-level libraries are not thread-safe.

 

I'm not saying it's not possible or wouldn't have benefits, but it definitely requires some extensive work. That, and full source access, since the collision model manager code is among the systems which are not thread-safe (it's using static local variables/arrays behind the scenes, if I recall correctly).

[MoroseTroll]

Yeah, it's a helluva job - to make code multithreaded, but I think it's the only way to make Doom 3 & TDM run much faster...

[i30817]

Let's just say that companies regularly redesign entirely or just add hardware into simple programs rather than make the original code multithreaded.

 

Basically doing multithreaded code worth it requires:

 

0) profiling and make sure the limitation point is not inherently sequential.

0b) check that the whole runtime libraries used in what you found are thread safe or can be made thread safe (without losing the expected performance).

1) algorithm redesign

2) finding the right crossover point from dividing the work to working into single thread

3) very carefully check the uses of shared resources and their publication points

4) very carefully check that you've found all of 3

5) pray, since you can't have good unit tests for thread bugs.

6) go insane if you used wait/notify/join or lock/unlock/readlock instead of queues/fences & other high level slower constructs.

7) profile again to see if you haven't actually made the code slower due to vagaries of the OS thread scheduler and/or over locking and/or cache non-locality.

8) ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Edited October 22, 2011 by i30817

[Sotha]

Let's just say that companies regularly redesign entirely or just add hardware into simple programs rather than make the original code multithreaded.

 

Basically doing multithreaded code worth it requires:

 

0) profiling and make sure the limitation point is not inherently sequential.

0b) check that the whole runtime libraries used in what you found are thread safe or can be made thread safe (without losing the expected performance).

1) algorithm redesign

2) finding the right crossover point from dividing the work to working into single thread

3) very carefully check the uses of shared resources and their publication points

4) very carefully check that you've found all of 3

5) pray, since you can't have good unit tests for thread bugs.

6) go insane if you used wait/notify/join or lock/unlock/readlock instead of queues/fences & other high level slower constructs.

7) profile again to see if you haven't actually made the code slower due to vagaries of the OS thread scheduler and/or over locking and/or cache non-locality.

8) ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

 

Curiously, the only entry I can understand is the last one. Peculiar, is it not?

[i30817]

There are even worse things.

 

I shudder to think of the deep ones behind non-blocking parallel datastructures.

http://video.google.com/videoplay?docid=2139967204534450862

 

 

AIIIIIEEEE!!!

Edited October 22, 2011 by i30817

[tech]

Ohh... Converting program to multithreaded one is a rather hard thing as it was said here,,, We'll need to revise the whole Doom3 code and correct it. And bugs will be everywhere.

It's easier to use some engine and implement TDM through it than to correct Doom3 source code