Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Content Count

    2606
  • Joined

  • Last visited

  • Days Won

    41

stgatilov last won the day on March 21

stgatilov had the most liked content!

Community Reputation

723 Legendary

About stgatilov

  • Rank
    Lead Programmer
  • Birthday 08/26/1989

Contact Methods

  • Website URL
    http://dirtyhandscoding.github.io
  • Jabber
    stgatilov@gmail.com

Profile Information

  • Gender
    Male
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. See p.2 and p.3 in the Mapping section of changelog, they provide a link to wiki. Ok. If someone can reliably reproduce the problem with fonts, please provide darkmod.cfg and exact steps.
  2. Hmm... you cannot imagine how much software works on OpenGL. As for now, all those vendors would more likely drop support for Vulkan, calling it a "failure", than drop support for OpenGL
  3. beta208-03 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update. Otherwise you will not get the new beta release and will stay on beta208-02 instead.
  4. It is also worth trying r_cinematic_legacyRoq 1 --- that would enable original Doom 3 code for ROQ playback, instead of FFmpeg. To be honest, I regret now that I finished FFmpeg playback. It was probably a better idea either to extend ROQ or to take some particular format like ogg+vorbis+theora and support them by using official libraries from Xiph.org instead of FFmpeg. Or mkv+webm+opus, which is another free combo. Now the djinn is out of the bottle, and FFmpeg will stay with us forever.
  5. No, it is not locked at 60 FPS, it is bounded below at 60 FPS. Higher-FPS physics are allowed, since otherwise the game would not run smooth on high-FPS monitor.
  6. 1 millisecond is way tooo small! It should be something like 500 ms, or otherwise there must be some proper handling for timeout
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. Did you check that all values are set correctly?
  15. 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?
×
×
  • Create New...