MoroseTroll

The porting Doom 3 from OpenGL to Direct3D is a helluva job, IMO. Who from the Doom 3 community can perform this task? How much time can it take? Which exactly Direct3D version will be the target: D3D9.0 + SM2.x, D3D9.0 + SM3.0, D3D10.0 + SM4.0, D3D10.1 + SM4.1, D3D11.0 + SM5.0, D3D11.1 + SM5.1? BTW, has anyone ever ported Quake 3 to Direct3D?

7upMan, Briareos H: Ok, ok, I got it: the West, the East, and the difference of expression.

Please don't pretend an innocent - your phrase that you do like Shadowhide is just a phrase, not a feeling that you do really feel. I believe that your words about Slavic and Russian people are insulting. I don't know the people you've met in Russia, and I don't know what an artistic taste they have, but I believe it doesn't mean that you have a right to judge a whole country.

Briareos H: I hope you are not a Slavophobe, aren't you? You see, you may don't like Shadowhide as a person, but you cannot say the things you just said about all Slavic people because you, apparently, don't know them. So please stop it.

Midnight, New Horizon: Hey, I wrote "in theory" . Of course, I understand that it wouldn't happen even if id would make its Tech 5 free of charge. That was just a thought.

Gamasutra has published another interview with John Carmack. And I've found the following phrase that is very interesting for me: Does it mean that id Tech 5 would not be an ideal for TDM, in theory?

Unigine is not available for free for non-commercial applications. Moreover, this engine has not been proved as an excellent game engine, because there still no relatively big game projects do exist on it.

Meanwhile, CryEngine 3.3 becomes available for non-commercial use. Anyone?

I believe John Carmack is already a hero for many IT-people over the world, for two reasons: He shares the source of his games with the rest of the world.He keeps OpenGL on Windows alive for almost fifteen years.

Excellent news ! I was thinking that John Carmack will realese the Doom 3 source after Prey 2 only - say, at QuakeCon 2012 or even at Xmas 2012. It's good to know that this event will happen much earlier than I thought .

Hmm... What a nice boost, nbohr1more, from 35..45 to 55..60 fps ! Apparently, an elimination of the memory fragmentation could be much more useful then all my work with idSIMD, seriously. AFAIK, there are at least two methods exist to cope this issue: The Low-fragmentation heap feature in Windows. Apparently, Doom 3 doesn't use it because I've found no entries of the HeapSetInformation function.The Page Size Extension (PSE) of Pentium 1 and later CPUs. But Microsoft has implemented this feature (VirtualAlloc with MEM_LARGE_PAGES flag) starting with Windows 2003 Server (I suppose nobody of us is using this OS for TDM) and, ta-da!, Windows Vista.So, even John Carmack will release the Doom 3 Source, and somebody will implement the PSE support in it, all pre-Vista TDM-gamers won't feel any speed boost. Well, guys, what do you think about?

My sincere condolences to all Norwegian people. No matter what goal Anders Behring Breivik wanted to reach - he has killed innocent people, and therefore he is a terrorist.

Thanks for the good wishes .

Well, I understand your point of view. Yes, my code is still useless until id Tech 4 will become open. I hope this will happen this year, and then we will see how (in)efficient my code is . You see, I still hope that by boosting Doom 3 itself, I could boost TDM as well. Moreover, if someone from TDM team will learn that some hot function works too slow, I would help to improve it by implementing it in the idSIMD library. Yes, I know that due to the suboptimal size of the idDrawVert class (60 bytes instead of 64), any massive manipulations with it (as in ModelGenerator) can fool CPU hardware prefetchers, and because of this they can be RAM-bound. But I hope that it can be resolved when (if) the Doom 3 source will be released. As for ASM-code versus intrinsics I should say that it is not so important. If my code will be efficient enough, I will make it available on Linux and Mac versions of TDM, one way or another.

I'm sorry, guys, but it seems to me that I can ony start my work at the end of this June. Right now I have no time .

Voted for the fourth.

My congrats, jdude .

The idSIMD library charts covered on that Intel site is a part of Enemy Territory: Quake Wars, IIRC, another id Tech 4 game. There are some functions were added into the library since Doom 3, so I wonder whether TDM team can use the new (post-Doom 3) parts or not.

Ok, downloaded.

I've seen two places in ModelGenerator.cpp with idDrawVert primitive. I can optimize both of them, but if you are saying about the min/max bounds calculation, then I need an updated version of this file with an updated source code of the DuplicateModel function (+ DrawVert.h, Matrix.h, Vector.h). You see, the last version of TDM source I have is just 1.04...

I've already seen ModelGenerator.cpp. It seems to me that there will be no big deal to implement the function you need...

AFAIK, the earlier versions of GCC has a different inline assembler syntax than MSVC, but I'm not sure about the newer versions. About DRAWVERTS.H: I've already optimized all the idSIMD Library functions that are using DRAWVERT primitive: a pair of Dot, a pair of MinMax, TransformVerts, TracePointCull, DecalPointCull, OverlayPointCull, DeriveTriPlanes, DeriveTangents, DeriveUnsmoothedTangents, NormalizeTangents, CreateTextureSpaceLightVectors, CreateSpecularTextureCoords, CreateShadowCache, CreateVertexProgramShadowCache. Are there any of them useful for your needs? If not, I can easily create a new one for you.

The only way I can see to implement SIMD in the Linux build of TDM is to use FASM or another multiplatform assembler. I.e. to deploy all the idSIMD library functions as an .asm files and compile them separately. As for drawvert.h - I will see what I can do .

You see, Jan Paul van Waveren, the id programmer and the author of the original idSIMD library, has optimized it for Intel Pentium 4. My version uses AMD-specific instructions (E3DNow! & PREFETCH/W) and mode (so named "Misaligned SSE"), so I'm not sure that my code will run fine on Intel CPUs. But don't fret about this, because all Intel CPUs after Pentium 4/D (Core, Core 2, Core i3/i5/i7, Pentium E/G, Celeron M/E) have a very efficient instruction decoder that allows them to perform any code nice and fast. Eventually, if it turns out that my code will be fast enough, I could port it to Intel CPUs as well, by removing AMD-specific stuff.