Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by stgatilov

  1. 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
  2. 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
  3. I added Scale. And now Rotate can apply arbitrary non-singular linear transform to the model if you specify the flag. Attached the pieces of code for .h and .cpp files. Could you check the code, please? Hope it helps. tracemodel.cpp.txt tracemodel.h.txt
  4. To be honest, don't understand the problem... If you want to scale it by constant factor C isotropically then you can multiply everything with coordinate and scale sense by C and do nothing with things like normals. To my mind it should work correct. The anisotropic scale is a bit worse. If you scale each vector (x,y,z) by factor (Cx, Cy, Cz), then each normal (Nx, Ny, Nz) should transform into (Nx/Cx, Ny/Cy, Nz/Cz). If there is a plane, then its normal is transformed as stated and its distance is not changed. Just remember to change it when you renormalize the normal (it does not have unit length no more). In general case: there is a plane with equation in homogenous coordinates in form (Nx, Ny, Nz, d) dot (x, y, z, 1) = 0. You want to transform the world by multiplying it on the 4x4 matrix A. It is well known from shader programming (applying modelview transformation to normals) that the "plane vector" must be multiplied by inverse of transpose of A. So the new plane parameters are (A^{-1})^T * (Nx, Ny, Nz, d). The correctness can be checked by noticing that dot product of transformed plane vector on transformed point vector remains the same. Notice that combined rotation, translation and arbitrary scaling are included in this case. I hope that I'm not mistaken about the formulas above If you find a way to change all the coordinate parameters, then the formulas how to change them are indeed obtainable.
  5. Here is that concept video I think (TDMroperide on 2008-09-25 from shadowdarkkeep): TDMroperide
  6. Crazy mission! It is like "TDM defrag". I remember seeing the Komag's concept videos of riding on the moving rope in TDM a long time ago. Perhaps even before TDM was released. I never thought these concept demos would make it into a fan mission Can anyone explain how to swing while on the rope? Also there are a few things that were a bit disappointing. Just a few things...
  7. I added a page on wiki: http://wiki.thedarkmod.com/index.php?title=DarkMod_and_Doom3_linkage By the way: Am I right that idClass and all derived classes are used only inside "gamex86.dll" ?
  8. Do you mean that clues will be automatically added to the diary? That would definitely help a lot. When playing this FM I took pen and paper after hour of playing . I wrote the most important clues down on the paper. But I didn't track the plot details. Some of the original thief games allows to make marks/notes on the map - it is really cool. This way I can track on the map visited/unvisited places, hints about locked doors etc. Is it possible currently in TDM? Was this idea discussed?
  9. To be honest I was away from playing thief/TDM missions for quite a time... When I decided to take some FM I was afraid that it would quickly bore me. But this FM simply can't bore anyone! Very absorbing gameplay - all the best thiefy nuances! Huge mansion, hidden passages, a lot of good old secrets to find, myriad of readables... The deeply designed storyline. I understand the most of it now, but I am sure that not everything (And the fact that I'm not English native speaker makes understanding even harder. I'm used to this problem but reading hand-written English text turned out to be surprisingly difficult...). The possibilities of TDM engine which are rarely necessary in normal gameplay were used - frobbing bodies and manipulating objects are required by objectives.
  10. No, I have another problem. I play TDM at 800x600 fullscreen but want to take high-res screenshot. I have added bind "F11" "screenshot 3840 2400" to cfg. The resulting screenshot images are indeed 3840 x 2400 but only a small part of them (left-bottom corner) is rendered. The rest of screenshot is black. Do I miss anything? EDIT: Does this way of taking screenshots require resolution support by the monitor? Does Doom3 changes resolution, takes screenshot, changes it back? Or Doom3 just sets buffer for the specified resolution and renders it without messing with monitor?
  11. I tried to take high resolution screenshots, but it does not work. The images have the specified size indeed, but the renderview is still cropped to screen resolution. Does it work when fullscreen?
  12. I'd be happy to download the SVN version after greebo strips out editor spawnargs! I'm curious how small the saves will be and how fast save/load will work
  13. Just cut that leEEEengthy editor_* args. Even without compression saving/loading will become mush faster and will take much less space. I think that hunting duplicates is superfluous. Even compression may turn out to be unnecessary after editor data is stripped. By the way, did you consider opening read-only SVN access to public? Or it it is too dangerous? Some crazy people may try SVN builds... And sending patches will be easier. Though I think not many guys want use SVN builds and send patches...
  14. It can't allocate contiguous region in virtual address space. Maybe make buffer non-contigous?... Or I need to code buffered compressor stream? And the same decompressor stream. Or maybe it's better to include some C++ zlib wrapper (like gzstream)? Or even better: I've just found that there are boost zlib streams. But in case of streamed compression the file structure would become more complex. The compressed data will be interleaved with non-compressed data (which is closed-source). Hmm... What's the problem here?
  15. How big is your swap file, how much RAM do you have and how much memory is used by Doom3 process? It sounds a shame that it failed to allocate 128MB I can't believe it... Can you please tell me exact steps... exact name of mission maybe?... HNAT is No Honor Among Thieves? Mission 2?
  16. That's possible... There is no flushing now. I decided not to mess with zlib internals. So all the data is written to that buffer and compressed afterwards. And the previous version (with pipe) behaved the same way. Maybe some realloc error.
  17. OK, I added cvar tdm_savegame_compress. Now everything seems to work... We can start testing! Here are the files changed (against clean 1.03 source): http://www.mediafire.com/?mu4q71gmtt8rcvv
  18. An important question: I think there'll be a setting for whether to compress save or not (since uncompressed files are less prone to errors and are easier to study). Should I make game loading compatible with both variants? On SaveGame the saves compression is regulated by some options. On RestoreGame the save should be loaded regardless of any settings. Am I right? If so, I'd add 'compressed' flag Now BuildNumber and CodeRevision are not compressed since they are important.
  19. You cannot do it. idRenderModel implementation is closed. Therefore you can only call its virtual methods. Constructor cannot be virtual hence you cannot construct it (linker error). To create closed-source object you have to call virtual factory function of another closed-source object (like OpenFileRead). And it will create the object you need inside Doom3.exe. Destructor is virtual. so it will call deallocation in Doom3.exe module as well. As you see, all the objects with closed source are black boxes for us. We cannot construct them, we can only call virtual methods for pointers we get. The problem appears when we pass objects between modules for which we have source. For example idLib containers (idStr, idList etc). We must be sure that no allocation/deallocation can cross the module boundary. By the way, I noticed that idDict::Clear and idDict::Set takes a lot of CPU time on loading. Maybe I'll write some internal saving/loading for them. That's not for me. I prefer ollydbg to IDA since the first loading
  20. To be honest, it is rather difficult to catch this bug unless you do something bad. The closed part of code is mostly isolated from gamex86. The only thing you should never do is: call idFile->ReadString . I guess this is the reason why idRestoreGame::ReadString does not call it. I think it's better to state it all in wiki? Several heaps, communication with closed part only with virtual functions and the like. Now I think about reverting back to greebo's idea. I added debug output in saving process to know what parts of code write the most. Only 300Kb is written before idSaveGame::Close. It means that 99.6% of save consists of object data. All the objects call methods of idSaveGame and idRestoreGame which are opened. So I just need to rewrite their methods . Most of the data will be stored to buffer inside idSaveGame. The closed part of code will write their data uncompressed straight to the file. After everything is done, the cache would be compressed and dumped into save. No OS-specific things, no hacks, no heap mess. Great! The only thing I cannot understand now is what eats time in save/load process. Writing 86Mb to hard drive is much faster that the whole saving process if done in one operation. I hope that when I rewrite SaveGame/RestoreGame everything will become clearer...
  21. Yeah... ID decided not to expose their memory allocation to DLL. And finding virtual functions which allocate memory it also a problem. The only approach I can think of is to create a temporary file with some garbage and call idFile::ReadString routine to allocate memory for idStr . Crazy. Each instance of CRT in Visual C++ allocates memory in its own windows heap. It should be easy to find that heap for Doom3 and allocate memory from it. Can't find similar info for unix, probably C runtime uses global process heap there. Anyway it gets dirty. Also I think it is not possible to avoid writing idSoundWorld to savegame. Ok, then I'll continue trying OS-specific things. The pipes are already working now, but I don't like the code: it is cumbersome and error-prone (a lot of WinAPI calls, threads...). It would be great to find some windows equivalent to /dev/shm if it exists. Any ideas? I'll try to play with FILE_ATTRIBUTE_TEMPORARY flag. Also I think about taking FILE* object from idFile_Permanent and using windows-specific things with it (like getting HANDLE).
  22. Here is the code. int CIDFileFrontend::ReadString(idStr &string) { string.Empty(); int len = 0; int res = ReadInt(len); if (res < sizeof(len)) return res; string.Fill('@', len); res += Read(&string[0], len); return res; } Yes, you are right. it calls gamex86's idLib functions to allocate memory. Regarding symbols: we have NO symbols about Doom3.exe at all as far as I know. All the coordination relies on virtual function calls which are not crashing because 1. declarations are identical hence vtables are identical 2. each object uses pointer to vtable stored in itself to understand where the function is. And the virtual functions are always prepared for call from outside. Each non-virtual function is uncallable, because: 1. We don't know its address 2. It could be optimized (even if not marked as inline). Calling it requires hacking each executable separately, writing asm helpers and bad stuff like this. I'm trying to get access to Doom3.exe's heap. Maybe I can call some virtual function which creates proper memory and set this buffer to the idStr read.
  23. Now I'm sure about the problem. In idGameLocal::RestoreGame the ONLY place where idStrs are loaded is a call to savegame.RestoreObjects(); This call in turn calls idRestoreGame::ReadSoundCommands() which redirects the flow to closed part of engine with gameSoundWorld->ReadFromSaveGame( file ); That closed part of engine starts reading strings (I suppose names of sound files). The first string does not cause any problem since it has len<32 and is allocated in idStr::baseBuffer inside idStr object. The second string like "sounds/lights/light_flicker.wav" has length=33 and is allocated by my piece of code (CIDFileFrontend::ReadString) in gamex86's idHeap string allocator's memory. Then everything goes smooth. When game shutdowns, Doom3's part of code tries to deallocate the first idStr which was allocated inside gamex86. Address of its buffer is equal to the address of that light_flicker allocated string buffer I mentioned. Since it was already deallocated when gamex86 was detached, we get a crash. Is it possible to find workaround?... I'm afraid that if I load that save and continue playing for a long time Doom3 will try to deallocate that string and I'll get that crash, but not during shutdown. This error is critical. What does gameSoundWorld->ReadFromSaveGame do?
  24. There is idFile::ReadString(idStr &string) which has to change idStr. In version 1.03 all the strings from Doom3 are read by idFile routines. And all the strings from TDM are read by idSaveGame::ReadString that uses gamex86.dll heap. Since now I try implement idFile replace, there are calls from Doom3.exe to CIDFileFrontend::ReadString. I commented the commands that change idStr in ReadString, that does not help... So that may be wrong guess. EDIT: forgot to rebuild...
  25. No, my changes cause the problem. The bad quicksave is properly loaded by 1.03 without any problem, but loading it in my version causes bad shutdown. If idLibs are different, we cannot edit idStr object which was created in another module?... Because Doom3 alloced string with its own string allocator, then we try to change the string and get deallocation + allocation in gamex86.dll. And when Doom3 shutdowns, the string buffer is deallocated by Doom3.exe. Seems like two improper deallocations. I'll try commenting WriteString and ReadString to see if they cause the trouble. Thanks for help! Now I don't feel that lost...
  • Create New...