Search the Community

Uff... hard-coded "magic numbers" like this always make me uneasy.

I would like to download the source code and play around with it. The source code compilation procedures shows in a pic that the source code must be next to the installed game. I was wondering if we can only play around with the source code with the game installed as well or can we directly run the game from the source code? Thank you

I'm trying to compile TDM from source, to explore the engine for total conversion projects. But my hardware is a bit old, and the versions 2.08+ run into this black-menu issue (my gfx card is an ATI Radeon HD 4870, and the proposed solutions don't work), so I have to stick with older versions. So I tried compiling version 2.07, but it failed to compile. I'm not experienced with Visual Studio, so I'm not sure what to do. I get errors like this one: I tried right-clicking the solution and selecting "retarget solution", but it didn't fix it. I'm still getting the same errors. I'm not sure how to install the build tools says it requires. I'm on Windows 7 (x64), using VS 2017, so I'm not even sure I could use these build tools. Version 2.10 compiles fine, though, but I don't suppose there's something in the code I could easily switch off to make it run on my hardware.

My wonderful screenshots seem to be a bit obscured by the lightgem! I enjoy noclipping and flying up high or wherever and taking interesting pix of the maps from different angles.

New here. I'm a data analyst by trade (sql, etc), but dabble in game dev stuff in my spare time. So, I'm def not a developer. Hence my question may sound dumb to seasoned devs... I dl'ed the Dark Mod source, and just scanned through some of it, mainly seeing if I could help tweak, optimize or help on the GLSL. (I worked on an HLSL mod for a game, so spent a lot of time learning shaders and tweaking them.) I looked at some of the .h and .cpp files, though, and noticed some redundant calculations... EG: In the /renderer/MegaTexture.cpp, there's several functions that have things like this... (I copied this from the "GenerateMegaMipMaps" func)... // mip map the new pixels for ( int yyy = 0 ; yyy < TILE_SIZE / 2 ; yyy++ ) { for ( int xxx = 0 ; xxx < TILE_SIZE / 2 ; xxx++ ) { byte *in = &oldBlock[ ( yyy * 2 * TILE_SIZE + xxx * 2 ) * 4 ]; byte *out = &newBlock[ ( ( ( TILE_SIZE/2 * yy ) + yyy ) * TILE_SIZE + ( TILE_SIZE/2 * xx ) + xxx ) * 4 ]; out[0] = ( in[0] + in[4] + in[0+TILE_SIZE*4] + in[4+TILE_SIZE*4] ) >> 2; out[1] = ( in[1] + in[5] + in[1+TILE_SIZE*4] + in[5+TILE_SIZE*4] ) >> 2; out[2] = ( in[2] + in[6] + in[2+TILE_SIZE*4] + in[6+TILE_SIZE*4] ) >> 2; out[3] = ( in[3] + in[7] + in[3+TILE_SIZE*4] + in[7+TILE_SIZE*4] ) >> 2; } } I'm a noob at understanding the optimizations compilers do.. In working with java & python, I'm pretty sure when calculations are done in a loop call, the compiler is smart enough to calculate something once. (So, I'm pretty sure a C-compiler is smart enough to do that, too). IE: the TILE_SIZE / 2 in the "for" statements will get calculated once, not each time the loops loop and the statement is evaluated. (I may be wrong, though. I'm projecting my experience from java / python after I ran tests when coding various projects. I've never done C++ development, so unsure how the C++ compiler would function.) But, in the body of the code after the 2nd "for", the TILE_SIZE/2 is calculated 2 more times on the byte out. So, pre-calc once for the first "for" to use over and over. Another time (?) for the next "for" to use over and over, then 2 more times in the body each time the 2nd for loop runs. And, I'm assuming each time that block is ran, it's calculating those 2 calc's each time. Also have TILE_SIZE * 4 calculating 8 times in the body, which, if those are re-calculated each time that block of code runs, would be a lot of redundant calculation. Does the compiler notice this, and optimize it down to a single one-time pre-calculation, or is it actually calculating this stuff over and over? I guess I'm wondering if a variable should get declared, and the TILE_SIZE * 8 and the TILE_SIZE / 2 should get calculated once and used wherever those parts are. Maybe it's written the way it is, b/c it's a case of losing precision due to floating point error? (IE: creating a var would "round" the result and create erroneous results, which is why the calculation is done each time it's needed?) I don't know. I'm a nub on that, too.. but from doing shader work, I learned that sometimes it's better to let a redundant calc run multiple times to avoid precision error. I'm not even sure if the code is being used.. but I was just looking at various files, and noticed some had redundant calcs. I was wondering if this was something I could tweak and submit changes for? Coming from the shader side of things, there's the push to reduce calculations as much as possible to prevent shaders from bogging down the FPS. IE: reduce instruction set use, use intrinsic functions, move as much stuff to vertex side instead of pixel/fragment. Having some redundant calculations in a global var the game engine calc's once before piping to shaders or something doesn't make any impact. But, having a shader-like function called many times to generate vertex / pixel could create performance impact with redundant calc's.

Over some time i been working on adding these changes to stock Doom3 both because it is nice to have a profiler for hunting down bottlenecks (for future modders) and the smp changes help with higher res monitors and also help a bit on some more resource heavy maps. Some time back i had actually added the smp changes but i lost the work in a github crash and im having trouble re adding it as some of the code lacks commenting so it is a bit hard to figure out which parts need to change. So anyone with some time to share is welcome to point out which parts i need to complete it. Im using a heavily modified MHDoom as a base with a working hybrid ARB/GLSL backend (took me years to perfect it...)

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.

How to reproduce: 1. Delete "tdm_fonts01.pk4" 2. Run the game in a terminal. Result: signal caught: Segmentation fault About to exit with code 0 Also these errors are printed to stdout, where it should be stderr. This is relevant because if the game crashes it cannot properly report that to a parent process. Such parent is needed, for example, for running the game with a single installation for all users on an Unix system.

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

Been scouring the net for an active community for doom3 and this was the most active outside of github source codes... so I figured it might be worth a shot. Looking to see if there is anyone who can give me a hand fixing up the thirdperson cross hair for Doom 3 Ruiner. There are 2 bugs in it. I'm hoping to get a fix included for the upcoming, and long overdue, patch for the mod. This is probably the biggest bug in the mod. The first bug is from the trace line made to determine the cross hair's position. When playing the mod, type g_debugweapon 1 in the console to show the line used to determine the position and also for the melee combat related additions. When something gets in the way of the line, the cross hair won't update. This is easily duplicated by standing next to a wall or door way and just shooting. I have a hunch the issue is mainly caused by the shoulder camera offsetting the camera. Maybe being able to offset the origin of the line to the right would help? The other bug deals with launching projectiles from the barrel. When set to 1, the cross hair is always off. to counter act it an offset can be set in the cursor.gui It works alright, but will still be off when looking too high or low because of the weapons barrel position. The only thing I can think of is maybe a flag in the projectiles fired to aim towards it... which could look wierd unless the crosshair position is offset right in the cursor.gui. Any help would be really appreciated! We uploaded the source code for the mods years ago on the mod db. https://www.moddb.com/mods/ruiner/downloads/ruiner-hardqore-2-source-codes The crosshair is handled in the player cursor.cpp

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?