damiel

I am not sure if including all of those 3 headers is the way to go especially because we already include glext.h from TDM so we would get another clash without adding a couple of more ifdefs. (I will play around with those anyways, its worth investigating) And about the filesystem header, the crux is that neither of those two exists on macOS simply because it isnt shipped with xcode and its commandline tools, you either have to wait for it to be shipped by apple or use a custom compiler build either installed by homebrew/fink or by compilling it by hand.

Sorry for the double post, I was able to remove a tiny part of the error messages but the majority is still there. I had to define #define GL_ARB_shader_objects 0 right after including the opengl header. Later it will be set again to 1 in glext.h so i hope this is fine. But there are still plenty of error messages left and i out of ideas right now... (not that i had many to begin with ) EDIT i did it, i managed to overcome the first encountered hurdles, found some new errors that need to be fixed, i will see if i can fix those aswell. EDIT2 Next show stopper: idlib/StdFilesystem.cpp:26:11: fatal error: 'experimental/filesystem' file not found #include <experimental/filesystem> The comments related to the code suggest that this should work for both gcc and clang. Any ideas? EDIT3 I should share what other fixes i have so far: In qgl.h line 30 #include <OpenGL/OpenGL.h> This header is a bit of magic to me, it seems to be related to Core OpenGl/CGL which is macOS equivalent to glx on Linux or WGL on windows. Other thing i had to fix was Simd.cpp line 257 #elif MACOS_X into #elif defined(MACOS_X) EDIT4 After some research it seems the version of libc++ which does not have this header yet, the only solution for this that were suggested was to either use gcc which is kinda messy because alot of places expect clang to be the main compiler or to use a beta release of xcode and its commandline tools. Here is a related stackoverflow thread about it.

Small status update: I havent been able to resolve the issue related to qgl.h yet. From the error messages itself it seems there is a declaration collision, between the glext.h provided by TDM and gltypes.h provided by the macOS SDK/OpenGL framework and i havent found a way yet to untangle this mess... the gltypes.h is included by the OpenGl headers used by macOS... I keep trying to research this problem.

I checked your fix but it doesnt seem to work. If you want to use ifdef instead of ifdefine i think you have to remove the braces around __ppc__ EDIT I just checked, yes you have to remove the braces to make it work.

This seems to work as fine and also revealed a problem in Math.h which tries to include ppc_intrinsics.h which is not existing in modern macOS SDKs, but there is a workaround. So something like #if defined(__ppc__) #include <ppc_intrinsics.h> #endif will help there. I will take a closer look at qgl.h to see if i can resolve the issue.

Ok, i will first try to build trunk to see what needs to be done and maybe update the documenation for macOS. First thing that has to be fixed is #elif defined( MACOS_X ) in qgl.h in line 26 which needs to be changed to #elif defined( __APPLE__ ) otherwise it will look for the opengl headers in the wrong place(gl.h vs OpenGL/gl.h) This will be a fun little ride to get to compile , i keep you updated on my findings... EDIT Btw which opengl version is required by TDM, anything newer then opengl 4.1? Because i keep on hitting problems in qgl.h, see the attached log output. qglh-errorlog.txt

I can give it a shot if you have some hints for me.

Quick question: i checkout the osx branch but i only found xcodeproj files for tdm_update but not for the engine itself, is that intended or a mistake on my side?

Sry for the double post after some playtesting i found a bug. Alot of times lights tend to shine/pierce through concrete walls or objects, being visible when they definitly should not. Another thing i noticed is, that when you try to trigger this bug with wooden objects, chairs, tables or that kind of stuff, you see some sort of wireframe on the wooden object, mainly on the exact spot where you can see the light shine through.

Thanks to both of you, i got unto the right track. I checked the security settings and it seems that macOS Sierra and its Gatekeeper settings are more stricter then older versions, the option in the GUI to enable apps from unidentified developers is even hidden per default and you have to completly disable Gatekeeper if you would like to enable them via GUI. As disabling Gatekeeper for the entire system is not exactly safe, i did some research and found a way to add per-app exceptions to Gatekeeper using the commandline. Short version is to run: spctl --add path/to/The\ Dark\ Mod.appYou can take a look here to get a more detailed explanation: http://osxdaily.com/2015/07/15/add-remove-gatekeeper-app-command-line-mac-os-x/ Doing this small step i can now simply doubleclick on the app to start the darkmod as expected.

