stgatilov

I think the issue is about eliminating pipes from lightgem shot receiving. And using glReadPixels directly from SDK was intended as a possible solution. Right now the state is the following: Firewall issues would be fixed in 1.05 by eliminating pipes (hook WriteFile instead). This relevant code is already implemented and is working right now (in branch), but it is considered risky to ship it in 1.04. And everyone is busy testing a lot of other things EDIT: by the way using glReadPixels directly wouldn't make performance much better I think.

Wow, the code has become much more readable now! So the rewriting the ModelGenerator is a very good change from all sides. Regarding scaling it is not complete yet. Only entities without clipmodels can be scaled properly - we still don't know how to put scaled clipmodels into the engine. By the way, how often would SEED use non-shadowcasting objects? Seems that shadowcasting objects would take a lot of preprocessing time anyway. Right now I'm trying to see what exactly is so slow in FinishSurface. I still have a hope that it could be ignored if source was available

Could you share the way you watch the call graph? I've generated the call graph, but its size is so huge that any graph visualizer is slow as hell and completely useless. It must be simple to draw f.i. all vertices within distance 2/3 of single vertex, but I cannot find that simple functionality...

Do I understand you correct that you have a big array of geometry and you need to know whether it is several copies of the same array? And find the original array? Are the copies of arrays shuffled or just two equal arrays concatenated? By the way, a funny trick to determine doubled array comes to my mind: XOR everything and determine if the result is zero Far from reliable though.

I regret that TDM's engine is both cross-platform and closed source. No chance to hack it .

The patch to test. drawvert_transform.txt

Emm... Could you write what sort of info the GL tools can provide? For example what can you learn from running PerfStudio on Doom3+TDM ?

What sort of info is it? The code just looks well or it contains names (like symbols or other text hints)?

Not really I was asked how I looked Doom3 closed code. So I decided to start a thread about it. To be honest, I doubt that anyone can offer a better tool that olly, but there is some chance... Also I was interested in what tools are popular. IDA is mentioned quite often, maybe some hardcore debuggers prefer SoftICE? Also there is windbg which was a prototype for olly AFAIU...

Of course I use 2.01 alpha 1 (the latest one I think). Pure 2.0 version cannot load debug symbols, so I'd downloaded 2.01 as soon as I saw it. There is no reason to stick with older version of software like olly: It is free, it is developed by one person, it is provided "as is" and can be buggy anyway. Sticking with old version won't help you

From time to time most of coders have to dig in the Doom3 closed source. I hope it won't be necessary from the next year, but it is still viable today. I feel that most of TDM coders already know asm well, so they can use some disassembler/debugger to look through Doom3.exe. What tools/ways do you use to look Doom 3 executable? I use ollydbg2 for it. It is user-level debugger with good analyzing capabilities and convenient UI. It is capable of showing debug symbols, so I can see TDM and GL functions clearly. Also it has a lot of helpful searching routines like "search for all referenced strings" of "find references to". Of course it allows to set breakpoints on code/memory (including conditional ones), moreover it allows code patching with assembler at runtime. I've seen IDA before. IDA is very good analyzing disassembler, but it is not designed for debugging. And analyzing the code statically is much less powerful that debugging it.

I've noticed that it is too easy to dodge archers' missiles now. Just constantly running in one direction is enough for them to miss. They are expert shooters, aren't they? Why not allow them to take player's movement into account? The player will still be able to dodge missiles, but it will be more hard.

Never seen anything like this before. I run SVN version. The guard was first running somewhere in alerted state, then he walked to the ledge, looked around for a while, and then walked further. And dropped to the air. Don't know how to reproduce it, I'm afraid.

