MirceaKitsune

Yes, FXAA isn't the only method: There are a few other alternatives to MSAA, which are all worth exploring and testing to see which gives the best results at the best performance with our engine. I believe most are shader based but use different passes to achieve the effect, which IMO is the right way of going about it. I agree that in theory MSAA is the correct way of doing this. Its problem is that it requires multiple samples per pixel which is a great way of wasting GPU power. If we could have everything running in the most accurate way, our dream of a lighting system based on realtime raytracing would come true... on existing hardware that would run at 1 frame per minute. Point being that sometimes it's better to use estimations, especially when they can offer roughly the same result as the more realistic method. MSAA should always remain an option... only wishing that other alternatives could be available for those who need the performance benefit. Ideally they can all be put under one slider or drop-down menu, so you have a list that looks like "FXAA, 2x TAA, 4x TAA, 2x MSAA, 4x MSAA, 8x MSAA, 16x MSAA" (prolly a silly example but you get the idea). Something I forgot to add: I took inspiration for this suggestion from Red Eclipse, the latest version of which uses Tesseract engine (previously Cube). It has all sorts of AntiAliasing options available in the menu, from FXAA to Temporal AA to one I think they created just for that engine. I played with them and FXAA seemed to give the best results, whereas enabling all others at the same time still didn't affect performance as much as enabling MSAA alone.

Here are some useful resources on the matter, sharing in case they make this easier to accomplish. https://catlikecoding.com/unity/tutorials/custom-srp/fxaa https://catlikecoding.com/unity/tutorials/advanced-rendering/fxaa http://blog.simonrodriguez.fr/articles/30-07-2016_implementing_fxaa.html https://iryoku.com/smaa https://www.geeks3d.com/20111101/smaa-enhanced-subpixel-morphological-antialiasing

This is useful to know, thanks for sharing! I run most FOSS games from their repositories: TDM is among the only exception due to how it's packaged by its own installer. I might stick to the install manager for game data... the engine I'm already able to compile and use independently if its URL hasn't changed. One curiosity tempts me to ask: Is there a reason why we're using the much older SVN instead of Git? While at that, do we have an official mirror on Github and / or Gitlab for the engine and its game code? It always felt like development could be even better if users on those popular platforms could clone through them and submit pull requests there.

I remember briefly discussing this on Discord, wanted to bring it here for broader discussion. With all the fantastic improvements made recently I felt that before the next release, we should look into the possibility of supporting alternate implementations for anti-aliasing over the classic MSAA. The reason this is important to discuss is performance. Multi-sampling based AA is very expensive: Even 4x, which is the minimal amount needed to properly get rid of jagged edges, is considerably GPU intensive. In older engines that use lightmaps this may not make a noticeable difference. With our realistic lighting system, we still need to squeeze out every bit of performance that we can. MSAA is a notable performance impactor... of course none of us want sharp pixelated edges so we don't want to get rid of it entirely, a faster replacement is thus desirable. The most common alternative available today is FXAA. I understand that like MSAA, it's supposed to be supported by the video driver and the engine just needs to tell the card to enable it. It's a shader / post-processing based solution which achieves nearly the same result but at times faster performance. If it's this simple to support it, could we get a menu option to use FXAA instead of MSAA please, so those of us who feel there's a performance benefit can rely on this alternative?

Please NEVER do that. One of the things I love about TDM is how dynamic it is and how you can interact with every little aspect of the environment, including being able to pick things up and have them fall around when you bump into them. This would literally be deliberately worsening the project. I think the frob highlight should look good on small objects as well. I still think different entity types should use slightly different colors, set via spawnarg on the core defs each item inherits from... this can be done later on.

This is actually kind of cool looking! I don't see it working out as a default color though; I for one support something closer to white, but still bluish if possible... haven't seen a screenshot of that yet for comparison.

Fair enough. Out of curiosity, how does it compare with a more standard blue? Could you share with something like 0.4 0.5 0.6? That looks good too and I don't mind either way, feels pleasant and at the right brightness.

