stgatilov

It seems that the code is already in SVN. So who is going to implement the safe switch? I mean: the cvar which would make everything sequental?

Yes, exactly. The separation into f.e.geo and b.e.geo may be not necessary for non-threaded version, but it should not make any harm. I think we must have is a simple switch which quickly reverts the game to sequental version. This is very important in case someone meets some race conditions / driver incompatibilities / whatever. Glew is great for small and fast projects, because you don't need to waste time on adding stuff manually. But Doom 3 engine already has some paradigm of supporting GL extensions, what's the problem with it?

Nobody talks about putting every line from the diff into "if". Most likely, there is only one place really which makes everything work in parallel. The idea is to commit common changes (like structs changes) as is, but provide a switch that makes everything run sequentally if requested.

When ROQ video is played, the whole texture is sent from CPU to GPU each frame. This is OK for FMV, but if you start putting it all over the level, performance would suffer, I guess. I don't know how easy it is to share the same video across several objects/materials, and how easy it is to avoid video decoding/uploading if the player does not see the material from his area...

I am pretty sure that rewriting vertex cache to BFG style would improve performance a lot. We had discussion about it on dev forum recently. The current way of creating new vertex buffer for each animated mesh each frame (in random order) is just a mess. The way BFG does it (single huge vertex buffer mapped + manual double buffering) seems like one of the proper ways to do vertex streaming in OpenGL. Most likely, it is this bug, already fixed in SVN version.

I think we should remove this linuxBuild.sh. I did not update it after last changes. I have no idea why is it needed at all, given that scons file can run any python code itself. Please build TDM by invoking scons directly. Simply go into source directory, and run "scons" or "scons --help". UPDATE: This command should work: scons BUILD="release"

I don't like that you are talking about performance of rendering as a binary thing: engine either renders an object or not. It is much more complex. Aside from draw calls (which are very important), there are other things involved. For instance, pixel fill rate (think about pixels you have to fill with data) and other read/writes to memory. Also, the complexity of the per-pixel visual effects (which are done in pixel = fragment shaders). So it is all more complicated: the engine is big, and it is very hard to fully understand all the performance details. First I'll try to correct some misunderstanding here (well, at least I think so): An entity cannot be culled out only because it is occluded by some set of entities. So if there is a candle behind a crate (or several crates) in a room, the candle will be rendered regardless of crates presence. In my opinion, there is no efficient way to check that the candle is fully behind a crate or a barrel, that's why I think so. Quake 1 really has software renderer with zero overdraw, but Doom 3 renderer does not have. If engine renders several surfaces which are located on the same place on the screen (and thus occlude each other), then even occluded pixels would take some time to render. However, Doom 3 performs "early depth pass": it renders all the geometry without any lighting/coloring/texturing at the very beginning of the frame to produce depth map. After that it renders everything again, but all the complex math for lighting/texturing (i.e. fragment shader) is done only for the pixels which are actually visible and not occluded by anything. For the pixels which are occluded, only depth calculation and comparison is done (which is much cheaper than full rendering). So you pay for visible pixels, and pay much less for occluded pixels.As you see, the only way to not pay for triangles and draw calls is to cull the surface completely in frontend. This is what I'll try to explain now: let's go back to portals culling. Let's call arbitrary convex polygon on screen "winding". For instance, every portal that you see with r_showPortals is rectangular, and its winding (which is a 2D thing) is a 4-gon. Every area can be seen by player through a sequence of portals (let's call it "portal path"). For the area where the player is located there are zero portals in this sequence. Given a portal path, you can intersect the windings of its portals, and you'll get a polygonal winding through which you see the area at the end of the path. For instance, on this picture the outside area is visible through two portals, which together yield 5-gonal winding (marked by orange color): Now the main rules are: If the windings of the portal path have empty intersection, then it is culled out. if one of the portals is sealed (maybe closed door), then the portal path is culled out.If all portal paths leading to an area are culled out, then it is not rendered and you don't pay for it. If there is a single remaining portal path into an area, then its winding (recall that it is intersection of path's portals) is used to cull out the entities in the area: if an entity's bounding box is not visible through the winding, then entity is not rendered (so you do not pay for it). If there are several portal paths leading into an area, an entity is drawn only if its bbox gets into at least one winding (I think so). Unfortunately, I cannot say how the winding of the portal path affects the world geometry, but I can imagine that surfaces (sorry, I don't know if "surface" is a known concept/term in DR) which are surely not visible through the winding are culled out too. This is not over yet. There is also an OpenGL thing called "scissor test", which allows to skip rendering of pixels outside of a specified (axis-aligned) rectangle on the screen. Doom3 uses it heavily: when rendering an area, it sets scissor rectangle to be minimal rectangle bounding the windings of all the portal paths leading to the area (usually one portal path leads to an area, but not always). As you see, even portals which can be seen through by player (drawn as green when you enable r_showPortals) can help a lot with culling. Note that the description above explains the final effect of portals culling, but does not exactly describe how the implementation works internally. Also, I think that the overhead introduced by portals is pretty low: you should not be afraid that setting 2x more portals would waste CPU time (I suppose so). Note that there are also shadows, which are culled by different code. For each shadow-casting light, a similar procedure is started from the light itself. It does not matter whether portal is sealed or not here. The algorithm for culling by portal path seems to be completely different in this case, but it also takes into account the fact that even visible portals limit the range through which the light goes. Having said all that, I'd like to ask a question: has anyone seen a case when adding a portal (or several portals) seriously reduces performance?

