Frost_Salamander

OK - I managed with -j12 on my Ubuntu desktop, so the crash might have something to do with Virtualbox. Here are the 'proper' installation docs here: https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/ Docker for Windows: https://docs.docker.com/docker-for-windows/install/ You need to be running either Windows 10 Professional or Windows Server 2016 I think (or else you have to use the Docker Toolbox version, in which case you might as well just use Virtualbox). I don't know how many people are running either of those. I have a dual-boot system with Ubuntu Gnome / Windows 10 Pro, but I don't know what most of you guys are using. So for Docker for Windows the default setting is to use Linux containers, but you can 'switch' it to use Windows containers. So to answer your question it should work in the same manner as running it on Linux. I can try it out later and see.

Just had a quick look at some current hosted CI services. There is a lot of good stuff out there that is free for open source projects. Most of them are Linux/Docker/Github-centric which would be fine if not for the Github thing, but I found one that seems to tick all the boxes for Windows: https://www.appveyor.com free for open sourceWindows / Visual studio build environmentssupports public Subversion repositoriesSome more about their build environments: https://www.appveyor.com/docs/build-environment/ Only thing I'm not sure about is would the environment have everything required for building TDM? They have DirectX SDK and Boost - is there anything else it needs? Another option for Windows might be Team Services, but it's hard to discern what the limitations are - looks like it's free for up to 5 people and might have to use Git (or TFS) as well: https://www.visualstudio.com/team-services/

OK - I've pushed my build image to dockerhub: https://hub.docker.com/r/timwebster9/darkmod-build/ There is a short blurb on there of how to run it. All you need to do is install docker and run that command. It only covers the simple case of a release build - no sense trying to cover every single use case at the moment. Don't worry if you're pessimistic - I don't blame you. If it makes any difference, I do this sort of thing for a living and I wouldn't dream of doing any sort of Linux build any other way than this. Yes absolutely - this is what I'm in fact proposing. If you look at that command to run the darkmod build, it 'bind-mounts' (the -v argument) the source code directory from the host inside the container and then runs the build. When the build stops, the container exits and the newly built binaries will be there on your host filesystem, with no trace left of the container. But why does this happen in the first place? It's because of inconsistent environments - the very thing that Docker fixes. Correct me if I'm wrong, but you can build for x86-64 on Ubuntu and the resulting binaries will run on Fedora right? If so, it doesn't matter what the build image uses for its OS. Now if the game runs on one machine and not the other, this is a different story (the runtime environment). Even if you did want different Linux build environments, all you would need to do is create a Docker image for each one. Again - this is where an automated CI system would help... Also to be clear, containers are NOT VMs. I only used that term because it's the best way to describe it to someone who is not familiar with them. They run a single process only (not an entire OS), and their resource usage is limited to whatever resource the process running inside the container is using. There is lots of stuff on Google describing the differences. Basically a running container will just use whatever resources on the host that the process needs. Yes, there is overhead, but it's almost negligible. A key thing to understand about how they can do all this without being a true VM is that they also share the host operating system's kernel. Another way to think of it is a running container uses only the binaries from the image, but the resources and kernel of the host. A traditional VM allocates and reserves fixed CPU, memory and disk resources, as well has having a much higher overhead for the hypervisor. Regarding running Dark Mod in Docker: Let's keep this to just builds for now - I don't want to promise something that I can't do. I haven't looked into doing this and I don't know if it will work. Using a VM such as Virtualbox isn't a bad idea at all - and if it works then great. However I don't have any visibility of what you guys have been doing so I'm not aware of any problems you might have. If you need a way to share a VM image then I would use something like Vagrant. Again, if Docker is an option here - it uses less resources and startup time is way faster than using a traditional VM. Having said all that, some preliminary searching looks sort of promising. One thing you can do with Docker is share hardware resources with the host. For example graphics cards, sound cards, the X11 display, and I/O devices. This is all done via bind-mounts of the /dev/xxx devices or UNIX sockets. Nvidia has got into the game for GPU processing tasks in datacenters: http://www.nvidia.com/object/docker-container.html (think cyptocurrency or AI computing). However once we start sharing host resources then you lose some of the benefits of using a container - that is we start introducing host dependencies. But it could end up being an easy way to share a current build for testing purposes - it would save having to send a ZIP file around - the current build would exist in Dockerhub which is a central location, and all one would have to do is pull and run the latest image.