+1 to making the transparency a menu setting. As for the color I'm not sure about that default: I believe it should be pure white, or if anything a slightly blue tint (eg: RGB 0.6 0.8 1.0). I wonder though if maybe the color should depend on the type of entity being frobbed. Like green for doors, gold for loot, blue for in-world decorations you can move around, etc. Obviously as a spawnarg on the definitions of items, root defs can customize it then so every derivative can inherit it without leaving existing FM's out.

Oh wow, he died too? I think I briefly saw or heard about Sir Taffsalot years ago, though it was around when I first found TDM in 2014 I believe. And I actually played that FM too, the name at least I surely remember... now I understand what it was about. Hopefully it's not weird but I'd like to imagine they met where they went, and among other things discussed TDM and what they created with it while on this Earth... maybe that they'll even know where it goes from here on. But yeah: Definitely make at least one FM in his name. Something great and of quality, definitely well deserved

If we want something that's easy to use for mappers and encourages them to actually use the feature, please consider my idea to create an actual Git plugin for Darkradiant, and let me know what you think about it since I'm quite curious myself. Unlike my idea for realtime editing it's actually not something that radical to implement. I'd basically go for a set of menu entries and toolbar buttons that automate the appropriate Git commands required to work with a map, a customized GUI for Git if you will. Obviously the OS needs to have Git installed else DR would issue unrecognized commands to the system... on Linux this is a given, not sure about Windows users. It operates on the idea that the current FM directory is a Git repository, while being able to turn it into one upon use if not. The only features and commands it's really going to need are: Clone: Runs "git clone". Only needed if your FM isn't already a repository; This asks you for a Git URL and turns the FM directory into that repo. Pull: Runs "git pull". The repository thus map file are updated from the network, map is automatically reloaded when ready. This may erase local edits or throw an error if the remote map is newer: I understand the commands needed to merge against local changes are "git stash; git pull; git stash pop" (source 1, source 2). If changes were made to the same brushes or entities there will be a conflict: We'll need a prompt that lets you pick which version to keep, ideally with realtime previews later on so you can see how items change in the viewport (local versus remote versions) then have the option to make your choice per group. Same for other text data such as defs or script files, there should be a diff previewer that makes it easy to pick which def / function / paragraph to keep in cases of conflict. Push: Runs "git push". Uploads new commits to the remote repository. This should be pretty straightforward, the plugin only needs to support an additional menu asking for the username and password of the Git repository if they aren't set up in the config. Commit: Runs "git commit -m Message". Records saved changes you made to the map, a window lets you write a commit message describing those changes. The menu should also list every file in the FM directory so you can add or remove map assets as you work with textures / sounds / scripts / etc... if that's too complicated it can automatically add all new files and delete ones that were removed, but only in subdirectories that hold valid map content (eg: "myfm/def"). Log: Runs "git log". Generates a simple commit list in which you may browse through all commits... no need to even account for origins and branches, a linear list of commits from the current branch should suffice for our purpose, long as they're listed in a readable format like short log + author + date. Double-clicking on a commit should prompt you to revert the repository / map to it locally in case you need to go back to an older version. That should pretty much be it! Support for more Git options like branches could be added later but beyond this anything else can be optional. Needless to say mappers who want more features can use Git commands and other GUI Git tools on the FM repository separately: This is just to make it easy to do simple actions directly from DR... it also comes with perks that can be added later such as realtime previews of differences between commits, or a timer to automatically pull every X minutes so the mapper can be notified when there's a remote update and can click a button to reload the map with the new changes. The nice part is we can start with simple basics then expand with more features as needed.

How amazing we'd both write about almost the same thing at almost the same time last night As my thread about full realtime / multiplayer editing is its separate idea, I'll simply quote my post on the matter of non-realtime collaborative editing over Git / SVN and the challenges I see with this idea.