3.0 Ghz against 3.5 Ghz means roughly -14% performance. But you have to keep in mind that if only one or two cores are busy, then Ryzen goes into boost-mode, and works on increased frequency. Look at some reviews. They mension that boost frequency of Ryzen 1700 vs Ryzen 1800X is 3.7 Ghz vs 4.0 Ghz, which isn't much. Also, there are plenty of single-threaded benchmarks (including games) on the net, where you can compare different Ryzen CPUs. Of course, not every program can make more than six threads working simultaneously, so your +33% boost from two additional cores won't have effect most of the time. I have bought Ryzen 1600 recently. I was considering Ryzen 1500X too, but it's increased single-core performance seems too low for me. Moreover, I have read many times that Ryzens without 'X' can often be overclocked to almost the same frequency, although no guarantee here and it depends on luck. In fact, I often compile TDM using my home computer, and having 6 cores against 4 cores for me means almost +50% compilation speed P.S. And when looking at benchmarks, remember that 80 FPS vs 75 FPS is not a major difference

Sorry, but I forgot about this Anyway, now Linux version builds an runs on both 32-bit and 64-bit Linux. I do some basic testing of it in 64-bit Linux VM. Feel free to play with it

Ok. Just... not yet I imagine that the right answer is: an any Linux, given some skill On 32-bit Linux it might be easier, on 64-bit Linux it is a bit harder now (but hopefully it would change in 2.06). As for Linux-Windows comparison, it is common knowledge by now that Linux native TDM is slower. But, once again, I hope this difference would go away in 2.06

In order to generate debug information for Release build: 1. Right-click on every project -> settings, ensure that Release configuration is selected. 2. Click the C/C++ node. Set Debug Information Format to Program Database (/Zi) 3. Expand Linker and click the General node. Set Enable Incremental Linking to No (/INCREMENTAL:NO). 4. Select the Debugging node. Set Generate Debug Info to Yes (/DEBUG). Rebuild everything and you should have gemex86.pdb file generated, so you can now debug in the source code. If you succeed, then "Binary was not built with debug information" message should not be printed for gamex86.dll. However, debugging Debug configuration is MUCH easier, because it is not optimized. When debugging a release build in MSVC2010, you can only see current call stack and approximate place where error happened. Perhaps you would be able to see values of some variables, but often devenv simply shows some trash instead of real values. Release build is not intended to be debugged, so you would have more problems with it. I suggest trying to fix Debug build, although most likely you need onsite help (it would be much faster that posting on forum). As for the error ("Access violation reading location 0x00000000"), it is not a hard problem This is caused by accessing (dereferencing) a NULL pointer. It leads to immediate crash, so unless you fix it, you cannot even see another issues (if there are any). This type of error happens often. It is not the dreaded "Heap corruption" problem, don't worry

