Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by stgatilov

  1. Do you have the file {darkmod-root-dir}/newjob/newjob.pk4 ? Of course, the {darkmod-root-dir} is the place where you installed TDM to. Anyway, if you decide to reinstall TDM please do one of the following: Install TDM not to Program Files. Basically, find some directory where you can add/edit files without UAC prompt, and install TDM there. Use installer suggested by Freyk, it contains additional workaround for setting permissions. A simpler solution would be to forbid running tdm_update with elevated rights, or forbid installing TDM to Program Files. Having TDM in Program Files is a way to shoot yourself in the foot.
  2. Everyone here, and especially people who had problems with aliased font. Could you please verify that r_useFBO is 1, and set it if it is not? I have seen cases when some errors reset it to 0, and it is never returned back.
  3. If someone suspects that packaging dropped a file, please report either a file path (like models/md5/chars/monsters/werebeast/werebeast_mesh.md5mesh) or an in-game asset path (like textures/darkmod/fogs/real_fog_layer_moving). Regarding werebeast, I see the following files with "werebeast" in their name in latest beta package (ignore the numbers): Almost all of these files are in tdm_ai_humanoid_beasts01.pk4 archive, which is new. So check at least that it is present. If it is not, then run game and verify that you see proper svn revision in game console (that's the last number in the lower-right corner of the console). Finally, please verify that you have the following in tdm_mirrors.txt file (NOTE: latest beta is beta208-02, the last digit must be "two"): [Mirror localhost] url = http://tdmcdn.azureedge.net/beta208-02 weight = 1 Note that unlike previous betas, this time you must redownload tdm_mirrors.txt every time you want to get a new beta package. The link to this text file is given at the very first post, and I will update the underlying file every time a new beta version comes out.
  4. Please keep in mind that playing a video takes a lot of resources. You might be OK with one such video on a test scene, but if you start filling FM with them, you will have performance problems quickly. Having 10 videos is like opening 10 VLC at the same time. EDIT: Moreover, I believe I never tested more than one video playing simultaneously... ever. Given that every such playback runs on several CPU threads with synchronization, nobody knows what could happen.
  5. It is possible to compress on CPU with SSE/AVX. Uploading a texture takes time anyway, so texture streaming usually goes through some sort of async stuff like PBO, to avoid locking main thread. As far as I remember the game did not block or lag, it just showed low-resolution textures when you rotate camera (although I did not notice it when I played, perhaps I tweaked some config to avoid the issue). That's why the best idea is to start loading assets beforehand, so that you can show them in full glory when the time comes. All those delay-loading techniques will inevitably cause popping.
  6. Yeah, looking at this all is a bit sad, especially when you compare idStudio to Radiant. Although looking closer, it seems that they did not drop their old habits completely... like if some of this is still rooted in idTech4 and earlier. I wonder if this engine still uses brushes Nothing yet made me think otherwise: they can still use brushes for basic level structure, and then use it for high-level culling. They showed editing geometric detail in realtime, but it does not contradict anything. The brushes can be used only for large hard walls, but they did not show realtime editing of map layout on global scale. Why not? It is possible to start loading and decoding jpg file prematurely in background, and then drop it from memory when you are far away from it (or based on other criteria). It is of course less efficient than taking raw texture data and pushing it to GPU. And it is hard to do any LOD, since the whole image must be kept in memory.
  7. Gamma/brightness has been merged into postprocessing pipeline, which somewhat reduces the effects of gamma correction (probably to avoid overbrightening). Previously I heard that gamma = 1.2 is sort of default, so I set it as default value (with gamma = brightness = 1 the game is obviously too dark). But new gamma = 1.2 is a bit darker than old gamma = 1.2 To be honest, I came to conclusion that I should adjust gamma every time depending on circumstances. Am I playing or only testing? How strong is ambient light? Is it morning or evening in the real world? etc. Previously it was too painful to use non-default gamma, because desktop was messed up after a crash, but now everything is OK.
  8. Did you check that all values are set correctly?
  9. I guess current code integrates only with X system. Most likely there is no code to cooperate with Wayland. I'm not familiar with this side of Linux, but is it possible to somehow force using X system just like NVIDIA drivers did?
  10. If you have time to have fun, you can try to implement your own in something like Python. All those texture compression formats are so simple compared to PNG and JPG, that writing a basic converter is a one-day problem I'm afraid CPU profiling is not the right way to conduct experiments in this case. There are many things involved which you won't be able to properly measure with profiler: disk accesses, OpenGL driver work, GPU transfers, etc. I suggest doing more complicated measurements with temporarily disabling some parts in the code. I guess most of the time should be taken by texture loading, models loading, and sound loading (also covered in zip compression unless you are on SVN).
  11. TDM 2.08 uses statically linked CRT, just like 2.05 and before did. So new tdm_update does not even attempt to install VCRedist. You have old tdm_update, which for some reason does not update itself. Did you set checkbox "noselfupdate" ? (hint: you should not) Did you set checkbox "keep-mirrors" ? (hint: you should) Did you download the tdm_mirrors.txt file by the link in the original post and put it near TDM executables? (hint: you should) If you did all of this properly, then I'm afraid it might be some access issue again, like tdm_update cannot overwrite anything in its directory...
  12. As I wrote here. Changelog does not include everything. Even bugtracker does not, unfortunately.
  13. Yes, a sad problem. Perhaps I should make HRTF an in-game option and remove the ini file. It seems to be possible via OpenAL-soft extension. Although many users will still have the file locally.
  14. The engine opens all pk4 files on load, and creates an index of all files contained in it. When you actually open the file later, it just sets the offset in zip file and starts reading. So everything is OK on zip level, but of course data is read from disk in the order in which you load it, so seeking is done.This is not HDD-friendly, so SSD is very helpful. By the way, it seems to me that loading times are much longer on AMD GPU than on NVIDIA GPU. I suspect that loading textures to OpenGL is the major fraction of loading times. Forcing player to wait on TDM start is even worse than waiting on level load. The idea of loading level in background while player goes through briefing is quite hard to implement. It requires multithreading, and the engine itself does not work with it properly, so there would be plenty of bugs, some of them corrupting random stuff randomly --- very annoying, very hard to reproduce and debug. Duzenko already tried to load textures in separate thread (faster load for debug purposes), and recently we had hard time fixing random weird bugs caused by it. We had to make the whole D3 filesystem threadsafe. And there are many more systems which are not yet suitable to multithreading. Moreover, it is hard to distribute resources between loading and other engine: for instance, FFmpeg videos can be rather CPU-heavy to decode. I'm not sure that squeezing 25% of load times is worth the effort behind it. If someone really wants to invest time into it, why not. Otherwise, let's pretend they are already OK
  15. I wonder how is it done in modern games. I have an impression that developers push the loading responsibility onto artists' shoulders. Basically, they most likely put some markers where start "preload" a new bunch of textures and models. This won't help TDM because nobody will add such markers to existing missions. Another option is to load things when they are needed. This looks either like stutters when you see new places or like textures and object popping up in the view. I believe a similar problem in megatexture was a major compliant of Rage game. Anyway, I think both options are possible in TDM, but not recommended for players. Developers dedicate time to the loading times sometimes, but it is not clear how to make it much better. You are talking about 100+ missions, released by a lot of people (most of them not even being official TDM developers) over 10 years. Aside from the fact that this would take years of work, we simply cannot do it. Because every FM is an artistic creation of the author. We have no moral right to take his work and start "improving" it as we see fit. The only intervention we can do is small fixes to make mission playable if it got broken. If you are talking about 3 prepackaged missions, then yes. Surely it is possible to fix issues in them. Although I would imagine the author is already pretty annoyed maintaining them Well, in my opinion the main reason why TDM is not on Steam is the spirit of the community. The core team wants TDM to be free for everyone, free of money, and free of legal issues and entities. This contradicts the idea of working with any distribution service like Steam. It is unfair to compare TDM to System Shock 2 on the polish level. System Shock 2 has preserved to this date in its original state, with its original missions. It is as polished as it was when it was released. And before release, I'm pretty sure a team of people who made it from the ground up polished it from dawn till dusk. But TDM is constantly changing. Even if you spend all time on polishing it this year, it will go away in 5 years. While it sounds like a good idea, I am a bit afraid that this would start ranging FMs into "good" and "bad", which is not very encouraging for mappers, especially for the new ones. And mappers are the most important group of people in TDM community. Anyway, while some of issues may be easy to fix, a lot of them are actually very hard to fix. Like the frobbing system, which I think should declared "unchangeable" and never ever changed again. Or the physics of item pushed into the wall (pretty sure "fixing" to get a bit of "polish" would break some FMs). The system of "installing" FMs is not easy to remove, because I'm afraid Doom 3 engine was not intended to hot-swap its ppk4 files, and loading several FMs at the same time may lead to disaster.
  16. I hope I fixed the link.
  17. New beta build has been released. Changes are listed here. Note: You must download mirrors.txt file again using the same link to get the new version. This time even differential update should work, if you update form 2.07.
  18. It is already included in the post here:
  19. Let's continue in the new thread. This is not going to conclude soon.
  20. Here is the list of cvars which I guess should not be archived: And there are the only cvars which should remain archivable in my opinion (a lot of them are dead): idCVar cv_tdm_crouch_toggle( "tdm_toggle_crouch", "1", CVAR_GAME | CVAR_ARCHIVE | CVAR_BOOL, "Set to 1 to make crouching toggleable." ); // nbohr1more: #558 Toggle Creep idCVar cv_tdm_creep_toggle( "tdm_toggle_creep", "0", CVAR_GAME | CVAR_BOOL, "Set to 1 to make creep toggleable." ); idCVar cv_pm_lean_toggle( "pm_lean_toggle", "0", CVAR_GAME | CVAR_ARCHIVE | CVAR_BOOL, "Set to 1 to make leaning toggleable." ); idCVar cv_frob_fadetime( "tdm_frob_fadetime", "100", CVAR_GAME | CVAR_ARCHIVE | CVAR_INTEGER, "Time it takes for frob highlight effect to fade in and out." ); idCVar cv_frob_weapon_selects_weapon( "tdm_frob_weapon_selects_weapon", "0", CVAR_GAME | CVAR_BOOL, "Set to 1 to have weapons automatically selected when the respective item is picked up." ); idCVar cv_frob_debug_hud( "tdm_frob_debug_hud", "0", CVAR_GAME | CVAR_BOOL, "Set to 1 to show some frobbing info." ); idCVar cv_frob_debug_bounds( "tdm_frob_debug_bounds", "0", CVAR_GAME | CVAR_BOOL, "Set to 1 to see a visualization of the bounds that are used to check for frobable items within them." );
  21. Yes. Perhaps go through all the player-movement cvars, and write down the list of all archiving ones which may affect gameplay (stuff like head bobbing cannot, I guess). Then make them all non-archiving.
  22. It is also archivable. UPDATE: I come to conclusion that most of gameplay-related cvars should be non-archivable. Does it allow mappers to reliable modify them? Including the save/load scenario... UPDATE: That would be cool, but it does not work this way. I tried swimming against current in NHAT1 with default and zero pm_swimspeed_variation, and with variation it becomes about two times slower.
  23. It is also an open question if existing missions have a similar problem. Probably most of mappers don't use external force underwater, so their underwater sections get the same average speed. By the way, is it possible to configure average player speed underwater? I think it could be quite useful in many cases.
  24. Just had the last ordinary lecture in my university. No idea how would students study from now on: I'm afraid distance learning does not suit everyone. In one orchestra that I play in, all rehersals are already stopped. I guess the others will follow in the nearest future. On the bright side, it seems I have more free time for programming and TDM now UPDATE: On the second thought, I think it is a perfect time to replay the first Deus Ex now
  25. As I already said, the best thing to do now is to inspect this FM, so that developers could understand why this innocent-looking change is a problem for someone.
  • Create New...