Hello greebo, thanks a lot for your work on this, i recently switched to macOS as my main system and obviously had to test this out. I have good and bad news tho. Good news is that the game runs perfectly fine on my mac, a macbook pro 13' 2017 model, bad news is that running it using the app doenst seem to work, i had to start the darkmod by opening up a terminal and go inside the app forder like cd /Users/martin-kevin/Games/darkmod/The Dark Mod.app/Contents/MacOSand start the binary using ./The\ Dark\ ModAny ideas whats wrong here? The content of my darkmod folder looks like this: AUTHORS.txt tdm_ai_humanoid_townsfolk01.pk4 tdm_sound_ambient03.pk4 tdm_textures_other01.pk4 LICENSE.txt tdm_ai_humanoid_undead01.pk4 tdm_sound_ambient_decls01.pk4 tdm_textures_paint_paper01.pk4 TDM_icon.ico tdm_ai_monsters_spiders01.pk4 tdm_sound_sfx01.pk4 tdm_textures_plaster01.pk4 The Dark Mod.app tdm_ai_steambots01.pk4 tdm_sound_sfx02.pk4 tdm_textures_roof01.pk4 TheDarkMod.exe tdm_base01.pk4 tdm_sound_vocals01.pk4 tdm_textures_sfx01.pk4 ca-bundle.crt tdm_defs01.pk4 tdm_sound_vocals02.pk4 tdm_textures_stone_brick01.pk4 config.spec tdm_env01.pk4 tdm_sound_vocals03.pk4 tdm_textures_stone_cobblestones01.pk4 crc_info.txt tdm_fonts01.pk4 tdm_sound_vocals04.pk4 tdm_textures_stone_flat01.pk4 darkmod.ico tdm_game01.pk4 tdm_sound_vocals05.pk4 tdm_textures_stone_natural01.pk4 darkmod.ini tdm_game02.pk4 tdm_sound_vocals06.pk4 tdm_textures_stone_sculpted01.pk4 description.txt tdm_game03.pk4 tdm_sound_vocals07.pk4 tdm_textures_window01.pk4 fms tdm_gui01.pk4 tdm_sound_vocals_decls01.pk4 tdm_textures_wood01.pk4 tdm_ai_animals01.pk4 tdm_gui_credits01.pk4 tdm_standalone.pk4 tdm_update.exe tdm_ai_base01.pk4 tdm_mirrors.txt tdm_textures_base01.pk4 tdm_update.linux tdm_ai_humanoid_builders01.pk4 tdm_models01.pk4 tdm_textures_carpet01.pk4 tdm_update.log tdm_ai_humanoid_females01.pk4 tdm_models02.pk4 tdm_textures_decals01.pk4 tdm_update.macosx tdm_ai_humanoid_guards01.pk4 tdm_models_decls01.pk4 tdm_textures_door01.pk4 tdm_version_info.txt tdm_ai_humanoid_heads01.pk4 tdm_player01.pk4 tdm_textures_fabric01.pk4 thedarkmod.x86 tdm_ai_humanoid_mages01.pk4 tdm_prefabs01.pk4 tdm_textures_glass01.pk4 tdm_ai_humanoid_nobles01.pk4 tdm_sound_ambient01.pk4 tdm_textures_metal01.pk4 tdm_ai_humanoid_pagans01.pk4 tdm_sound_ambient02.pk4 tdm_textures_nature01.pk4

Just to clarify the Payday 2 stuff: It is limited by time and available copies, its limited until the 21th of june or 5 million copies whatever happens first.

Instant vote from me, i wish you best of luck in getting greenlit!

@NightStalker i did gave your patch a run now, it compiles fine and the game is running without any noticable errors, so consider 64bit linux as tested.

Maybe we can find out more if we look at the revision which introduced the date correction for zip files? Revision 6588 seems to be the commit which introduced the date correction. EDIT: I was able to dig out a bugreport about the problem: http://bugs.thedarkmod.com/view.php?id=4167

