HMart

The fact you really can't update drivers and not even OGL 3.2 seams to be fully supported, the only solution for now that I can think of, is to play a older version of the game, one that still has support for the original Doom 3 render based on OGL 2.0, but I don't remember which one, others may help better. Playing a older TDM, does means you will be unable to play the more modern missions, but even so, your GPU is very old anyway and would very probably suffer with the more heavy modern missions and there's still plenty of older ones that are very nice to play.

Unfortunately his are the latest available drivers. But yes based on this link the Radeon HD 3000 should be OGL 3.3 compatible, is TDM using some non core extensions?

I saw totally unrated movies as kid, in national TV, even porn movies and didn't turned into a sexual deviant or a murderer, with such restricted age rating and censorship that we have today, we still have as many sexual deviants and murder cases today, perhaps even more (thou I think that is because they get reported more now) then we add when I was a kid. Just my opinion.

Write what stgatilov says, I didn't looked at the code like he did, only transmitting what idSoftware has said themselves in their old wiki but even their employees, could have been wrong when writing that or it did worked like that but then they updated the gui handling code and forgot to updated the wiki. Only way to be sure, is to look at the c++ code and or test a GUI.

Something like this. not sure if well done but works for me and was really easy, don't know why idSoftware never implemented it originally, seems very obvious and useful, only Quake 4 has similar ability. edit: Took a fast look at the wiki being done and saw this there... That is wrong and not what I recommended at all, if I passed the wrong idea then my bad, was not my intention. What I really said, is exactly the contrary, what i said is that I add problems using, in this case colors, defined with preprocessor macro #define in transitions, only when using definevec4 for that coupled with the $ sign did they work. But the better and widely used method by idSoftware was to input color values directly! Also #define macros aren't really "float parameters", like definevec4 or definefloat, they are exactly like C macro preprocessors like stgatilov said, just text substitution.

I remember some idSoftware dev on Doom3World forum saying exactly that, they also said that in float "somevar" "0" the "0" is ignored From iddevnet, but you can look at the c++ and see if is true or not just to make sure. That is indeed not correct, unless is for Doom script... idSoftware says for Gui script user var definitions you should do: float myfloat or float "myvar" "0" // see above about zero or other value being defined here at user var definition Hum you maybe right but Doom 3 main menu does uses that "!=" if ( "SGC1Title::text" "!=" "" ) { set "forecolor" "0.6 1 1 1" ; set "SGCBtn1EdgeG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1BorderG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1CornerG::matcolor" "0.5 0.7 0.8 0.5" ; set "noevents" "0" } This is awesome info and explains why some of my ifs didn't seem to do what i expected. but is that still true, if you change it through c++, using "_gui->SetStateInt("gui_var", value);" or is only when doing it from Doom Script?

Hey thanks that does teach me a lot about how the gui language works and clears some things, thou I did knew definevec4 was not a macro, that is why I put macro, word within quotation marks.

I have not read your wiki about the gui scripting, so sorry if this was already known by you and talked about, but if not, imo is always good to know that gui scripting language, can do a little more than what idSoftware used and talked about. Unless i failed to see where idSoftware talked about this stuff. I discovered this by accident, when I tried a few stuff that Doom Script supports, to see if they worked with gui scripting and they did. For example the gui language, other than #include also supports #define, just like Doom Script, thou in a more limited way, so you can do basic text substitution using #define like: #define COLOR_WHITE 1,1,1,1 #define WIND_HEIGHT 480 #define WIND_WIDTH 640 or more complex #define RECT_SIZE ((WIND_HEIGHT/2)-(320/2)),((WIND_WIDTH/2)-(240/2)),320,240 then used as: rect RECT_SIZE ----------- It also has basic support for pointers! using $ sign, example: transition "start_white::matcolor" "$Desktop::COLOR_WHITE" "$Desktop::COLOR_BLUE_07" "1000"; and other capabilities that I may be forgetting, have not messed with gui scripting for ages now. Thou i remember macro and pointers support was not free of problems, there's some idiocentricities with this stuff, for example macros using #define and defined in the global space, meaning outside the main desktop windowdef or any other windowdef, work globally and are accessible directly by name (just like in Doom script), but seem to work, only in some things, like "rect", "backcolor" and others but not in transitions, I remember having trouble with those, the only thing that worked well for this ones, was defining the "macro" in another way, like this and inside the main desktop windowdef: definevec4 "COLOR_WHITE" 1,1,1,1 Despite #define COLOR_WHITE 1,1,1,1 and definevec4 "COLOR_WHITE" 1,1,1,1 looking similar and apparently do the same thing, behind the scenes they seem to be handled totally differently. I don't claim to have tested this macro stuff very deeply but imo has potencial to make gui scripting life easier, but caution in the few tests I made, transitions using macros, were the most unstable GUI feature, they work the best inputting values directly, specially because those are separated by spaces not commas. Thou using pointers like I show above, even using colors defined using commas worked, sometimes... I think this, spaces versus commas, most be why macros and pointers were mostly ignored by idSoftware, most of their GUI's only use a "safe" subset of the GUI script language and I unless I missed it, I never saw #define being used in any of their gui's. But they do work in the basic tests I made, Gui scripters just need to be aware of the limitations.