Going to look at the other thread as well, thanks for sharing. Letting DR save and load maps over Git / SVN would be a simpler version of this idea, perhaps even a precursor to it. But it does come with issues: Multiple mappers can't easily work on the same FM at the same time! Here's a more in depth analysis on how I see that working out: The biggest issue is that the moment two or more creators edit the same item, there would be a conflict once the changes are faced with each other and have to be reconciled. We could teach DR how to resolve map conflicts and pick one set of changes, but this means one author's version would be chosen while others have to lose their work. The problem doesn't even end there: Some changes can be reconciled in theory but still lead to inconsistencies in practice! Say one author moves the walls of a building while another handles its furniture entities; DR can agree on which set of changes to keep for each of those movements and everything would seem resolved to the code, however if they aren't made or solved together you're left with an empty house in one place and floating furniture in the other, which a person has to later notice and manually resolve. There may be ways to reduce this risk. One is attributing specific groups of brushes and entities to different creators: Only the person who spawned an item may edit it, no changes to other people's stuff allowed. This way anyone can push map changes to a Git repository at any point regardless of what other developers may have done during that time, the differences can be merged under any circumstance as no conflicts can occur. But it's a limiting approach since you can't help another mapper with their part of the map, while on the other side they can build over what you're doing and you couldn't get their stuff out of the way. A good way to take this approach would be allowing maps to be stored in multiple files during development, so changes don't need to be made to the same file altogether. This means that alongside the main myfm.map you can have myfm.bob.map + myfm.mike.map + myfm.alice.map and so on, when loading the main map content is also loaded from those additional files: Now you can push and pull the git repo at your own leisure, your work is always up to date locally while changes made by others become visible whenever you do an update and reload the map! This alone is unlikely to be noticed or used by many creators though, unless encouraged by additional Git tools in the interface; DR could support pushing and pulling changes directly from the toolbar, with an option to automatically update other authors files at an interval (say 5 minutes by default) then refresh the map seamlessly. While this would all be fun and easier for starters, the holy grail would be realtime editing at the end of the day. That way anyone can work on anything and always see the updated result on their end during all stages... without having to fear emerging conflicts that need to be reconciled later, unless someone's connection goes down and they make changes during that time which should probably be disallowed by the code. If designed properly we could have a powerful and unique system to work with here.

Regarding the FM series he was working on, this is my take on it: I definitely feel the nicest route would be continuing them rather than leaving them abandoned. Ideally by those creators who knew him and the stories well enough, thus know what he'd most likely make of them and the direction he'd want them to continue in. At least the existing / unfinished FM's for sure, but why not new episodes too if someone familiar could assume the series and become their new owner to develop them? Here's an extra idea if I may: In the next original episode, if anyone decides to produce one, add a memory of him in the world as a main plot point... like making him a character in the FM or something nice like that. There are many creators with inspiration here so I'm sure something remarkable could come out of such an initiative! This can be made into a moment of creating something nice that wouldn't have happened otherwise rather than letting it be just a moment of sadness, if that makes sense. Hope this thought helps.

This isn't a feature I personally plan on using as I like to work alone. However I wanted to bring this up as I believe it would help with mission creation and more FM's being developed faster, particularly for people working on FM's in teams rather than alone. I'm imagining a relatively simple system, albeit it may require bigger code changes. Think of it as multiplayer with a server list but for the map editor: DR instances would have the ability to connect to other DR instances (or different server software) over the internet. Upon connecting the map in cause is cloned locally and loaded. The maps are synced between actively connected instances and any change made on any of the connected DR's is mirrored to the others in realtime, with the local map file being updated on each end as this happens. When an user selects or moves a brush or entity on one instance, it's highlighted and repositioned on all others as fast as the network allows... if done right a DR user should see map components moving on their own in the viewports as they would if being dragged by the local user. I'm imagining that such an ability could bring FM creation to a new level; Creators of a FM can connect to a central server storing that FM, ideally up for connectivity 24/7... each author can then make changes whenever they feel like working on a given part of the map, with everyone else seeing those changes in realtime (if connected) or when they connect to the project later. We could have larger and more complex FM's as a result! What do you think, and would this be possible without too much development effort? Trivia: This idea was inspired by the map editor in the Cube / Tesseract engine which is what the popular FPS Red Eclipse uses. It's not just integrated in-game requiring no separate editor at all, but people can start an ordinary multiplayer match to create a map instead of playing Deathmatch. This got me thinking about the possibilities of realtime collaborative map editing, especially for something more complex as TDM FM's where this could accelerate things quite a bit.