Most of the time is consumed inside Doom3 renderer and OpenGL driver. They are designed only for single-threaded work. It is a crazy idea to make them multi-threaded because they lack any synchronization. (Well, some OS-specific hacks can be used, but they are VERY buggy - I don't want to play TDM with them ). Perhaps AI calculation can be separated from rendering. But it requires redesign of the whole TDM code, I think... So unlikely it'll happen. All in all, multi-threading produces more pain than benefit.

I'm looking through "TODO:" notes around the code (cannot access bugtracker ). Noticed a strange comment related to "attach_posmod_name_*" spawnarg. And this thread is the only one which mentions it. 1. Are "attach_posmod_name_*" and "attach_pos_name_*" used? 2. Here is the piece of code in "attach_posmod_name_*" handler: // TODO: Prove mathematically that adding the angles is the same as converting // the angles to rotation matrices and multiplying them?? pPos->angleOffset += ang; I think it is wrong. EDIT: 3. Are there any other places in code where Euler angles are added instead of taking composition of rotations?

Why guessing how it works if we have the code? The lightgem render is done every k-th frame where k is the value of tdm_cg_interleave parameter. So if processing a frame without lightgem takes A time and lightgem itself takes B time, then you need A + B/k time per frame on average. The so-called "law of diminishing results" for FPS is obvious from this formula, isn't it? Of course this time per frame is average. To be strict, there are k-1 frames with A full processing time and one frame with A+B processing time. So there is indeed a small stutter every k-th frame. Do not set interleave to high values - 3-5 should be enough to lower the influence of lightgem on the average FPS. Also the interleaving depends on FPS. So interleave 10 with 60 FPS is 166 msec lag, while with 10 FPS it becomes 1 sec lag. Again: do not set high values of it and you won't have trouble. By the way, I suppose that there are a lot of important gameplay things that depend on your FPS. I'm sure that the information from this thread should be added to wiki article "Performance tweaks" even if it is unreliable because it gives noticable boost to some people (me included). The bugs of interleaved lightgem rendering are very interesting. Maybe there can be fixed? Right now I can't understand most of the problems... Maybe someone can capture the video?

How do you think, is such a behavior normal? Looks cool, but I'm not sure that it is possible to shoot bow if he handles lantern the way he does I suppose he is the archer who goes away at 2.00.

Water contest is a dangerous idea . Remember that water is not native for Doom 3. I'm afraid that mappers and players can meet bugs or just weird underwater behavior (like frobbing, mantling, projectiles speed, performance).

Well, theoretically per-entity scaling is the thing Tels is trying to implement now. But the current state of scaling is: You want to scale idTraceModel? No problem (though the code is not checked yet). Pure linear algebra exercise But Doom3 engine is not suited for colliding scaled models. And I feel that it will cause A LOT of trouble and a lot of work to understand how to push scaled models into it.

Not sure that it will work. When you reinsert the scaled model back it will likely create new collision model inside engine and return its handle to you. And what are you going to do with that integer number? As far as I understand this clip/trace/collision-model mess, things work this way: idTraceModel is just a polyhedral data. It is loaded into Doom 3 physics engine. And I suppose it is copied into Doom3 on loading and probably preprocessed. cmHandle_t is a handle to internal tracemodel object inside Doom3. It is the copy I spoke about, I suppose... Since we cannot access it in direct way, ID provided us with this magic handle that we can pass to some routines to do some cool things idClipModel looks like atomic piece of physical substance of entity. It has materials, own orientations and origin and stuff like that. Though I don't understand how these origin and orientation parameters are used. It is a bad idea to add Scale function to it because all functions like Translate and Rotate do not change the polygonal data (which is tracemodel) right now while your Scale indeed tries to change it. This object stores a handle to tracemodel (cmHandle_t). idClip - don't know what it is. Except that its Motion routine is called from rigidbody source and is redirected to the collision model manager. idPhysics coordinates all the object physics at the highest level. It stores a list of clipmodels. So if you need to change tracemodel of each entity individually, you can do something like the following. Go through links idEntity->idPhysics->idClipModel. Then get its collision model handle. Then ask that collision model manager to extract the polygonal data (idTraceModel) for you, then do whatever you want with it, then load it back to manager. And finally set the received cmHandle_t back to tracemodel. But this way number of tracemodels will increase with every new scaled entity. Not sure that it is a proper way. But it is unavoidable because the code for collision is closed and it can collide models with rotation+translation but cannot collide anything with scaling.

The matrix inversion is moved out of assert(). I often forget that release builds wipe the code inside assert out. Send unified diffs file-by-file? Well, it sounds good for small fixes. I store TDM source inside mercurial. I tried to send to greebo the whole directory patch for savegame compression produced by mercurial but some program (I guess tortoiseSVN?) didn't swallow it. By the way, there is no such concept as "patch" in SVN. The easiest solution would be to open public read-only SVN access: then everybody would be able to send proper patches. And moreover, everybody would be able to play TDM with the latest SVN build. But greebo said that SVN is not yet ready for such shock. And anticipation for major updates like 1.04 would be less then OK. It sounds like endless source of inspiration!

I played with a chair in Lady Helena's bath. When a floating object is frobbed it starts doing weird things. Sometimes it dances like mad, jumps out of the bath. That damn piece of wood has even killed me once (Yet Another Stupid Death it is)! And once I managed to grab it and it started rotating with mad velocity. I still wielded it and could move it! I tried quicksaving this game state, but after loading the chair was not moving. EDIT: caught crazy rotating chair again. This time I tried to manipulate it (rotate it myself) while it was spinning. It works strange: the chair behaves as I manipulate it about half of frames, and the other half consists of random positions. Moreover, after I release manipulate button it continues to rotate with the same crazy speed. Even collisions do not always stop its rotation. Has anyone experienced the same?

I meant simple way...I tried to check all this stuff with a chair floating in the bath That was almost useless. Though the assert must be separated from calculations indeed. I think it's better to wait until Tels checks it. Not sure about it I'm very happy to help the TDM project (and since mapping/modelling/etc doesn't sound good to me, coding is the only help I can offer). But I already have bunch of hobbies, both programming related and not. That's why I'm not sure that I'll be here on forums for long For example I haven't run TDM for a year before now. So I'll better remain in shadows. But if there are not urgent coding tasks (especially which do not require understanding and treating a lot of TDM code), I'll gladly try to handle them! Just don't want to disappoint anyone who counts on me. By the way, a few questions about LODE possibilities: if LODE places objects with clipmodels, is it guaranteed that they do not intersect? Is it possible to place objects on a complex terrain (not just plane)? And finally: can LODE generate the terrain itself? tracemodel.cpp.txt

Sorry, forgot to renormalize normal in Rotate... Here is the new version. By the way, is there any simple way to check correctness of this code? tracemodel.cpp.txt