Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6740
  • Joined

  • Last visited

  • Days Won

    231

Everything posted by stgatilov

  1. Well, mapper can at least establish relative order between translucent entities of same-kind material. But I think it is not possible to do this in script right now. Yes, it is not perfect, but it should work. It would allow "user-assisted translucency" for those who dare. I don't think there is anything like that. Moreover, SEED is hardly a good piece of code to look for admiration...
  2. @duzenko, how can mappers control render order now, including dynamically from script? Can they set "sort" parameter directly as spawnarg? Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value? Can it be done in script during runtime?
  3. On VirusTotal only one piece of software reports something, and that's not Avira: https://www.virustotal.com/gui/file/3eb8c46eeeb508454457bf392a16bb5ff83e244bfa5cb333cb93a02d3e14e0c3
  4. Then let's remove this sort by some matrix element, and think how to allow mappers tweak order dynamically in such a way that we won't break it in future.
  5. BTW, there is another solution straight from the days of the first Doom: we can use BSP to establish rendering order. But: Our BSP is too large to traverse in realtime, so we should build a separate BSP only for translucent geometry. If some surface is split into chunks by BSP planes, we must not merge it back: we must retain each chunk as separate surface and order + render each chunk separately. Obviously, this only works for world brushes: no entities, no patches, no models. It is not obvious how to merge unsupported translucent geometry into BSP order... maybe by some origin point. This requires quite serious effort on dmap + rendered frontend + integration with backend.
  6. I think the best solution would be to save the current way of rendering objects, but allow mappers to specify tie-breakers in scripts. Don't try to make clever automatic solution, it won't work and won't be easily configurable. If mapper really wants to get complicated translucency work, he can often get away with some simple conditions like: if in area Q, then render A then B, otherwise render B then A if coord X < 1540, then render A then B, otherwise render B then A But for this to make sense, we need to guarantee that we won't try to tweak anything above this tie-breaker ourselves. We won't change "sort" variable in core materials, won't split its values into more classes, etc. All that tweaking that you did in the core game must be stopped, because if you continue, you'll break mapper's translucency tweaks.
  7. After some more consideration, it won't work, even in limited case. Actually, nothing will help. You'll just replace one problem with another, no matter what you do. Translucency is common problem which remains unsolved. If you have ordinary translucent objects with common material, then you can at least do some OIT (like per-pixel lists, depth peeling, or weighted approximation), but if you need to copy background, nothing of it works. Just remember that you should not have more than one heatHaze material per view, and that if you have many translucent objects, they'll probably render in wrong order.
  8. In order to depth sort, it is desirable to take bounding box of surface into account. That would allow to support world surfaces, and entities not centered at origin. Depth sorting has one major problem: as player moves, objects order sometimes changes, which results in a hugely visible "toggling". In a sense, it is more pleasant to render surfaces in fixed order than to sort them dynamically. Wouldn't it make sense if we apply proper sorting only for static surfaces whose bounding boxes don't intersect? I believe it is possible to reliably decide which box should be more distance in this case. Not sure yet what to do if boxes intersect, or how to mix it with dynamic objects: comparison must be transitive...
  9. So if you have two similar translucent objects with different colors, they will look good from one side, but wrong from the other?
  10. So, the latest commits are trying to add "sort by distance/depth" for some surfaces, as well as allow several copies of currently rendered framebuffer. I wonder: how is the problem of Z sorting solved for translucent objects? I mean: the engine probably already has some sorting for translucent objects to make translucency correct... where is it implemented in the code?
  11. Actually, I'm still not certain the script does anything with T-pose issue. I spent a week trying to understand and replicate it to not avail. It is probably some timing-sensitive bug which just just does not happen with script... thank god it does not The original release has 180 "neverDormant" spawnargs but the map has almost 300 AIs. I guess that's why the script improves performance even further.
  12. As you probably remember, I'm strongly against tying LOD setting to all kind of unrelated graphics settings I did not look the latest commits yet, but I think I glimpsed this kind of dependency...
  13. Returned to this story. Looking at flathub requirements: It means running tdm_installer is explicitly forbidden.
  14. To whoever has access to SVN and Visual Studio. I have applied the original patch by @Daft Mugi, except for the code in Physics_Player for automatic crouch/uncrouch depending on direction. And I did not add a cvar, since I believe this change should simply "be or not be" I'd say it feels good. Some minor questions: Pressing crouch on ladder results in crouch indicator quickly going down/up. Perhaps it would be better for it to stay "uncrouched" until sliding down starts? When slide-down is over, player stands up on key release, regardless of whether he was crouched or not when he initiated the slide. Initially I through it would be wrong, but on the second thought this is better because player can simply remember that he will be standing after slide-down, and crouch on muscle memory if he wants.
  15. @Daft Mugi, then don't waste your energy right now. Just wait a bit until some more commits come, then say what's wrong. Such discussions are lengthy, especially when no perfect solution exists. I think sooner or later we come to same solution as @Daft Mugi . I'll review the original patch and see if I can remove the direction-specific behavior but retain the ladder/rope + slide-down handling.
  16. I'm asking the people who had the original problem, i.e. guys on rather vanilla Windows 7. Like @Gadavre
  17. Well, the problem is that I don't like having a bunch of cvars either. We had a story when we realized that multiple missions are broken with use-on-frob turned off. Nobody noticed it because it is turned on by default, and only rare players changed that. I don't even remember if it is fixed or the missions are still broken. Adding cvars will be temporary solution. Sooner or later someone will notice that cvar is broken in a mission and remove it, or declare it unsupported since it is not in the menu, or someone will find out that nobody uses cvar and will delete it, or somebody will delete it because it does not allow to change something which needs to be changed (or because it got broken due to already committed changes), etc. Adding cvars as kill switch or for testing is OK, but adding cvars as legit player's choice... we'd better not. We still have a very lazy solution which does not introduce new problems: use crouch on keyup while on ladder/rope. In the worst case, we can just use it. And since everybody agrees that crouching while on ladder/rope makes no sense, hardcoding state to "standing" is probably OK too.
  18. Protecting children from pornography? Don't believe that shit! That's exactly how internet censorship started in Russia: forbid child pornography, drugs, and suicide info online. By this moment they just ban and disable everything they want for whatever reason. Parents can protect their children themselves using parental control features. There is no need to ban websites or block everyone in order to protect children.
  19. Note that the lightgem indicator does not reflect whether player is currently crouched, it shows "crouch intent" --- whether player wants to be crouched or not. For instance, when you go through a pipe, you can toggle crouch and the indicator near lightgem will toggle too, but the player will stay crouched all the time.
  20. Originally I planned to send the chassis by post. I abandoned monitor, speakers, keyboard + mouse, headphones + mic, and only took the chassis.
  21. Could anyone check if the just released dev build works?
  22. dev16498-9944 is now public! P.S. This is how I celebrate resurrection of my PC
  23. I have successfully resurrected my PC! Here is it packed initially: And this is it unpacked: Yesterday I finally bought a monitor, and everything works: Thanks to everyone for advice! I carried the chassis in luggage all the way through, including flights.
  24. So, this is basically "always slide down crouched, but then restore state". What feels wrong is that when I hold crouch button, I don't really know when sliding will stop, so I hold the button for longer than necessary. It feels wrong that player lands crouched, then thinks for half a second, then for some reason stands up on key release. Anyway, I fell really vague about controls, and I think we need more team members here. @Obsttorte@Dragofer@STiFU@kingsal The initial simple idea "crouch-toggle immediately when key is pressed down" faced the following problem: if player is on ladder (or rope) and he holds crouch button for some time, then he slides down. Previously the toggle-crouch did not happen if sliding was detected, now it happens first, then sliding down follows. So we try to find simple solutions for the issue.
  25. So, we have some more simple solutions: Retain old behavior on ladder/rope, do crouch-toggle only under normal conditions. While on ladder/rope, use crouch key only for immediate slide down, don't let it change crouch intent at all. I tried to do that on top of the current trunk code: toggle crouch again when key is released if slide-down was used. To be honest, it does not feel good, better not toggle crouch state to begin with.
×
×
  • Create New...