I think using MSVC debugger is your best bet. There are several cases: When you load, it stops immediately somewhere and says that error happened. When you load, nothing happens, but you can pause execution (Debug -> Break All) and it seems to do it. When you load, MSVC simply hangs and stops responding.I hope you have one of the first two. Then find Call Stack (Debug -> Windows -> Call Stack if you don't see it already). There you would see list of nested functions called currently + you can see the point of execution in the code. You can probably attach a screenshot of it, if it is hard to comprehend it for you. If you see no functions from Doom3 and your mod there, then it gets harder. You might want to look at threads (Debug -> Windows -> Threads). There is a possibility that everything silently hangs with deadlock, although I heavily doubt you could get a deadlock without messing with multithreading yourself. When using MSVC, be sure to build and run Debug configuration: this make everything slow, but increases your chances to see the error early. Use some VCS really! You are going to have a lot of trouble without it. If you have a single-man project, you might want to use hg/git (hg is much easier to use, but git is much more popular). I think even creating a local SVN repo is not very hard. Perhaps you have forgotten to save something. Or you have changed saving without changing loading appropriately or vise versa Overall, I think you would need a help from coder. Maybe you should prepare for a remote session (TeamViewer).

Ok, already found one tester I think it is enough.

We have some internal changes happening in the TDM source code now. As a result of these changes, Linux build is not working in the latest SVN version. This is not appropriate of course The idea is to fix Linux build incrementally, step by step. But the problem is: I have only 64-bit Linux in virtual machine, and it cannot run TDM there. I would be very grateful if some Linux geeky player could help me with testing the builds. In order to do this, you need: Real Linux OS installed (i.e. not in VM) Running native Linux build of TDM Some skill to build TDM (I think this point follows from the previous one) Basic SVN skills Unlimited internet access The last point is needed because testing should be done against uncompressed assets (instead of pk4 archives). Note that I would fix compilation problems myself, so C++/programming skills are not necessary If you can help, please let me know.

I like Python, so Scons does not look bad to me. CMake is of course great too. The main problem is not the build tool itself, but the sheer amount of stuff put into the scons files. CMake files of same size would be equally problematic. If we rewrite build system from ground zero, we may easily lose something... That's why I hope that the build problem can be solved incrementally. P.S. Also, with each step moving build system further from Doom3 original one, less information on the internet remains helpful in case of trouble.

Setting password in ZIP file actually means encryption. No decompression software can unzip your password-protected file without properly entered password. Any DRM is breakable, unless it turns a single-player game into an always-online game. So DRM is by definition "security by obscurity", and usually most of this "obscurity" comes from the fact that source code is closed.If TDM distributes password-protected pk4, then it also has to know the password in order to load it, at which moment it can be easily learned by everyone.Of course, there are several options here:Always use fixed password, e.g. "alpine": then everyone would know it after a month or so, and it would have no effect. Use different password for each mission. Looking at the source code, it is relatively easy to find the place where password is passed. After that, anyone can get the password by setting a breakpoint (if they want to). If it is passed over network, it can be sniffed in the network traffic (setting a breakpoint is much easier).As coder myself, I would not waste my time on adding passwords, because I think it is useless. Also I fear that it can generate conflicts in future. If you want to protect pk4 from inspection by ordinary player, the sole fact that it has extension "PK4" instead of "ZIP" should be enough to stop a lot of people from looking inside. Speaking of licenses. I think adding a license is the only proper way of protecting your stuff, although I would prefer to have everything freely available. But there is one important point to keep in mind: you should not forbid others to modify your work! Otherwise you may harm longevity of your FM. Imagine that TDM team decides to do an important breaking change in the code. Yes, breaking changes are always avoided as much as possible, but it might be a very rare case when fixing all FMs is easier than supporting the old behavior. Suppose that TDM team cannot get in contact with you, and your mission is license/encryption-protected from modification. Then your mission would stay broken forever. At least, this point applies to materials, definitions, declarations, shaders, and other code-like files.

I think no one really looked into linux build after x64 branch merge. Some files were added, some were removed, and linux make files remained the same. I have had a feeling that they do not work for all the time from that moment... I'm afraid they "need some love" now. Here is at least the file changes since the time I joined back in April: EDIT: as for the player movement, you should start at idPhysics_Player::MovePlayer in Physics_Player.cpp, just as grayman said.It seems to be the main function for all the movement, you can reach all the other code from there.

Well, building C++ projects parallelizes pretty well. Quite often I do some small change and have to recompile whole TDM from scratch. It is not very fun to do on my Core2Duo CPU. I hope 6-code Ryzen would make it less annoying =)

A great mission overall ! The main thing I did not like: the amount of helmed guards, especially with torches. Too late I realized that they don't know how to relight their torch after a water arrow... The main thing I liked: the amount of keys and secrets in the map! I have found a bit more than half of the total loot (including gallery), and I did not find a key to only one big metal chest. I wonder how many secrets I have missed =) Also, I must admit that I got caught a lot and had to save/load like mad

This fan mission was really surprising for me! I saw zombies, skeletons, but I did not that something like this can exist in TDM... I have two questions: The musical theme: did someone really put piano in such condition? The match: what can it be used for?

From the point of high-performance computing, AMD Fusion is conceptually better than CPU + discrete GPU. It is obvious that transfer bandwidth between CPU and discrete GPU is rather slow (compared to internal memory transfers and computing power). GPGPU suffers from low transfer speed in many computational problems. Ideally, memory spaces of CPU and GPU can be merged together to make it possible for the programmer to access particular data from both CPU and GPU without any transfers at all. However: Now CPU and GPU memory spaces in APU are separate. And it is VERY difficult to utilize the fast transfers between them properly. I sincerely hope AMD will solve this problem... OpenCL is functionally cross-platform but not performance-wise. A single code can be run on all the architectures with OpenCL: Intel multicore CPU, NVIDIA GPU, AMD GPU. But it is impossible to tune the OpenCL code to work fast on all of them. For instance, fast transfers (zero-transfers / overlapping transfer + kernel execution) are implemented in completely different way on AMD and NVIDIA GPUs. Unless various performance features can be used in a simple and unified way on all architectures, they can't be widely used commercially. There is a CPU vs GPU myth that states that modern GPU is about 10-20 times faster than modern CPU in practical high-performance problems. It is far from being correct=) The actual difference is about 2-4 times. Now recall that GPGPU programming is much more difficult than CPU programming.,, AVX instruction set is replacing the old SSE set. The width of SIMD instructions is doubled => more throughput on CPU. So as you see, I do not believe in the idea of unloading all the floating point computations to GPU. To my mind, CPUs have to conserve and increase floating point computational throughput in the nearest future.

Wow! I've been told about D3 going open source today... And I see that it's for real! Now I fell morally obligated to join TDM for the upcoming Christmas:) Staying tuned with other Doom3 forks is definitely a problem. Maybe we can avoid doing heavy changes to the engine at first time? Though it'd be almost the same as working with closed engine... Anyway, setting up the infrastructure is first priority, isn't it? And refactoring the dirtiest hacks is the second. I added some of them myself:)