Search the Community

That is very interesting, I was thinking about this when considering how to implement the DarkRadiant particle editor (a future task, not even started yet). I was thinking it might be good to have a sort of "progress bar" like you get in media players, which would allow you to drag it to any position and see the particle state at that point, but that would require the particle system to be a deterministic function of time, which I was assuming it wouldn't be. It sounds like in Doom 3, it actually is. I guess this requires more memory as well, because each particle's position needs to be stored and updated. The deterministic function of time implementation requires no state to be stored at all, rather the function can just be called from scratch each frame with a different time value.

No, you can use a single material that uses your image (in alphatest mode, presumably) and the twosided keyword on a patch in Doom 3. It will be visible from both sides of the patch.

Absolutely, mine ran it just fine. In fact my new GF6 series card is only about 30% faster (I'm CPU limited). Angua and greebo's bonehoard runs really quite well, and the old version was quite good on the old card. Without tons of silly Doom effects going on, and instead conservative environments like Thief can often have, there's no reason a GF4 isn't usable for TDM. Maybe not for Calendra's city, but certainly return to the bonehoard. Also, remember these are Thief fans. We tend to have slow upgrade curves.

It's the options provided to the Compressonator which are important. For DX9 cards (those that can run fragment shaders) Doom 3 uses RxGB compression which swaps the alpha and red components of DXT5 in order to improve quality, requiring the fragment shader to unswap them. The pre-DX9 cards used something else, whose details I am not fully aware of, because there are no fragment shaders to do the swapping.

Okay, this is nuts. I don't know why the initial concern was raised, but no valid reason has come forth. There's nothing "special" about the search anim compared to the walk or run anim, and there won't be a need to break out of it just to let the head turn - either the head turning code can override the neck animation, or I remove the keyframes so that the head turning code can take over. Either way, the head will be free to look around. Seeing as oDDity didn't know about dynamic head turning when he made the walk and run, I'd say he would have left all the mo-cap animation as it was and tweaked it, and not deleted the neck keyframes, which means the code can override the neck animation. Just like it played the upperbody running animation while the legs did the walking animation, in that vid in the Out Takes thread. Doom 3 seems to be capable of controling the animation channels independantly of each other.

Doublesided is a property of the 3D object, not the image itself. There is a "twosided" global keyword for Doom 3 materials that does this.

The problem with DDS is that the compression can look really ugly on normal maps -- look closely at some of the TDS textures at an acute lighting angle and you can see lots of little squares where the 4x4 pixel block compression is working. There are also certain diffuse textures which don't compress well, for example a bright red diagonal line on a white background without any detail or noise in the texture. In our case DDS is probably valuable as a means of reducing download size, but there is good reason why vanilla Doom 3 provides TGA versions of textures (although IIRC, we are only using DDS for diffusemaps not normalmaps).

The shared directory is a great idea, and one I highly endorse if it can be done without any major drawbacks. The majority of T3 animations were shared this way I think. I find doom 3 to be inefficient in this regard and I think we could definitely make some improvements. Hopefully this will be possible. I don't think AI sharing these animations would play the anims at the same time, otherwise two city watch elite guards would be doing the same already.

Skinning is our most important need right now...check this thread: http://forums.thedarkmod.com/index.php?showtopic=1554 As for models, we could use some more loot objects and decorative art objects: vases, ornamental statues, etc http://www.bellaumbria.net/umbria/immagini/vaso.jpg http://www.khm.at/khm/data/page1034/image1.x300.jpg http://www.culture.gr/2/21/211/21122m/00/lk22m017.jpg http://www.usask.ca/antiquities/Collection/Hannibal1_1.JPG http://www.sculpturesplace.com/Images/Fantasy/fAndosa350.jpg

Again guys, you'll have to excuse me if you've already discussed this stuff 10000 times. I haven't had too much time to read through the entire forums yet, and I'm curious as heck to know what the low down is on buying equipment and sellings goods will be like? will/could the amount carried affect movement in any way? Could people who prefer ghosting thru certain levels choose to leave certain weapons at home, in exchange for some additional speed scrolls? heh heh. I think it would be definitely worth your time to figure out a nice bartering system to add to your MOD if you haven't already. If so, can u shed some light??

I'm pretty sure all of the VFS methods deal only with stuff underneath the Doom 3 directory and in .pk4 files. It might be necessary to load the image yourself, and extend the TexturesCache module interface with another method to insert a new image into the cache, e.g. virtual void insertImage(const std::string& name, const Image* img) It looks like an Image object is just an interface which defines, amongst other things, methods to return the height and width of the image and a pointer to an array of bytes, which you can presumably get through GDK's image loading functionality. Inserting it into the textures cache might be dirtier, because there is some stuff about LoadImageCallbacks that you would have to deal with but I think there is a default you can use for this. Oh, and there is that horrible HashedCache again. If you were feeling particularly energetic, you might find that splitting out the TexturesCache into a separate module would make things easier, and it might even be possible to get rid of the image callback stuff altogether, depending on whether anything is actually using it.

I only know this because I was a forum lurker whore on the Unreal Tournament : Infiltration forums for so long. I believe it somehow also makes distances in front of you look shorter than they actually are (like 100m away will look like 80m), but I'm not sure how that works.

This is fixed on SVN. The Doom 3 root path is required (i.e. C:\games\doom3). There have been cases where a subfolder is appended to the selected path (although it never happened to me). If this happens you can always edit the engine path via the Preferences to correct this.

You can only select Doom 3 from the global preferences, to get a mod you have to go File -> Project settings, select "Custom modification" and enter the "darkmod" name in the text box. This is perhaps a usability defect, as it seems to crop up quite often; feel free to raise it as such along with the other two bugs.

I see, so this is meant to happen (presumably it corresponds to Doom 3's "removed degenerate" output message). Doesn't explain the leak though. I guess I will have to use the pointfile to find out where the leak actually is.

Well, at least it means this bug doesn't have to block the release, assuming it only affects a few maps. @greebo: My DarkRadiant uses "// primitive" not "// brush" when saving. EDIT: Actually, no it doesn't, that is because Doom 3 re-saves the map when you BSP it. I will do another comparison before the BSP is done, so that we are comparing the DR-saved version with the original.

I sent an email his way...but it's been awhile since anyone has responded on the forums, so he might not be quite as concerned about it anymore.

I'm a bit confused...perhaps I am misunderstanding how these sound shaders work. I have two sound shaders in the sound folder. tdm_sfx_movement.sndshd - for player movement tdm_sfx_aimovement.sndshd - for ai movement The tdm_sfx_aimovement.sndshd is overriding the player movement sound shader. I thought that the sound shader for movement had to be assigned to the player or the AI before they could be used, but it appears that doom 3 is simply reading the values (human_carpet, human_tile) from tdm_sfx_aimovement first, and going with those values. Is there any way we can tell the system to only use tdm_sfx_movement for the player and tdm_sfx_aimovement for all the rest?

I get almost no hatemail now I had restraining orders put out. Also welcome to the forums. Please use proper English. Thank you.

On the forums: "As most of you will know, 3dTronic offers high quality free texture resources to the web community. Free of charge, they can and may be used in any kind of project, commercial and non-commercial. The only restriction 3dTronic implies, is that the images may not be distributed in any way for the sake of distribution purposes only. They are here to make the life of all genre artists more comfortable." Still a little vague, but it seems that the only stipulation is that they can't be distributed on big texture compilation CD's or websites. So as long as we're using them in a project, we're good to go.

Hey guys! Thanks for the concern but I am alive and well! Just, as everyone else seems to be, covered up in my "real life" job. I've popped on to the DarkMOD channel several times over the past two weeks to see if anyone was there but haven't been able to catch anyone at the right time. I think next weekend I'll finally be able to get back to sound effects and music, so I'm really looking forward to that! I've missed being around the forums and am sorry for my absence. -sax

Good question. Is the centre of mass always equal to the origin in Doom 3?

Will regular users have the capability to change such things as the AI (without having any particular skills in game-development coding, but willing to learn what is necessary)? What tools will be released, besides the editor? (There will be modifications made to the Doom 3 editor itself, right?) It would be great if some coding tutorials were released along with other tools.

If Doom 3 does have vestigial support for the OpenAl library, perhaps this can be re-enabled somehow so that EAX is not needed?

You are correct Sneaksie. Until I upgraded last year, I couldn't use EAX in Doom 3 either. We can't rip into the T2X footsteps too much, otherwise they might end up sounding like crapola...but if we can relieve a bit of the reverb from the stone and perhaps wood, then it should be alright. The T1 and 2 sounds did have quite a bit of reverb on the stone and tile. I'm guessing it was just to smooth out the sounds and give them a bit more oomf when EAX was applied.