Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16717
  • Joined

  • Days Won

    47

Everything posted by greebo

  1. Sorry, I'm afraid this question is too vague for me to answer. It's all about the VC++ solution, if you intend to use Visual Studio. All the dependencies need to compile against that new platform, the produced binaries can then be linked with the main application and DLLs.
  2. DarkRadiant's main codebase is not relying on any intrinsics as far as I can recall right now, it's generally kept very close to the C++ standard for portability reasons. Third-party libraries like Eigen might use platform-specific stuff, but I assume they are portable as well. It all comes down to whether the third-party dependencies provide a port to the platform, these are some of them: freetype - https://download.savannah.gnu.org/releases/freetype/ FTGL - https://github.com/frankheckenbach/ftgl GLEW - https://github.com/nigels-com/glew libeigen - https://gitlab.com/libeigen/eigen libgit2 - https://github.com/libgit2/libgit2 libjpeg - https://sourceforge.net/projects/libjpeg/ libpng - http://www.libpng.org libsigc++ - https://github.com/libsigcplusplus/libsigcplusplus libvorbis - https://github.com/xiph/vorbis/ libxml2 - http://xmlsoft.org/ libzlib - https://zlib.net/ Python - https://www.python.org win_iconv - https://github.com/win-iconv/win-iconv wxWidgets - https://wxwidgets.org A problem might be the openGL version that is supported on your target platform. There could be some openGL API calls in DarkRadiant that may cause troubles.
  3. I remember IZaRTaX telling me that over on Discord. Yes, it's been removed, but it was not intentional. Feel free to open a tracker for this.
  4. Yes, so the 1.40 profile is needed after all. I haven't checked the TDM engine code, but I assume there must be a workaround in place there to achieve instanced rendering on older drivers. Not sure how much work that would be.
  5. @datiswousCan you try to open the file gl/zfill_alpha_vp.glsl and change the version check in the first line to 130 instead of 140? It's possible that GLSL 1.30 is good enough, it worked for me locally at least. #version 130 in vec4 attr_Position; // bound to attribute 0 in source, in object space in vec4 attr_TexCoord; // bound to attribute 8 in source ... I think the interaction glsl files might have a similar check in them, maybe you'll run into the next file - you can try to do the same change there. About hat GLSL version, I remember checking the version history, and GLSL 1.40 was released somewhere around 2009? I have been thinking I'm pretty much on the safe side here, but maybe I've been wrong about this.
  6. Hello Nort. That "some volunteer" you so respectfully refer to, would be me. I'm greebo around here, it's a pleasure to meet you. I'd like to inform you that I didn't mess with anything, especially not the "counting system". And the "engine" is DarkRadiant, which is the editor. And it is still able to count to three, even to four if you want it to. And you can still build your maps just fine, even with textures, because nothing has changed in calculating the texture coordinates, or displaying the brushes, or anything. Could you please get the facts straight and (more importantly) tone down the stress level just a tiny bit?
  7. And @Nort, I'd appreciate you editing your status update to clarify the situation, to not needlessly get people scared about map corruption.
  8. No harmful behaviour here, it's just a formatting issue, the underlying value doesn't differ. The difference between 2.14 and 3.0 is the fmtlib version DR is using. It appears that the fmtlib update to version 8.1.1 introduced a change in formatting behaviour when omitting the format specifier. Explicitly setting the format specifier to "g" removes the rounding of the rightmost digits: fmt::format("{0:g}", value)
  9. Maybe this is a good time to revisit the rest of the log file too. Do you care to you double check what other entries there are that might not be useful from your point of view? I might have been missing a lot of them over the past years.
  10. I added a link to your PPA to the website. It usually takes some time for the debian package to appear.
  11. I think the overlay system was designed to work with the player entity (HUD, effects, etc.), hence the name. It was implemented on the generic entity level, so it replaced the older system for all the entities. That's what I could figure out in the little time; it has been ages since I've touched that code and if I recall correctly, I didn't implement it myself, maybe it's been Ishtvan. I think, yes, since the "gui", "gui2", "gui3" spawnargs are processed before any script or game code has a chance to load any additional GUIs and reserve these [1..3] handles. A workaround to not hardcoding the handle might be 1) use the script loop you wrote to find out what handle it has been assigned or 2) load the GUI by the script itself using me.setGui("guis/test.gui") and store the handle somewhere (either a script object field or the "me" func_static entity). I know how you feel, weird GUI syntax is weird. I remember having my own fill of figuring out the GUI quirks back when we didn't have any sources to check. The GUI parser also chokes if no onTime block is present after the "float vis" declaration (without semicolon), claims about running into "unexpected end of file". It seems almost everybody hates working with GUIs, but after you've sunk in you'll find can do a lot and there are some really powerful features in there. The logging only works for the main menu GUI, which I assume is where you got that part from. The main menu GUI has special support in the C++ code, in idGameLocal::HandleMainMenuCommand or something like that. IIRC this method was the only place I could connect to the main menu GUI and implement things like the Mission Download GUI (in the days of closed source). set cmd "log" was one of the crucial things I needed for debugging stuff. You can look at the main menu to learn, but some things cannot be applied to regular player or entity GUIs, especially the set "cmd" trickery.
  12. Ok, if I understood your use case correctly, this should do the trick: Change the GUI to look like this: windowDef test { rect 0, 0, 640, 480 backcolor 0,1,0,1 visible "gui::is_visible" notime 0 } The visible property is now bound to the is_visible GUI state variable. Which is "0" by default, so the green window starts out hidden. Change your script to toggle the visibility by inverting the state flag: void onFrob(entity me) { sys.println("frobbed"); // Invert the is_visible variable that is bound // to the visible property of the test window me.setGuiInt(1, "is_visible", 1 - me.getGuiInt(1, "is_visible")); // Note: The first argument "1" refers to the first entity GUI // as defined by the "gui" "guis/test.gui" spawnarg } Does this help?
  13. @GeepIf you care to create a small PK4 for me with that particular set up, I'll have a look.
  14. DarkRadiant 3.0.0 is ready for download. It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before. The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements. For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.14.0 Feature: Realtime shadow mode Feature: Allow way to hide some entities in Create Entity list Feature: MD5 Animation Viewer: show current frame & total frames Feature: MD5 Animation Viewer: jump to frame Feature: DarkRadiant warns about missing .darkradiant file on load Feature: Ability to center 3D camera on selected entity Feature: Cut functionality to complement copy and paste Feature: Save user settings by application version Fixed: Free Rotation not working anymore, can only rotate along 3 axes Fixed: DR crash with combination of mouse buttons pressed Fixed: Git Sync Exception: too many redirects or authentication replays Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Fixed: Selected Skin not showing in ModelSelector Fixed: Reload Defs takes longer every time Fixed: ForceShadows materials are not casting shadows Fixed: Objective GUI doesn't display properly in some places Fixed: Crash on loading certain maps Fixed: Vertex colours do not show on models in lighting mode Fixed: Entity inspector shows inherited spawnargs of previous selection Fixed: DR overwrite order for defs is different from TDM's Fixed: X/Y and Camera View bindings don't save properly Fixed: Material Preview rendering Fixed: "Replace Selection with exported Model" sets classname to "func_static". Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant Fixed: Rotating a func_static result to random stretch textures Fixed: DR crashes when syncing with remote Git repository Fixed: Switching visibility of Github repo from public to private causes crash Fixed: Dockable window layout doesn't save new floating XY views Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg Fixed: Entity inspector considers inherited colors black Fixed: ReloadDefs moves def_attached light crystals to entity origin Fixed: Option to filter skins out of search results in the Choose Model dialogue Fixed: .lin files can't be opened if different case than .map name Fixed: Model chooser radio box selection issue Fixed: Changing multiple lights between omni/projected resets colours to black Improvement: Allow absolute paths for snapshots Improvement: Light diamonds and Speaker radii are transparent Improvement: Unify Declaration Parsers Improvement: Add "Create Particle" to right-click orthoview drop-down menu Improvement: Revisit Interaction Shader to get closer to the TDM looks Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs Improvement: UI for worldspawn-to-entity conversion Improvement: classname field should always be read-only, to force use of the "Choose entity class" button Coding: Update solution and build dependencies to Visual Studio 2022 The list of changes can be found on the our bugtracker changelog. Have fun mapping!
  15. I'll probably be going to release 3.0.0 in the next few days, unless someone has noticed anything that might stop that train. Thanks a lot for testing the new release, folks, this is invaluable and makes DR better for everybody.
  16. Not so sure how much work AA would be to implement, but you can dock off the camera window and move/resize it for your needs. Does this help?
  17. New version 3.0.0pre8 is available in the first post. Fixed the misaligned entity box, and patch vertices can be snapped again.
  18. I can confirm the problem, it's a regression. I'll look into it.
  19. Yes, I'm aware of that. It might not make it into the first 3.0.0 release, I'm afraid.
  20. A new build is available, links and changelog can be found in the first post.
  21. Oh man. Can you share that map with me, and does it happen every time?
  22. I'm not familiar with this bug. Can anyone confirm this behaviour?
×
×
  • Create New...