You're right in that the Dockerfile itself doesn't do anything particularly clever, but the output of it is a docker 'image'. This image can then be run as a container (the 'VM') and it contains everything you need to build your project. What this means is nobody then has to worry about setting up their PC with all the required dependencies, etc. They don't have to even think about it. I included the Dockerfile/docker image build to illustrate the entire process. Normally a 'user' (whether it's a real person or an automated CI process) doesn't have to worry about that part. Usually someone will create this Dockerfile and build the image. They then publish the image to Dockerhub. Then you, as a user, pulls (downloads) the image to use. I haven't published an image, but if I had it would look like so: docker pull darkmod/darkmod-build Then you build the project using that image using 'docker run': docker run <a bunch of arguments> darkmod/darkmod-build <some build command> The 'advantage' is that the build environment is isolated from anyone's PC and is immutable. It will never change, ever, and will work every single time. For everybody. No matter what Linux distro they have running, or what state their OS is in. Also - you don't even have to do the 'docker pull' - if the image in the 'docker run' command doesn't exist on your local filesystem docker will pull it automatically. Github: I'm sure you've all discussed the pros and cons of switching and I don't mean to rehash all of it here - just if code repo size was a blocker for it I would be happy to help look into possible solutions is all... :-) I've used SVN longer than I've used Git, and I've been involved in a few real-world projects where they were migrated, and it's never a problem. Yes, it can be complicated but it doesn't have to be. I am no expert myself - I basically stick to push and pull, and you can merge via the Github UI, etc. Docker: So primarily I was suggesting using Docker as a build tool - not for running the game. Containers are primarily used for server applications or command-line tools. Having said that, it is possible to run UI apps in containers (I've run browsers in containers before - e.g. Selenium). I think you could use the X Window system in the container or use something like VNC server. I would have to look into this, but would be happy to do it if you think it would be useful - by the sounds of it it would be. The scenario you mention (running the container on any distro) is indeed what you can do with Docker - and why it's so useful. You can even do this with Windows or Mac (although only running Linux containers). Windows containers exist now, but I have no experience at all with it so can't really say what's possible there. Automated builds: If we can use a free CI system then the 'administration efforts' would be minimal - especially if we use Docker. That's one of the reasons I'm suggesting it - to pave the way for stuff like this. One final note in case it's not obvious - using Docker for builds does NOT replace the current build system (scons or whatever). That all stays put. It just runs the current build command in the container. It's the environment that changes. not the process.

To better illustrate, let's contrast the different ways of doing this: The Old Way 1. Obtain a build machine (PC, VM, or server) 2. Install required OS (Ubuntu, Debian, Windows, Mac, etc) 3. Update OS 4. Download and install required OS dependencies (e.g. apt install mesa-common-dev, scons, subversion, etc). 5. Download and install required project dependencies (e.g. Boost). May require building from source, etc 6. Download project source 7. Run the build script, and hope (or pray) that it 'just works'. Which it won't. 8. Spend the next 3 hours figuring out what's wrong with your setup. 9. finally get it working 10. Update some OS dependency, and find that your project build no longer works. 11. Someone updates the build script or adds a new dependency, and the build no longer works because they haven't updated the Wiki 12. etc, etc Note that instead of step 5. people may opt to include libraries in the source tree. This leads to repository bloat. The New Way (with Docker installed) 1. Download project source 2. Run single docker command. This always works because the 'build image' will have been updated with any required changes as well - if it hadn't the code wouldn't build for the person who made changes to the source code. Note the 'build image' doesn't have to be built by the user - it can be shared via dockerhub and 'pulled' locally. This is done implicitly if it doesn't exist locally when you do a 'docker run'. The user doesn't have to know anything about it at all, in fact.

I'm not suggesting CMake. I'm not suggesting replacing scons. All I'm suggesting is a way to create and use a build environment that is instantly available to everyone and will work every single time. It would be useful for those interested in Linux builds, or those who work on Mac or Linux. You can even run Docker on Windows, and build for Linux from your Windows environment. Or run in it Mac and also build for Linux. That's kind of the point. You can think of Docker has an extremely lightweight Virtual Machine that you can spin up instantly (literally milliseconds) with any OS in order to run a particular task (in this case, to build Darkmod), and then it disappears. The OS (or image) you can build yourself and put anything you want in it (see the Dockerfile in the Github link I provided). Again, this is just one use case for Docker - the others aren't really applicable here. If you don't have any interest or experience with Linux builds, then it won't be of interest - totally understandable. But for someone like me, who wants to build the project in the quickest and easiest way possible, and have it work every single time, it is very useful. Regarding Windows - it's a different story and not really part of this Docker thing. But I was also looking at this whole thing from an automation angle like Tels mentioned in the first post in this thread. This is also doable with VS but like I said it would require a different approach. You would get a better idea of how it's helpful if you worked through the Github example I provided - but if it's not your area of interest then by all means give it a miss. Also - I would be interested in reading whatever article you said ridiculed Docker. The only people that I have heard ridicule Docker are those who have never used it and don't really understand the benefits of it. I've worked in software development for 18 years, and container technology is the single most useful thing to emerge in the mainstream in the past few years (along with cloud computing).

