id Software has released the source code to their classic game, Doom, under the GNU General Public License. This means that the engine which powers Doom is Free Software. However, the game engine is only one component of a complete game.The Doom engine uses an "IWAD" file to store all of its game data. This contains the raw data used by the game — the artwork, sound effects, levels, everything which defines Doom as a game. Until now, one of the original proprietary files was still needed in order to play Doom.The Freedoom project aims at collaboratively creating a free IWAD file. Combined with the free source code, this results in a complete game based on the doom engine which is Free Software.
Freedoom has multiple purposes:
A modern limit-removing source port is needed to play Freedoom. We recommend one of the following ports:
PrBoom GNU GPL GNU/Linux, *BSD, Mac OS X, other POSIX, WindowsSoftware, OpenGL
Odamex GNU GPL GNU/Linux, *BSD, Mac OS X, other POSIX, WindowsSoftware, OpenGL
ReMooD GNU GPL GNU/Linux, *BSD, Mac OS X, other POSIX, WindowsSoftware
The Eternity Engine GNU GPL DOS, WindowsSoftware
Boom GNU GPL DOS onlySoftware
Risen3D GNU GPL Windows onlyOpenGL
It is possible to run it with Chocolate Doom, although it requires a special workaround.
There is another project attempting to remake Heretic in a Free Software format (Blasphemer).
A new project recently has started to remake Hexen (Zauberer).
Hi everyone!
Publishing a new version at the end of April it's starting to become some kind of ritual...
Once again, special thanks to eviltechno, who helped me a lot with the testing of the Windows version and by suggesting almost all the new features, without him probably this version would end up be just a Linux port. Speaking of Linux, v2.5 is the first DML 2.X version that is NOT a Windows exclusive (more on that later).
Without further ado, here the full changelog. Below you will find a more in-depth explanation of the main new features.
(This is the latest changelog. You can read all changelogs here P36software.net)
As for this version, the only tested sourceport are (Remember that as long as it follows the zdoom command line standard, any engine should work fine):
FULL COMPATIBILITY:
PARTIAL COMPATIBILITY (Some DML features will not work):
Let me explain a bit the most interesting features:
Now it works under Linux/Mac through mono (Be sure to have downloaded the mono version, the one with "mono" in the exe name, and follow the instructions otherwise it will not work!)
There are now 2 version available for download, the "Windows" and the "mono" version.
If you're on windows you just need an up-to-date windows system (7/8.1/10) and .net framework 3.5, so the same requirements as any other DML release.
If you're on Linux/Mac OS you'll need to install "mono" on your OS, which is an open-source equivalent of .net framework and enable .net framework windows executable to run on non windows OS.
Note that while it SHOULD run on Mac OS, I've NEVER tested it under that OS as I don't own a Mac. While on Linux I've been using it on Linux Mint since I started the port. While both "Windows" and "mono" downloads are in the end a windows .exe, the "mono" version have a few difference that I had to make in order to make it run under mono. You will find the download for the mono version and more detailed instructions here (as it's NOT a native Linux/MacOS application) Github.com
Also, only on Linux (can confirm on mac os as I don't own one) as a plus I've not coded but came free by using mono... DARK THEME! It follows your system settings, if you're using a light theme it will look similar to how it looks on windows. As it's not something that I've coded, there is no way to toggle it via DML 2.X itself.
Added a workaround that mitigate the gzdoom bug where quicksave made with 'BIND [KEY] "SAVE QUICKSAVE.ZDS"' are saved in the wrong folder. Can be enabled in DML 2.X preferences. (Windows/Linux only) .
This gzdoom (and also Zandronum, being it based on an older gzdoom version) bug as hunted me for quite a while, I had sometimes someone reporting it to my and I couldn't recreate it, until eviltechno explained to me this alternative quicksave method. While gzdoom have already a ready to use quicksave function, it will prompt the first time the user to select the saving slot, and from the second time (until the software is closed if I recall correctly) will ask for confirmation. To some user this is an unacceptable 2 step process, so by using the console command written above, replacing [KEY] with any keyboard key ("F6" for example), the user can make a "very-quick-quicksave™", that will create and overwrite over and over again a "quicksave.zds" without asking for slot or any kind of confirmation. The issue was that on Windows this quicksave.zds file, if the gzdoom process was started from another process, it would not be created in the "Save" folder next to the gzdoom executable but instead it would create it next to the DML 2.X exe. Until gzdoom it's running it will still save/load fine, but once it's closed, the next time you boot it up you're savegame will be missing from the list, while it's still there next to dml 2.x, but gzdoom looks only in the save folder, as it's where all save should normaly be.
This does not happen if you use the normal quicksave or don't use a frontend, and I don't know why it happens, my guess it's that inside gzdoom there should be some kind of function that generate a path to where the save file, based on the gzdoom exe location, but that somehow it get "confused" if the gzdoom process is started via another software, and that maybe it mistake the DML 2.X as the gzdoom process and so it mess up the location, but I really don't know. On linux it's also bugged, but it saves it in the user "home" folder.
So my "solution" (which is really a workaround since I can't really fix this) it's to look for any .zds file in the dml 2.x folder (or "home" folder on linux) and moving it to the correct one (which is different in windows and linux) once you've closed the sourceport. Note that has been tested only with recent version of gzdoom/zandronum and on linux as been tested with only version installed trough apt. If for any reason future gzdoom/zandronum releases change saving location this fix will stop working, so by default it's disabled. You can enabled it in the DML 2.X "preferences" window. If you don't use quicksave made trough the custom method explained above you don't need to enable it as this gzdoom bug it's not afflicting the normal saves/quicksaves. If you're on Mac OS do not enable it because it will not work. Take a look to the readme for more info.
Now the mod that you always use can be placed in a preset and loaded automatically each time you play, just select the preset in the "autoload" combobox in the "Game" section of DML 2.X.
This one is if you have a few "quality-of-life improvements" mod that you always play, like the doom minor sprite fixing project, or for example a sound replacement for the plasmagun etc... With this new feature you can select one preset, as an "autoload preset" in the game section. The idea is that you make one (ore more) autoload preset that contains only your quality-of-life improvements" mods (I personally have one general autoload preset and one for tnt.wad, that include also the secret level yellow key fix). The autoload preset mods will load in the order you've setted them up in the mod list, AFTER all other mods, so they always have the priority over anything you load. Take a look to the readme for more info.
Updated the renderer selection in order to work with the newest gzdoom releases.
Since a few updates ago, gzdoom no longer have a single renderer option, but your render it's selected by using two values, one for the API backend (the value on the left is the backend on posix system like Linux/MacOS while the second value it's on Windows) and the other one it's for the render mode itself. If unsure on what those setting means or you're using an older gzdoom version that still use the old system, leave it to the "DONT OVERRIDE" setting or select "SDL + OPENGL | OPENGL" and "HARDWARE ACCELERETED (OPENGL)" or "DOOM SOFTWARE RENDERER". From my experience and by reading some post, the vulkan backend might be a bit faster then the opengl one if you're running recent hardware, the GLES2 it's usually the best on old/low end hardware but it may have some graphical issue in complex mod. Try to play around with them, personally having a 8 years old machine running Linux Mint I use the GLES2 for the newset and complex mapset that require hardware acceleration, I use opengl with doom software renderer for old classic mod/ original IWAD and i use the standard opengl hardware acceleration for older gzdoom mod (like Psychophobia). Take a look to the zdoom wiki for more info zdoom.org.
Note that this option overwrite the relative values in the gzdoom ini, it's not just a per-session setting, so the "DONT OVERRIDE" option will not override the current settings, but if the current setting it's already been changed by a previous launch it will still use the last selected renderer and not the "original" one.
Also note that while the newer version seems to no longer support the old softpoly software rendererers, I've still leave them in the list (with an "unsupported" warning) so if you need them, and you're using an older gzdoom version you can still use that renderer.
Also if using an older gzdoom version that does not use the 2 values but just the +vid_rendermode one, select "SDL + OPENGL | OPENGL" in the +vid_preferbackend field and then select the renderer like you would have done in an older DML 2.X version
Since 2.2b I've been saying that this version will be the last, and here we are 3 main updates later, where I still say that this version will be the last. Well, sort of... Let me explain: The more I've worked on the project the more I've realized of bad I've made it's "foundations".
It all started in 2016 as an experiment as I was learning VB6 at school (yeah, the 90' language... you still be surprised that it's actually quite used in today business, in the last place I worked this basic (pun intended) VB6 knowldege has come handy as the main project I worked on was a revamp in C# of an old VB6 set of softwares). DML 1.X is a VB.NET software but the syntax was quite similar to VB6. At the begginning of 2019 I've started working in a software house that coded mainly in C#, so to experiment with the language I've had started working on DML 2.X, for like half a year it sitted only as a GUI (no code logic was written) in my hard drive.
Later I decided to finish it, so I started working on it on and off in my spare time and in July 2019 I've release the first version of it. It really started as a one off project, something that I will publish an probably forget about really soon. But I started to get some attention, people started giving me feedbacks and suggesting new features, so I've started adding this features, and updating my software, but as at the time I didn't really any do any reaserch about "winform", so I didn't know it has been for a long time a dead platform. Also as I didn't know how to "plan" a software, and If a knew how to do it I still wouldn't probably care to do it as tought this will be one of my many "one off" projects. If you noticed I've started calling 2.X only from later releases (the software logo/icon still says "DML 2.0" to this very day!). So it ended up being a project really hard to maintain and to work on it, there are still some feature that I would have included but are still missing as those either required some wacky hack to work on winform or require ti have to change to much stuff, as again this project has really bad foundations, that were fine for what I think at the time of the project, but not adequate for what it become.
So from this release, excluding an eventual 2.5b for bugfixing, the 2.X brench of the project have reached it's end. Does it mean this is the LAST ever DML release? No. There WILL be a next future release. I plan to start a new 3.X version from scratch, but this time having some good, strong foundations. I plan a better, more modern and resizeble GUI, full support for non zdoom like sourceport, a true standalone version for Linux (and hopefully Mac OS) plus all the missing features that I've not been able to add, and a dark theme also for windows user. So will this 3.X version come out soon? Once again, no. Given that I also want to dedicate more time to my other project, and that I've also kinda starting a bit to burn out more and more with each DML release, and given that other that the few lines above I've have absolutely zero ideas on how to do it, it will take quite some time, probably years before the first 3.X version is out. But yeah this project it's not dead :)
The mono version does NOT have a new version notification and require some extra step in order to work. Read carefully the download page! Also remember that it should work on Mac OS, but I couldn't test it, not even booting it up. So maybe it wont even start. Or maybe you need to do some more extra step that I don't knwo nothing about.
For the next few hours the windows version will prompt you to download the 2.4, which of course it's the old version. Once I've update the version number on my server it will stop doing that.
I usually update the server version number as the last step I do in a release because it will rollout the update notification to the over 6000 users of the 2.4, so I'm very careful and release it very slowly, before on github, then on modb, then I made a moddb news and only later the full rollout, once I'm sure there is nothing wrong with the release.
Long story short, on the mono version the update notification is missing and you'll have to check it out manually on github (or my twitter @p36software) and for the windows version ignore the new version notification, I'll update it in a day or two
If you're upgrading from an older version, you will find the instructions in the download page, be sure to backup your CONFIG folder somewhere, so if anything goes wrong while updating to the new version you don't have to reconfigure everything from scratch.
Also note that you made need to update your presets in order to work with the new settings, to do that, just save again the preset by verifying that all checkboxs of the information you want to save in a preset are checked and click "update". This will update the preset in order to be 100% compatible with the new version. You don't need to to that for all preset, just for the one that you've stored the renderer. All older preset should work out of the box (Take a look to the "how to update from an older DML 2.X version" section in the download page for more info)
(NOT A NATIVE APPLICATION, READ THE INSTRUCTIONS BEFORE DOWNLOADING!)
If you find any bug with this version please report it trough github (if you're familiar with it), or by sending an email at support@p36software.net with subject "DML 2.5 *Here your OS* Bug - *Here describe the bug in a few words*" and in the mail itself try to explain with much accuracy and details as possible what happened, what did you expect it should have happened and a step by step guide on how to reproduce it, as if I can't reproduce it on my end, I can't fix it.
If you're interested in my softwares, games, open source projects or just want to contact me, you can find me here: Website: P36software.net
Support e-mail: support@p36software.net (for reporting bug/give feedback/ask for help)
Info e-mail: info@p36software.net (for anything else)
Twitter: Twitter.com (@p36software, gets updated more often)
Github: Github.com
ModDB: Moddb.com
IndieDB: Indiedb.com
Youtube: Youtube.com
Once again, thanks for your support, you're all amazing! <3
-Matteo
After a year in the making, the new version of DML 2.X is out! This version packs quite a few bugfixes and new features, like unofficial games (.iwad/.ipk3...
DML 2.X source code is now available on Github! Version 2.2b is out!
The new version od DML is out with a lot of new features!
All FreeDoom Versions from Version 1 all the way to the May Autobuild. (The wad named Freedoom-v12-0 is the may autobuild.)
This WAD adds an episode to Phase 2 , that contains all the maps that were deleted over time in Phase 2 Builds.
This WAD adds an episode to Phase 2 , that contains all the maps that were deleted over time in Phase 2 Builds.
A little WAD that adds Black Gloves to FREEDOOM'S weapons , something I made just for the sake of it.
I actually meant to do this a while ago , but seemed to have forgotten . Anyways it's done now , The Soviet patch for Freedoom. -Enjoy...
Freedoom Complete Enhanced 1.0 version Currently includes: Freedoom 1 and 2; Nashgore; Smooth Weapons; Fluid Water; and brightmaps
Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.
Really amazing. The iwad should get a higher score than that.
I noticed that on the new shotgun sprite you're not wearing gloves.
Glad Doom source code is out, you made a very cool game. :D
Yeah, Freedoom is not a replacement though, its more like a different take. Doom from an alternate dimension where Doomguy is a prisoner in some offworld convict labour outpost, possibly a ex-marine that becomes a hero because of circumstance and not because hes a ultimate badass, and the enemies are not from hell but are straight up alien scum who made a deal with the humans for some peace treaty only to turn against humanity after taking control of some of the prisoner colonies and turning the prisoners (AGM coverts them into mindless drones to do the labour who are capable of receiving signals and follow commands) into shock troops by activating their aggressive impulses through alien technology interfering with their normal signals, destablising the whole place and setting you from your cell. Its probably going to take another 2 years for FreeDoom to be complete and the story to be fully fleshed out but yeah its still optional to the regular doom experience.
I thought you were part of the brutal doom community?
I like the idea of FreeDoom. The engine is open-source, so naturally people should take advantage of that fact. However, some of the monsters look a bit poor. I would like to try my hand at making my own monsters for the project, (I am an hobby artist) but I am using Windows Vista and things like XWE do not work very well. Is there some other way I can import monsters? The worst that can happen is that they won't look very good either, but it couldn't hurt for me to try.
John 3:16 "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life."
/John 3:16 "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life."/
:)
Make sure you read all of that chapter. Very important stuff.
yeah, but im not there yet. im still in the old testament.
Still needs a better plasma gun pickup sprite. I mean come on! The existing one looks nothing like the HUD sprite.