That brought some memories is a very old test map/thing that I used to learn DR and TDM modding, I spend a few weeks messing with it only. I add almost no idea what I was doing the scale is all wrong for example. Thou If I remember correctly, this test map has at lest 2 or 3 custom models that i made that I don't recall ever being used on any real mission, would be a petty if no one took a look at them to see if they are of any use. Btw those frob-animated boxes, were my first foray into coding and Doom Scripting, also trying to code any ingame interaction with the language, to see if i could do it, so the script code logic most be a absolute mess and perhaps hardly useful but happy you find it cool.

Personally I don't like depth of field, in real gameplay at lest, for screenshots and cinematics is fine but if you want to try including it yourself, sikkmod for Doom 3 has a ARB shader for it, so if you learn basic Doom 3 ARB and TDM GLSL shader code, you could translate it to TDM, both engines follow the same basic principles.

IMO that is not a good idea, stencil shadows and shadow maps, are two totally different things, technically and visually, putting them both under a single shadow quality option, IMO is not correct and may lead to way more confusion by mission makers.

"spawnarg" is just spawn argument, is a variable you write inside a object definition (the .def files) that gets used at spawn time, to do many things, they are both accessible by the script language and c++. Hope this clears some things.

In this case for a shadow and physics mesh imo is very easy, just make two extra copies of the lowest LOD, slap the shadow material in one and the collision material on the other and make sure both occupy the same space and are on the same item mesh/layer has the main model. In blender (or any other 3D Tool) you don't need to import any TDM material or texture, you just make a basic material for the shadow and collision mesh and make sure to give each the name of the shadow and collision material respectively (not the .mtr file name the full material name, inside the file), is that easy! bear_statue_example.7z ps- here is a fast example of what I said, sorry for not making it plug&play to TDM. I add too mess with the model because I use Modo and it doesn't open ase files, I add to convert to obj using another tool and also rotate it in Modo to be able to work with it, so now is not a, one to one, to the original model and so shouldn't be used with the LOD's that were provided, this because I assume they will not match, but I didn't tested, plus the material name for the main mesh is not the correct, only for the shadow and collision mesh's are correct (follows doom 3 convention). This should be seen just as a model for anyone to know how a shadow and a collision model should be setup. (for those that don't know) I also used the second LOD counting from the last because the lowest LOD seems to not follow the main model silhouette perfectly, it could very well work at the distance but not for a shadow and collision mesh.

Sorry if late but if still useful, here is a memory dump of the DR 3.0.0 crash. https://drive.google.com/file/d/1Ws7FFyG15NTp-q8GuGnWUMKTUVwkoCpY/view?usp=sharing

Yes indeed but DR 3.0.0 like I said also crashs but is after, not during initialization and is random, sometimes it crashs, sometimes it works fine. Btw If other AMD users aren't getting the same behavior, it may very well be my particular PC configuration, I did some stuff to this computer that may not be desirable, like hot swapping the entire motherboard, the CPU and the GPU for new hardware without reinstalling windows, it works fine (and I've read online that windows is ok with it) in pretty much I do but it could influence DR somehow?

Sorry try this one https://drive.google.com/file/d/10g0D4Ujn9V99yezEgcNPgP1gvV_MLNTe/view?usp=sharing

I have a AMD 6600 XT GPU and a Ryzen 5900 CPU I confirm the bug in DR 3.0.0, red selection works on 3D view but not on 2D view, also it crashes randomly after loading to me. Unfortunately can't test DR 3.2.0, it always crashs before it opens. memory dump https://drive.google.com/file/d/10g0D4Ujn9V99yezEgcNPgP1gvV_MLNTe/view?usp=sharing

Is that endorsed by Nintendo? I hope it is because Nintendo can be very protective of their IP, it has shutdown mods before, I'm cautiously optimistic.

The physics on that video do look better, I still think they aren't "normal" looking, i mean not similar to Havok, PhysX or more recent physics engines but I can't deny that was way better than the older video. Btw I knew that using a faster single core CPU, would make the idtech 4 physics engine able to calculate more objects, what I didn't knew, was that you guys made it able to use multiple cores?! Is that right?

Look how few boxes there's moving on that simple scene and already the performance feels so low. Next to the problems you pointed you can clearly see in the TDM video, how the physics objects move in very obvious discreet steeps, looks has if performance took a nose dive at that instant, but is that really performance going down or just how the idTech 4 physics were made to work? Instead of a continuous smooth movement they move in steeps?

Indeed it would About the video I knew something like that was already possible on TDM, the problem imo is the physics objects, behavior/speed and performance. And guys don't take me wrong, TDM being a Thief homage, I don't think should go crazy on physics, I just think that with a better physics engine, some doors would open to make some cool physics based stuff, in or outside the TDM/Thief lore. Would be cool if possible but I know you can't just swap the physics engine there's a bunch of work involved, this is just a "what if" .

The physics engine is open source (MIT licence) and it seems it was used on a AAA game already see here. https://github.com/jrouwe/JoltPhysics I can only dream that some day this may happen to some idtech4 based engine. So much cool physics based gameplay would be possible in that case. A small glimpse at what perhaps some TDM traps could look with a better physics engine, thou I do think some of the traps in the video bellow aren't suited for TDM and or are already possible with current TDM physics. https://www.moddb.com/games/shadwen/videos/video-2

They took their sweet time, AMD has done that years ago but is better late then never.

Personally, if editing original Doom 3 code, I always put my code between #ifdef macros, just like the D3xp team did and I think is a good idea, in that way, I can immediately know it is my code later (blame my self not idSoftware) or disable my edits, if necessary, for debugging or something.

For TDM programmers and people that know how to edit and compile the engine.