MoroseTroll

Windows has an environment variable, NUMBER_OF_PROCESSORS, which is equal to the total CPU threads (not CPU cores) available for OS. I'm sure that Linux and MacOS have something similar. In Windows, all you need is to check that variable and voila - you may bind the Light Gem function to any CPU thread you want. Of course, there some simple (?) multitask manager will be required in order to implement this feature. So, TDM programmers, what do you think?

Just a thought (sorry, if someone have already spoke about this): can you, guys, set the affinity of the Light Gem calculation function to another thread? Almost all CPUs of TDM-fans' PCs are multicore, and the Doom 3 itself is a mostly one-threaded application, so maybe such a trick is feasible?

Yesterday I've tested THoLS. The time of loading with TGA-normals is 152 second, with RxGB-normals - 92 second. Also, I've monitored the memory usage and noticed that the RxGB-version consumes 58 MB of RAM less than the TGA-version of the mission.

Well, if someone is interested, here is the source of my DXT Cleaner utility. It finds DXT3/DXT5-files and removes the alpha channel, if it's opaque. I've written this utility six or seven years ago for Star Trek: Elite Force II. I've ran my utility through the whole TDM package and have found (and automatically) converted about four dozens of DXT3/DXT5 files into DXT1. I know, it's not so much...

As far as I can remember, I've learned from my analysis of Doom3.exe that it can use so named GL_ALPHA8_EXT (0x803C) and GL_INDEX8_EXT (80E5) formats. I suppose, in DirectX, these formats should be named as Alpha 8 / Grayscale 8 / Index 8 or even A8/G8/I8. I'm sure that the ATI Compressonator 1.21 does support A8/G8/I8 in the "Alpha compression" / "Grayscale compression" / "Palette compression" options. BTW, A8/G8/I8 formats are not DXT-based, instead - they are index-based. But anyway, I hope they will be useful in order to reduce the size of grayscale/alpha images and thus - the time of mission loading as well.

Well, I can provide my scripts, if you, he or anybody else is interested to take a look at them - here. Make sure that you've installed 7-Zip (in order to repack the PK4 archives) and ATI Compressonator 1.21 (in order to convert the normals into RxGB). Extract the content of this archive into "darkmod" folder (it'd be wise to make a backup of it) and run the "RunMe.bat" file. Be warned that my scripts are using a substituted Z: drive, so if you are already using some device mounted to this letter, please modify the "RunMe.bat" file and change the line "set %vd%=z" with another (not Z) letter. In my case it took me about two hours to perform the first phase. The second phase is... a hand work . That's right - ATI Compressonator 1.21, apparently, has some bugs, which prevent it to convert some TGA in the batch mode. So, if you're brave enough, all the time of this conversion you'd click several dozen times on Windows error message caused by the faulty ATI Compressonator's Boxfilter.dll. As such, several dozens of normals won't be converted in RxGB form, so you'd made this by yourself, in the interactive mode of the ATI Compressonator.

It's me. Again . First. You, guys, have made a great job with the 1.03 version. The game really looks better. Second. I have performed TGA->RxGB transformation for the 1022 normals (1.3 GB in total) and have tested the time of a mission loading (RxGB vs. TGA): NHAT1/3 - 62 vs. 105 sec., speed boost = 1.69 times. NHAT2/3 - 89 vs. 136 sec., speed boost = 1.53 times. NHAT3/3 - 83 vs. 132 sec., speed boost = 1.59 times. My rig's specification is: Phenom X3 8450 / 2.1 GHz, 4 GB DDR2, Radeon HD 4770 / 512 MB with Catalyst 10.12 (AI is off), Windows XP SP2. As you can see, the compressed (RxGB) normals are significally improving the time of a mission loading, especially on a relatively weak CPUs like mine. Moreover, I've found about 400 TGA files that are not normals. Why are they still not compressed into DDS? Some of them are height maps (*_h.tga) and alpha-channels - these ones could be converted into one-channel grayscale DDS, which could reduce their size by three times. All others could be converted directly into DXT1/DXT3/DXT5. This could save the time of mission loading even more. Third. I've tried to implement in TDM more advanced normal map compression, DXT5nm, instead of RxGB, but I've failed. Can your shader gurus tell me, what did I wrong? I've modified three vfp-files, as suggested there, in order to replace RxGB to DXT5nm, but with no luck .