Grayman: believe me I understand where you are coming from.... This wouldn't require replacing scons or MSVS (I'm assuming this means Visual Studio). Rather it still uses them and complements them. Think of it as abstracting the build process up into another layer - one that is far easier to manage (both for newbies and experiences devs), as well as paving the way for other possible improvements like mentioned earlier. Also I'm not interested in suggesting anything goes into SVN - this is just a demonstration on how things can be improved. For those interested, I've put what I have up on Github, with a readme: https://github.com/timwebster9/darkmod-build

OK got it to build in my Docker image (using the linuxBuild.sh script), but might be missing a couple of files...? scons: done building targets. real 3m12.136s user 31m43.112s sys 3m35.660s mv: cannot stat 'gamex86-base.so': No such file or directory cp: cannot stat 'tdm_game02.pk4': No such file or directory EDIT: I also notice there are a lot of binaries included in the source, which helps contribute to the large repository size. This is another area where Docker would help - all this stuff would be in the Docker image instead of the source repository and you would have clear separation of code and dependencies. You could also have a different build image for each target platform (Debian, Ubuntu, MacOS, etc). So what this would provide is: - isolated, immutable build environments for all target platforms - reduce repository size by moving binaries and other dependencies to Docker build images (and possibly pave the way to moving to Github - which may help attract more contributors, and make it easier to use free online services. I'm not sure how many support SVN for example...) - provide an easy way for anyone to build the project without having to worry about missing libraries, dependencies, etc Happy to share what I've got so far, and provide more info for anyone who's interested...

OK. That's the first time I've seen that build command, so either I didn't look hard enough or the docs are out of date. I'll give that a try. For the record, I'm only looking at Linux at the moment as well, as that's where all my experience with this stuff is. But obviously getting something working for Windows as well would be just as valuable. What I was thinking of doing was just creating a Docker image for the build environment, and seeing if we could use it in a free hosted CI service (or one that is free for open-source projects at least). Haven't really looked at any of them yet - just wanted to see if there was interest first. Also for it to be truly useful I would also probably want all the steps involved in packaging it up for distribution as well.

OK thanks for the reply. I have no preferences for the 'build system' (i.e. scons), but looking at the Wiki and the COMPILE.txt file in the source it looks like (and correct me if I'm wrong) a fairly manual build process, involving all the usual headaches regarding OS dependencies, configuration drift, 3rd party libraries that have to be compiled, library paths, etc, etc. What is used for a consistent build environment? How do you know if the build is broken? What if it works on one user's PC and not the others? Would using a free CI service (e.g. Travis or Circle) be desirable? I also think I saw that using Github isn't doable because of the size of the repository. Would splitting up the repo between code and assets help? I'm wary of making suggestions without having the full picture - all I have to go by is the Wiki and the readmes in the source code, but if any of this sounds like it's worth looking into I'd be happy to do it.

Just wondering if this ever went anywhere or could use improvement? I've been wanting to offer to help out with this project for ages, but wasn't sure what I could offer. I have a lot of experience with stuff like Docker and automated build systems which might help here. Is there anything I could look at?

I just finished this and managed to totally miss the somehow. Went back to try and find them and still can't - are they possible to find after you've completed the main objective?

Do you reckon the 4GB is worth the extra ££, or does it make no difference?

Thanks - yeah the card was a budget buy (used). Any suggestions for an Nvidia upgrade? It seems for anything decent these days it's at least £100. FYI In my kids' PCs (Core 2 Duos) I put Nvidia GT 710s and we get a very playable 30-60 FPS on those in TDM (although for my next upgrade I'd be looking for something better)..

- Windows 10 Pro - 2x Xeon E5620 Quad Core @ 2.40 GHz (8 cores total) - 12 GB DDR3 1333 MHz RAM - Sapphire Radeon R7 260X 1 GB - 24" Asus VS248HR 1920x1080, 1ms, 50M:1 - Pretty good performance most of the time, slows down a bit in outdoor areas (the worst is Lords and Legacy: 10-20 FPS outdoors near the castle). - I have Ubuntu on the 2nd hard drive but haven't tried TDM on it yet...