Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Days Won


greebo last won the day on July 5 2010

greebo had the most liked content!

Community Reputation

29 Good

About greebo

  • Rank
    Heroic Coder
  • Birthday 11/26/1979

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    conduction band
  • Interests
    Physics, Sports, Guitar, Coding

Recent Profile Visitors

10862 profile views
  1. I'll have a look at the PR in the next few days, but I can't promise anything. I'll take the liberty and change a few things here and there, and I'm probably going to convert this to a TDM plugin like the conversation editor and the rest.
  2. DarkRadiant is much more modular than TDM, we worked for years to get to that point. We don't have that many globals or statics, it's mostly the static module instances which are declared as globals. The modules do have dependencies, but still it's possible to test their interfaces separately, one after the other. What I'm mostly interested in is not whether GlobalEntityClassManager().findOrCreateEntityDef() is working or not, but whether inserting a new worldspawn in the scenegraph is working properly, resorting the existing entities, or whether the map saving algorithm is working, producing a valid map. I know that the above are not strictly called unit tests but rather integration tests, but I don't care too much about naming. I need proper machine tests to be more confident when refactoring stuff in those sensitive algorithms. Every time I'm touching the map saving code I feel my neck hair raising because of pure angst.
  3. I've had some reorganisation work going on the last few weeks, and I thought I'd give a short overview about what changed and why. Originating from the discussion about lacking unit-testability of DarkRadiant's code, I went ahead and moved all vital DR parts into a shared module. The idea is to load this module from both the main DarkRadiant.exe and the unit testing code. One goal was to enable DR in "headless" mode, so you could run it without any UI, or maybe use a different UI than wxWidgets (theoretically). After moving most of the modules to the core and getting it to compile and work, I went the extra mile to clip off any UI-related code from the core binary, which was sometimes a bit tricky, but I think I'm there. From the bird's eye, DR now consist of the following: An EXE containing the UI based on wxWidgets, including main(). Almost no map editing logic here. The Core / Server DLL containing all modules like VFS, registry, map algorithm, shader, model handling, etc. No wxWidgets allowed here. A couple of plugins (as before, nothing has changed) A couple of static libraries like scenelib and modulelib, and a few header-only libs The main() function is still in the EXE, but one of the first jobs is to set up an ApplicationContext and use it to instantiate the core module. This will load the rest of the modules and initialise DarkRadiant's functional part. All Dialogs, Mouse-Handling, Shortcut Management is handled by the UI binary. When a button is clicked to do something, the UI can communicate with the core module either by the interfaces as defined in the include/i****.h headers or (in case it's a one-way command) by sending commands through the CommandSystem (as with the console commands). There are cases when the core module needs to request stuff from the UI (if there is one), for example when it needs to ask for a filename and display the FileChooser to the user, or dispatch a command failure (such that an Error Popup can be displayed), or whether it's ok to do an automatic save. For this purpose DR now offers a communication channel named "MessageBus", which can be used to send messages or requests to possible listeners. Some message types might not have any listeners and will stay unhandled, the sending party needs to deal with that. Right now, all message types are subscribed and handled by the UI, but the MessageBus *could* be used for general-purpose communication or event handling too. Compilation in Windows and Linux is already working. In Linux, there's a libradiantcore.so, in Windows it's DarkRadiantCore.dll. The Xcode project for macOS is not up to date yet. The next step for me is to merge all this into the codereader/master branch and then merge all the changes which have been pushed to orbweaver/master in the meantime. After that, I'd like to start looking into adding the first unit test based on Google Test, as it seems to be light weight and cross-platform.
  4. "Author" would be me. That brush translation code is an ancient workaround, which was introduced to fix editing behaviour for child brushes of func_* entities (somewhere around 2007 - there were a couple of issues similar to https://bugs.thedarkmod.com/view.php?id=169). The D3 map format needs child brushes to be saved in local entity coordinates, but GtkRadiant/DarkRadiant couldn't handle that correctly. The proper fix would have been a lot of work and probably it would have been above my head back at that time - so the workaround was never removed and carried over since today.
  5. There's std::filesystem in C++17. Its API is almost 100% the same, and we previously did a fair job of wrapping filesystem functionality in the os/*.h headers. (In fact, the implementation shipping with the C++17 standard is almost a carbon copy of boost.filesystem. The people working in the std committee are often the same as the ones working on the boost libraries.)
  6. Actually, I meant boost headers too. At least as far as the Windows compile is conerned, we don't need any boost to compile DR anymore. After replacing the heavily-used helpers like boost::shared_ptr, boost::noncopyable, and the libs boost::thread and boost::filesystem, there weren't any references left except for a few string-manipulation functions and predicates. At this point I decided to bite the bullet and get rid of the entire boost dependencies - it didn't seem appropriate anymore to ship dozens of MB of headers just for those few string helpers.
  7. We used to rely on Boost for many things in DR, but this has changed in the meantime. I think right now the only thing left is Boost.Test in Linux, and Boost.Filesystem (but only for older GCCs lacking C++17 support). I think I used Boost.Asio in 2007 to connect TDM and DR with each other, but I removed it from both codebases ages ago. I'd personally vote for anything that is not making us include and compile the entire boost sources and static libraries in Windows again. I'm actually quite happy about having got rid of the compilation dependencies in Windows. I'm aware that I used to be a fan of Boost myself in the past, but the modern C++11,14,17 standards made it more and more obsolete, and it was actually easy to replace. In short, +1 for ZeroMQ (which I don't have any experience with).
  8. If you can describe the scenario well in a bug tracker entry, I can look into the duplicate behaviour some time.
  9. I created the DR macOS app, DR 2.8 has a working Xcode project. (I just did it for fun, I don't think there's many (if any) DR users on Mac.) TDM is a different story, I know that we had a working Xcode project back in 2012. Can't say what happened after that.
  10. You're saying downgrading to DR 2.6 did not solve the issue? If that is the case, I guess it's something to do with the setup. Can you see and edit the readables in DR fine? Anything in DR's console indicating that something is wrong with readables, xdata or similar?
  11. Is this something that had been working before? I'm not aware of the specific entity setup, but if it was working before, please report it to the tracker, I'll look into it. As far as the texture path is concerned, I think you can right-click the tile in the texture browser to seek it out in the media browser. Or you can pick it with MMB and then look at the shader clipboard info in the status bar.
  12. Ok, I was planning to include the fix for this in a short-term 2.8.1 bugfix release, so let me know. If it isn't reproducible, I think there's only one other issue to be fixed for this release - so I'm probably skip that, no need to do a new version just for one fix.
  13. It's not crashing for me, tried a couple of maps. You got a crash dump for me, perhaps?
  14. In 2.8.0 a limit of maximum grid lines was introduced to fix a near-infinite loop - I guess that was a bit over-ambitious. Can you open an issue on the tracker and maybe add what dimensions / grid sizes you're using?
  • Create New...