That's the main problem of many in-house engines - instability. Who knows, if Arx was built on something like Unreal Engine 2, LithTech Jupiter, GameBryo, RenderWare, or idTech 3, there would be much less bugs in it...

There are several types of bumpmapping exist: emboss (EBM), environment mapping (EMBM) etc. The first one is the simplest and supported absolutely on every hardware. The second one was introduced by Matrox in its G400 (1999) and then supported by ATI Radeon 7200+ (2000).

My bad, I haven't noticed this .

Do you mean that the behaviour of the TDM Updater has been changed in v1.03? If it so, it's a good news - thanks! And sorry for the disturbance .

Have you guys changed the TDM Updater's behaviour? What do we have right now? I have to manually download the TDM Updater every time I want to update my TDM package to the newer version. What if the TDM Updater would download and update itself, and, after this, it would update the whole TDM package?

Some AMD's VIPs have a blogs (for example, Nigel Dessau), so you guys can easily inform him about the situation on the AMD Game forums.

Either way, this situation of the AMD forums is not acceptable.

Everything is possible. The main problem is who exactly would work on this feature?

Jason, I'm a guy, not a girl !

Double post, sorry .

No, guys, I haven't had a copy.

rich_is_bored: Don't worry, I'm sure the Thief community has enough qualified programmers to cope with any problem.

Downloading the source... Still, I can't believe this happened! Fucking Eidos would never do that! Thanks god, some people can dig deeper than I can.

I've learned from my analysis of Doom3.exe that it treats DXT5 and RxGB as identical texture formats. So, if I'm correct, I hope there will be no difficulties to feed some DXT5nm-compressed normals (with nVidia Texture Tools, for example) to Doom 3.

Maybe.

I don't want to upset you, but that was pure coincidence . I have told about 3Dc on TTLG about year and half ago, but no one have heard me. About my Catalyst AI Switcher: this utility has been created before you've started this topic, just see at the date and time of the files in the archive for yourself. Sorry .

Serpentine: AFAIK, 3Dc support has been integrated into ATI Radeon X800 (and all cards later) in 2004, not earlier, with GL_ATI_texture_compression_3Dc. Alas, this OpenGL extension was never supported by nVidia (according to Realtech-VR OpenGL Extensions Viewer), so the only way to use 3Dc on non-ATI/AMD cards in Doom 3 is to use GL_EXT_texture_compression_latc/rgtc, which is possible only on DX10-compatible hardware. Aprilsister, ungoliant: Ok, ok, now I see that my proposal about upgrading DX9-cards (and using 3Dc) was, say, too early . Well, let's think about DXT5nm instead of 3Dc (but I'll post the same topic on Doom3World.org ). DXT5nm is supported on every DX9-card (and even on DX8-ones), so I hope it would be nice to try use it instead of uncompressed TGAs. If I'm not mistaken, all I need to use DXT5nm-compressed normals is to move them into "DDS" folder, right? So, I'll try to do it this weekend.

Firstly I'd like to be assured that my 3Dc-hack works on the Windows-executable of Doom 3. If it so, I think I can hack the Linux-executable too.DX8-cards I know are: nVidia GeForce 3 / 4 Ti (GeForce 4MX is a DX7-card), ATI Radeon 8500-9250. All these cards are drastically slow to run Doom 3 even in 800*600 with medium quality, and I'm quite sure that nobody from TDM fans is using them. DX9-cards (nVidia GeForce FX / 6 / 7, ATI Radeon 9500..9800 / X300..X850 / X1300..X1950) are still on track, but I'm sure that after one year they will be upgraded to much more powerful DX11-ones. So yes, 2011 will be a DX9-year for TDM, but I'd like propose you, guys, that you'd suggest all TDM fans to upgrade their DX9-cards to DX10- or DX11-ones.