Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6740
  • Joined

  • Last visited

  • Days Won

    231

Everything posted by stgatilov

  1. As far as I remember, it is autoexec.cfg.
  2. If it is not hard, please find where it started. If that's dev16330-9508, then it most likely means that your CPU was not able to keep up with game modelling. Game tic models 16 ms of gameplay time (slightly more on uncapped FPS). If your CPU spends more time for modelling a tic, then game enters so-called "spiral of death", and FPS quickly falls down to zero. The engine has some hard limit however, something like 10 tics per frame, which stops the spiral, slowing down gameplay instead. But if the limit is really 10 ticks, then this stop should be somewhere at less than 6 FPS.
  3. Did it start from dev16330-9508 ?
  4. Some notes about the main algorithm. Pixel values [0..255] are treated as float values [0..1] (standard thing in image processing). The 8 values which can be selected from are called "ramp points". When min/max ramp points are determined, all the other ramp points are computed by formula and rounded to the nearest integer (see GetRmp1, _bFixedRamp is true in our case). Then all input pixel values are encoded as the closest ramp value (see Clstr1). If several candidates are best, then it's hard to say which one is chosen due to numeric errors from dividing by 255. The format supports two orders of min/max ramp values (see here). The auxilliary one always has 0 and 255 values. That's good for alpha in transparency, but seems pointless for normal maps. Still, the compressonator's algorithm tries both ways and chooses the one which is better (see CCodec_DXTC::CompressAlphaBlock). Now, the hardest part is selecting min/max ramp points, and it is far from simple (see CompBlock1). It includes some search when max-min is greater than 48, plus some "refinement" trying to minimize error while ignoring rounding. I won't be able to reproduce this, that's for sure. However, there is also a setting for compression speed, and if you set it to fast or super fast, then different code is used instead of all the stuff described above (see DXTCV11CompressAlphaBlock). For some reason, it is disabled under Windows. There is also good explanation at the beginning of dxtc_v11_compress.c file. This is much less arcane, although there are still several hardcoded candidates for min/max ramp points (it tries to add plus/minus one to them).
  5. I looked in compressonator, it uses box filter (CMP_GenerateMipLevelF in cmp_boxfilter.cpp) : for (int i = 0; i < 4; i++) *pDst++ = (c1[i] + c2[i] + c3[i] + c4[i]) / T(4.f); with rounding down. By the way, given that c1[i], c2[i], c3[i], c3[i] and T are all unsigned char, which this code does not overflow? Note that this is not "blur", this is averaging of 2x2 blocks. This is not even arbitrary resize, where old texels and new texels interact in arbitrary way.
  6. You can go to https://haveibeenpwned.com/ and check your email/account. If credentials leaked from some websites, check if they had the same or very similar password to leaked one.
  7. And... what is meant by "disable new highlight" ? Given that old frob stages will be gone soon (btw, maybe good time to do it already?), what will be left if you disable outline?
  8. Yes, it should not be a problem.
  9. I have alternative proposal. It seems that RGTC compression algorithms are trivial. I'll check up the algorithm in compressonator. If it is really that simple, then I'll implement SIMD-accelerated compressor RGBA8 -> RGTC on CPU. After that we can compress textures in memory during load like we do now, but 1) it will be done same way regardless of driver, 2) it will be fast regardless of driver, 3) it can be moved from main thread to worker threads which we already have for loading TGA, making it parallel to uploading data to OpenGL. It seems such approach allows to avoid the whole "compress everything" story and leave assets as they are. It also allows using uncompressed normal maps (although large missions won't boot in such case). Also, it avoids locking in to RGTC compression format. Precompressed RGTC textures should also work fine if someone decides to use them.
  10. @OrbWeaver has already discussed it in DevIL/png thread.
  11. I added commands for all the features except for "Restart Game" with dmap on. Right now "dmap" checkbox is purely GUI dialog thing, it is not stored in GameConnection singleton. So, I added command "GameConnectionRestartGame", but it never dmaps regardless of what is ticked in the dialog currently. I'm not sure if users need to have a separate shortcut for Restart game + dmap or if they need the current state of dmap checkbox to be respected... Also, I have noticed these "advanced toggles" (used on checkboxes) are not very good: The hotkeys are broken with them. If you only use hotkeys, then it works properly. But if you start mixing clicks on checkbox and using hotkey, then sometimes hotkey simply tries to always set false or to always set true, without changing state. Since advanced toggles are set directly in EventSystem, they cannot be used in DR console. They can be toggled by shortcuts though, so I'm not sure it is a big problem. Also, there is some naming confusion. I originally called two approaches "reload map" and "update map", although the latter term is pretty stupid and I would be happy to find a replacement. But the thing is: both approaches are "hot reload" to me (in fact, the difference between them is mostly on the DR side). For now I keep this naming convention in the code (if it is changed, it has to be changed everywhere at once). For the GUI dialog, I have used @OrbWeaver terms to make two approaches sound distinct. However, the commands still use the naming convention from the code. And if power users decide to configure shortcuts or execute commands, they will face the differences between dialog and code terms.
  12. I wonder what is console used for? Is it worth exposing game connection toggles/buttons for console? What about Python scripting? Can it generate an event? Can it run a command?
  13. What's the difference between command and statement? I mean, I have this code: // Construct toggles _camSyncToggle = GlobalEventManager().addAdvancedToggle( "GameConnectionToggleCameraSync", [this](bool v) { bool oldEnabled = isCameraSyncEnabled(); setCameraSyncEnabled(v); return isCameraSyncEnabled() != oldEnabled; } ); // Add one-shot commands and associated toolbar buttons GlobalCommandSystem().addCommand( "GameConnectionBackSyncCamera", [this](const cmd::ArgumentList&) { backSyncCamera(); } ); _camSyncBackButton = GlobalEventManager().addCommand( "GameConnectionBackSyncCamera", "GameConnectionBackSyncCamera", false ); As you see, _camSyncToggle is created from lambda and directly tied to toolbar button. But _camSyncBackButton is created as a command in CommandSystem, then same-named command is created in GlobalEventManager, which is finally tied to toolbar button. Why can't we delete the last three lines? What do they even do? UPDATE: Both of these two things work in toolbar, and both of them show up in Keyboard Shortcuts and work properly from shortcuts too.
  14. There is one more thing I forgot. In my opinion, it should be possible to assign hotkeys to game connection actions. Defaults keys are not needed, but if mapper finds himself using something a lot, it should be possible to do it quickly from keyboard. Aside from speed, there is also a problem of screen size. @Wellingtoncrab has a laptop with small screen, and even the new GUI window takes too much space on it. He should be able to use common features with GUI window hidden. How is it usually done in DarkRadiant?
  15. That's an interesting option, although a bit complicated. And if we do it for normal maps, better do it for ordinary textures too. Basically, we can distribute tga/png textures, and write dds textures straight on player's machine on-demand. Of course, TDM installation will increase in size... With all the normal maps, I have dds directory of size 2.5 GB. Now consider how the size will increase if we replace dds with tga for ordinary textures (provided that we find most of them in SVN history). I'd say it will become 5-6 GB download and 9 GB after install...
  16. I think I initially resized the window in wxFormBuilder, then got annoying problems with activity indicator, and finally forget that sizes should not be constant. I hope I'll remember where to look for information if I do any GUI in the future. UPDATE: I added SetMinSize just before calling Layout. I tried merging the branch, it worked fine, no conflicts. Nobody except me changed Game Connection code, and my changes outside it consists of a tiny hack in MapExporter. If you update entity spawnarg every frame, then it will be very bad with "Update after every change". This mode schedules update on next frame after every change (delaying by one frame does not increase latency but allows to move many entities at once). Also, "update map" is blocking. If you update spawnarg only when mouse is released, then it should be OK.
  17. The common opinion is exactly opposite: compression artefacts are way more visible in normal maps than in diffuse maps, and mostly due to specular light. It won't be easy... but I guess it is possible to check for image program and dump tga of the end result, then compress tga to dds and replace image program with dds image path. By the way, will we simply delete tga normal maps after everything is done?
  18. I don't understand the rationale. There is X system, and there is Wayland. The programs written for Wayland don't work in X system. The programs written for X system work in Wayland via compatibility layer. Given that we cannot combine both systems in one build, relying on X system sounds like the best solution.
  19. I guess you can do this now "in theory", i.e. disable image_usePrecompressedTextures.
  20. I wrote a simple script to convert all *_local.tga textures to DDS/BC5 using compressonator. From a very brief testing, the game loads them and looks normal. So I wonder about this point: The easiest solution is to run image programs using DDS image as source. All these texture compressed formats are trivial to decompress. The main question is about quality, I guess.
  21. Sound good to me. I think if something needs to be added, it should be added to the GUI window. The menu interface was temporary from the very beginning, and I hope it will never be used again. Ok, I'll write some initial tooltips then.
  22. I don't want to push it... But are there any plans about integrating my latest changes? I have finished working on game connection for now, at least on DR side. In my opinion there are several TODOs remaining: Now "Connection" menu contains only one item, which spawns the new window. Is it OK? Should it be moved somewhere else? There are no icons for "pause" and "respawn" buttons. I guess I'll try to draw them myself (I use Inkscape a lot myself). It is obvious how to draw "pause", but what to draw on "respawn" icon? It would be nice to have some verbose words about the new GUI window. Should it be in tooltips or in manual/help? Should I try writing them (judging from feedback over wiki page, I'd probably avoid it) ?
  23. Legacy OpenGL? I guess you should ask @cabalistic about it, but to me it's total bullshit. Of course, you need a "fat" driver with deprecated stuff into order to use them. But I think it is only a problem if you want to use newer features (GL3 and later) at the same time. And I think even Linux drivers support deprecated profile today. As far as I understand, you use GL 2.1 and no more than that, and you rely on glBegin and lots of other stuff anyway. In my opinion it is not wise trying to clean everything to Core profile. It will take a lot of time, result in complicated code, and will most likely be slower than it is now. Did you ever try to reimplement immediate-mode rendering (glBegin/glEnd) in Core GL3 ? It is very hard to achieve the same speed as driver shows. If you manage to put everything into one display list, performance improvement should be crazy, at least on NVIDIA driver. Of course, the results are heavily dependent on the driver. The reason they are rarely used today is that they are not flexible: you cannot modify parameters and enable/disable anything. Display list only fits if you have static sequence of OpenGL calls. Perhaps it won't help with lit preview, but basic "draw things where they are" view is OK. Oh, I did not enable lit mode and profiled the basic one. Yes, calculateLightIntersections is very slow here. With L lights and E entities, you have O(L E) intersections in the loop here. That's a hot loop which should contain only a bare minimum of calculations in it. The problem is that you compute light's bbox O(E) times per frame, and entity's bbox O(L) times per frame. Compute boxes once per frame for each thing, and the problem should go away. After that you will have another problem: I understand that you want to have stable pointers when you put objects into container by value. But the truth is, linked lists are very slow to traverse (The Myth Of Ram should be read by every programmer who cares about performance). Unfortunately, DarkRadiant relies of linked lists in many places, and the same problem happens e.g. during scene traversal. Going through entities/brushes is very slow when they are in a linked list. Maybe use std::vector? Or at least std::deque if addresses must not be change? In this particular case, you can copy _sceneLights into temporary std::vector and use vector in the loop (in calculateLightIntersections). Same applies to bounding boxes: precompute them into std::vector-s before quadratic loop.
  24. If you don't need dynamicity, then you can compile a display list and render it when camera moves. It is a very simple approach from base OpenGL, and it makes wonders (I remember I saw it working even faster than VBOs on NVIDIA). Of course, if you change some settings or filters, then you need to recompile display list, which will take some time.
  25. I don't think messing with OpenGL commands is a good idea. You won't win much easily, and redoing all the rendering is too complicated (and the more advanced OpenGL features you use, the more driver bugs you suffer from). Note: I'm not sure there is much to win here. Maybe 20%... not more. Here is profiling data from Behind Closed Doors (worst scene): It seems that CollectRenderablesInScene does not do any OpenGL calls. It is a bit sad to see std::map destructor eating 5% here (out of total 88%). Here some time is spent on searching in map (1.3%), reserving 1024 elements (4.3%), and push_back (2.2%-??3.5%??) --- out of 10% spend in addRenderable. This is from within submitToShaders (6.1%) --- 5% is spent on various data structures. Once again: changing this won't immediately turn 5 FPS into 20 FPS.
×
×
  • Create New...