This is something I did not expect. I didn't know him personally but saw him often here on the forum. He made some wonderful things that will live on. RIP.

This is an interesting initiative, I'll want to see how it goes. Wishing you the best of luck! TDM and DarkRadiant are very modern tools... at least by FOSS standards, some code is technically +15 years old but that doesn't stop the end result from being as good as if it was made yesterday If it doesn't work out, I'd recommend taking a look at Tesseract (the engine Red Eclipse also uses) which supports modern graphics with the added benefit of having an in-game map editor and even allowing players to create maps in multiplayer! I also have a dream to create an immersive game, which would contain elements from multiple games overall (FPS weapons, stealth mechanics, RPG leveling system, worlds generated in Minecraft voxels). Planning to use Godot for this one, but alas it's not something I'm ready to get myself busy with yet.

I wonder if the installer could offer an option for which platform to use then. The starting page has several options under Advanced Settings, there could be one new checkbox for "Use Wayland" in the Linux version. Just a thought for the future... if it's too complicated it isn't an emergency in my book; We should be able to run TDM on Wayland as is, except apps without native support have to go through a fake X11 session which is slower and not ideal especially for high-end games that can use the performance benefit.

I see. I was hoping it's a builtin feature of GLFW, detecting whether it's X11 or Wayland and launching appropriately in each environment. You'd still require one engine binary though right... as in the same thedarkmod.x64 would know to operate on both renderers, you wouldn't need two separate thedarkmod_x11.x64 / thedarkmod_wayland.x64 engines? If it only requires a Wayland enabled GLFW build I hope it wouldn't be difficult to compile the official engine against one. On my Linux distro (Manjaro) I see a package for glfw-x11 and one for glfw-wayland, both are offered officially. However you can only install one at a time, the packages are marked as conflicting each other. Hopefully they aren't required at runtime in this case, but as a dev you may need to link to each GLFW separately when building.

I'm still curious about a little detail if anyone happens to know the answer: Does the new window management and input system support Wayland natively... by which I mean using the pipeline without having to go through X11? I'm re-asking because I hear KDE Plasma 5.22 (coming next month) should fix all the final issues I was personally running into and kept me on X11, thus a switch may be on the table again.

Just wanted to say I'm looking forward to seeing this lovely effect! The frob outline is definitely going to modernize TDM visually. I'm in favor of mixing it with the old method by default, the new and old highlight should work great together. In the past I've also been confused whether I was frobbing an object or not... albeit the brightening is usually consistent and fairly obvious, there are rare occasions when you can't tell if the item was bright already. This will make it easier to understand what you're pointing at and less risky to use the wrong thing when two objects are close and you can accidentally click on either.

Big fan of the idea here, can't wait to try it out in the latest build It's good that there are cvars to tweak those effects though, some users may not like the new changes; I'd put the customized cvars mentioned above in autoexec.cfg to not lose them... that's what I did with the color correction cvars to make my own environment config.

Does the latest dev build available in the installer include this now? Or will the next one have it at least? Haven't fully understood if it's still experimental or made it in master.

As far as testing goes: I haven't tried compiling the engine from SVN for a while though I remember it worked relatively recently. Any thoughts on when the first TDM 2.10 beta is going to be released? I figure that's likely months away though so I may try the latest master engine if I can.

Alright. And that's because I imagined the method used to draw the window could have a minor impact on paint update latency thus on perceived performance, even if this obviously doesn't affect the work the renderer has to do before the drawing stage of each frame.

Yet another great improvement I'm delighted to hear about! Was directed here from the extra mouse buttons bug since I understand this should guarantee at least 8 mice buttons will work in the input selection. Though I'm intrigued by many questions upon seeing this. The first being if we should see any performance improvement and how much! Also does it mean there will be native Wayland support when using a WL desktop session instead of X11?