Thank you for the hint, i missed that little detail, it's kinda getting hard to follow every discussion with so many being around now! Using the combined patch and hardcoding the path to the system copy of boost, makes everything compile just fine. After that i encountered the invisible man problem but luckily that one was resolved by using the missing pak file. I started a couple of missions now and everything seems to be fine, no crashes or other oddities. So for me at this point there are only two concerns left now: 1. patch review 2. handling of boost libs and possibly other improvements to the build process for linux.

I am build trunk right now with your combined patch applied as i dont have access to 2.05 yet. Ill keep you updated how it runs once i am done building. EDIT Okay i get following error while building tdm: I obviously dont have that directory, just /usr/lib/ and /usr/lib64. I have the missing libboost_filesystem.so which is a symlink to the versioned file of my distribution in /usr/lib64. Boost is installed as 32bit and 64bit package.

Evening, just send the pm to taaki to get access. Here some info about my hardware and soem additional stuff: gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. As i said earlier before i am running Fedora 25, 64bit. Hardwarewise, i sport a AMD Athlon X4 640, a AMD Radeon 7850 (1GB memory) and 4 GB RAM. I use the free radeonsi driver and mesa 13.0.2 aswell as Xorg 1.19.0. Yes indeed i intend on compiling the source code for 2.05beta, trying out a couple of the fixes that float around and maybe if i get make some sense out of it, try to come up with some fixes aswell. I have some experience tinkering around with the source code of dhewm3 and rbdoom3bfg. Greetings, damiel EDIT: Forgot something: kernel version is 4.8.14 and libdrm is version 2.4.74

Hey, sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it? I am not so versed in using subversion but would like to try looking at the issue, i am using Fedora 25 so this might give you some more information on yet another development stack. Greetings, damiel

You have luck because i recently(are 3 month really recently? ) stopped using Gentoo, i searched around on my hdd and found the ebuild: # Copyright 1999-2016 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI="5" PYTHON_COMPAT=( python2_7 ) inherit eutils python-single-r1 DESCRIPTION="An open-source level editor for Doom 3 and The Dark Mod" HOMEPAGE="http://darkradiant.sourceforge.net/" SRC_URI="https://github.com/codereader/DarkRadiant/archive/${PV}.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64 ~x86" IUSE="+darkmod-plugins debug python" DEPEND="x11-libs/wxGTK:3.0 >=dev-libs/boost-1.46.1 python? ( dev-libs/boost[python,${PYTHON_USEDEP}] ) media-libs/ftgl media-libs/glew dev-libs/libxml2 sys-libs/zlib media-libs/libpng:0 virtual/jpeg:0 media-libs/libvorbis media-libs/freealut dev-libs/libsigc++:2" RDEPEND="$DEPEND" src_prepare() { epatch "${FILESDIR}/gentoo-204.patch" touch configure.ac aclocal.m4 configure Makefile.am Makefile.in } src_configure() { econf \ $(use_enable darkmod-plugins) \ $(use_enable debug) \ $(use_enable python) } Obviously i cant guarantee anymore that it will work out of the box but it should be a good starting point.

You dont have to necessarily do a whole public overlay, you could ask the proxy-maintainer team to include your package in the portage team, this way you would be the maintainer for the package while the gentoo devs can provide you even more feedback then i could (and we get an official ebuild for DarkRadiant in the gentoo repo). It doesnt take more then forking the gentoo repo on github, create a branch, add your ebuild and all related files (the patch and the metadata.xml) to that branch and then do a pull request. The devs will take a look into your pull request, most likely ask you for some more changes to fully reach the qa standards of gentoo and if everything is done, it gets included. If that sounds interesting to you, id recommend joining the #gentoo-proxy-maint channel on freenode, the devs there are usually quite responsive and helpful to get you set up.

Not to be like this but the ebuild needs some more work, it lacks a dependency to dev-libs/libsigc++, several packages lack a proper slot, it has a broken header and metadata.xml is missing aswell. Here is my corrected version for the ebuild and here is a dummy metadata.xml It's a good starting point tho, thanks for that.