mirror of
https://github.com/freedoom/freedoom.git
synced 2025-09-02 07:25:45 -04:00
Freedoom is an entirely free software game based on the Doom engine.
https://freedoom.github.io/
3efe8a0e41
* levels: fix various bugs. Thanks to Goji!, Inuk and rednakhla on Discord for pointing these out. E1M3: Northern lift simplified to address texture alignment problems. E1M5: Door near (-205,1336) (leading out into open ceiling area with the big strip of lights down the middle) door tracks needed to be lower unpegged. E1M9: Lift near (-2328,120) was split into 2 sectors, causing HOMs when they went out of sync. There's nothing that relies on this split (contrast the neat lighting stuff from Map22) so the lift is just merged into one sector. E2M2: Shellbox near (-486,192) is right on the line between two stairs, causing it to rest on the bottom step which causes ports like GZDoom to have the sprite clip *very* visibly into the upper stair. Moved it slightly so it rests on the upper of those two stairs. E2M3: Door leading to red key and "door" leading to soulsphere: former should be lower unpegged but latter should not, but were reversed. Two exit-door-textured doorframes also given more conventional DOORTRAK and lower unpegged treatment. The teleporter representing the hatch going down into the nukage is now fully repeatable. Map07: Infinite height in vanilla would cause the spectres in the red key courtyard to trap the player on the entrance ledge from below in a way that could not be seen or diegetically explained. Those three spectres now warp in only after you cross the ledge. (Setting them to "ambush" would do nothing since you're in LOS with them from the top of the ledge.) Map11: Lights above red keycard weren't aligned; moved that entire sector and added a few lines to round the corner. Removed a strobe effect on the exit teleporter to compensate for a GZDoom issue where the light would go to absolute zero during the blink. Map12: Room to the south with the 2 stimpacks, ammo boxes, 2 chaingunners and berserk would sometimes cause some of the items to be "levitated" to the highest sectors they touch. Moved them away from said higher sectors - it looks a bit sloppier but this is a backroom not a storefront lol. Map13: The easternmost archvile platform had the archvile stuck in the seam, preventing it from lowering in vanilla. (Worked fine in GZDoom) Moved it a little further in. Map19: The combat slugs teleport in from a W1 teleporter which could sometimes be spent while one of the pinkies is blocking the destination, permanently preventing that slug from teleporting in. These are now WRs like the other teleporting enemies. Map22: More W1 monster teleports that should be WR. Also filled in some missing textures in the multi-sector lift connecting the cavern to the hall in the southwest, which parts are clearly not meant to be seen moving separately but can - it still looks fucked up if you manage to desync them, but it's a diegetic fucked up now. Map24: Another W1 spawn. This one is impossible to screw up in vanilla, but there are some mods that could end up spawning something there that could block the archviles from teleporting. Map25: More W1 problems. The spawn source room now also has a small barrier to make sure each pinkie only goes to its own teleporter unless the initial teleport fails. Map27: Lizardbaby dropping too far meant that the bracket was falling along with it in a visibly unnatural way. Map29: Broke up all the long linedefs on the perimeter of the map to get around the invisible hitscan barrier bug: https://doomwiki.org/wiki/Hitscan_attacks_hit_invisible_barriers_in_large_open_areas (Ideally this entire perimeter should be redone to break up the box in favour of more natural-looking formations, but that's a bit outside the scope of a fix like this.) Also got rid of the Plutonia-style start/end teleports on the fixed Phase 2 maps, to address #867. * maps: more fixes. More floaty items and other things. E1M9 - floater mid south stim by staircase E1M7 - floater northwest clips near the tunnels - floaters near switch by railings, now all on the railings - duckproofed sector 439 barrier E2M9 - floater thing #125 medikit on top of lift, now in middle of platform - shotgun guy (thing #309) and the spectre behind it stuck in geometry. - lines 430 and 761 both open the same door and are in the same room right next to each other. Since 761 is actually textured and positioned as a switch, the tag and special on 430 is removed. * levels: flag e2m7 DM stuff as multi-only. Marked the following based on eyeballing out what items are right next to DM spawns with no obvious alternate route to them: 487, 488; 203, 397; 499, 500, 501, 502; 482, 485; 491, 492, 493; 494; 496; 28, 486; 182; 54 * levels: more misc. fixes. E1M6 W1 lines 2318 and 2321. E3M5 Removed all monster block lines in that gross blood room and raised the blood floor to only 4 below the normal floors, but flagged more monsters in there as ambush to make up for it. Also fixed a lot of texture alignment issues in the top skin panels and lowered the ceiling, along with adding a new sector to address texture tiling issues in the northern teleporter room. E4M1 fixed a mysterious HOM that was going on near the northern shadow line in the northern outdoor area. Merged a lot of sectors that were identical in their properties. E4M7 entrance to sector 985 seems to be intended that the player run off the ledge into that room, then the pinkie near the ledge ambushes the player from behind. Instead, what sometimes happens is that the pinkie is alerted somehow, then obstructs the player (vanilla infinite height) from being able to get down there. That means of getting down into that room is now walled off, and instead you step onto that lift to bring it down from above. Neat side effect: any monsters still in the ring when you enter that room will follow you down there. E4M5 linedefs 1724 and 1725 were facing the wrong way and couldn't be hit with projectiles. Map25 Float thing 217. Moved that entire row further south to address floating item issues. Map28 Float thing 464. * levels: use inner room texture in E4M7 lift. * levels: align side textures on that lift. Didn't realize the little squares were sticking into the floor at the *bottom* of the lift as well. |
||
|---|---|---|
| .github/workflows | ||
| bootstrap | ||
| dist | ||
| flats | ||
| graphics | ||
| levels | ||
| lumps | ||
| manual | ||
| musics | ||
| patches | ||
| scripts | ||
| sounds | ||
| sprites | ||
| .adoc-layout.conf | ||
| .gitattributes | ||
| .gitignore | ||
| BUILD-SYSTEM.adoc | ||
| buildcfg.txt | ||
| COMPILING.adoc | ||
| COPYING.adoc | ||
| CREDITS | ||
| Makefile | ||
| NEWS.adoc | ||
| README.adoc | ||
= Freedoom The Freedoom project aims to create a complete, free content first person shooter game, but _Freedoom_ by itself is just the raw material for a game. It must be paired with a compatible _Doom_ engine to be played. There is a massive https://doomwiki.org/wiki/Idgames_archive[back catalog], spanning over two decades, containing thousands of _Doom_ levels and other modifications (“mods”) made by fans of the game. _Freedoom_ aims to be compatible with these and allows most to be played without the need to use non-free software. _Freedoom_ is actually three games in one, consisting of two single-player oriented campaigns and one set of levels designed exclusively for multiplayer deathmatch: [horizontal] *Freedoom: Phase 1*:: Four episodes, nine levels each, totalling 36 levels. This game aims for compatibility with _The Ultimate Doom_ mods, also known as plain _Doom_ or _Doom 1_. *Freedoom: Phase 2*:: 32 levels in one long episode, featuring extra monsters and a double-barrelled shotgun. This project aims for compatibility with _Doom II_ mods. *FreeDM*:: A 32-level game designed for competitive deathmatch play. The engine uses a single file, such as +freedoom2.wad+, that contains all the game data such as graphics, sound effects, music, and so on. This file is often called an “IWAD” by those in the _Doom_ and _Freedoom_ communities. While the _Doom_ engine source code is free, you would normally still need one of the proprietary data files from https://www.idsoftware.com/[id Software] to play _Doom_. _Freedoom_ aims to create a free alternative: combined with the GPL-licensed _Doom_ source code, this results in a completely free game. For more information, see https://freedoom.github.io/. == How to play Since _Freedoom_ is only the game data, you will still need to download an engine separately. These are also often termed “source ports” by the community. There are an overwhelming number of choices available, a lengthy list of which is available on the https://doomwiki.org/wiki/Source_port[Doom Wiki]. One particularly recommended by the _Freedoom_ project is https://zdoom.org/[GZDoom]. This engine offers good support for single-player, multi-player, and the majority of mods created for both _Doom_ and _Freedoom_. On Windows, you should place _Freedoom_’s data files (those ending with +.wad+) alongside the engine (eg, +odamex.exe+). On Unix-like systems, these data files should go in either +/usr/share/games/doom+ or your home directory. If _Freedoom_ comes packaged as part of your operating system distribution, it should already be installed into the proper location. Hopefully, your engine of choice should already be capable of running _Freedoom_ without extra configuration. This may not be the case, however, if the engine does not recognize any of the filenames for _Freedoom_, and might require manual intervention to make it so. One of the following options should solve it: * Use the +-iwad+ command line parameter. For example, to play Phase 2, you can enter +-iwad freedoom2.wad+ either at a command line, or adding it to an application shortcut. * Use the +DOOMWADPATH+ environment variable. Many engines support this variable to add directories and/or files to their search path. The exact syntax matches your operating system’s normal +PATH+ environment variable. * Rename the game files. This may be a bit crude, but you can rename the files to match those of _Doom_’s. This is often the easiest quick-fix, although it is normally desirable to use one of the above methods if possible. ** +freedoom1.wad+ can be renamed to +doom.wad+ ** +freedoom2.wad+ can be renamed to +doom2.wad+ ** +freedm.wad+ can be renamed to +doom2.wad+ Additionally, for Unix-like operating systems, such as GNU/Linux or a BSD variant, _Freedoom_ may be packaged and installed with programs named +freedoom1+, +freedoom2+, and +freedm+ that automatically run an engine for proper play. Desktop files may also be installed so that you can start the game using a graphical interface and avoid the command line altogether. == What “free” means When we speak of free content or software, we refer to the movement in which your freedoms to use, copy, modify, and study a work is not infringed. For example, you may freely use _Freedoom_ for any purpose you see fit, you may redistribute it to anyone without needing to ask for permission, you may modify it (provided you keep the license intact, see `COPYING`), and you may study it--for example, to see how an “IWAD” is built. To facilitate this, you can get the full source code for _Freedoom_, in this case, in the form of a DeuTex tree. You may read more about free software at the https://www.gnu.org/[GNU] and https://www.fsf.org/[Free Software Foundation] websites. == Contributing to Freedoom Contributions to _Freedoom_ are always welcome, however there are a few guidelines that should be followed: === Intellectual property We know people hate legalese, but this is important. This applies to *everything* which is submitted. You must be careful when basing on existing graphics or sounds. Most _Doom_ projects are lax on reusing intellectual property--there are many mods which contain modified _Doom_ sprites, for example. However, due to the nature of this project, we do not have the same liberty to rip as we please. The general rules go as follows: * You must have permission for everything you submit. If you make your own resources, do not base on resources from _Doom_ or any other restricted work. If you take work from other places, please make sure that the work is freely-licensed or that you obtain permission to include it in the _Freedoom_ project. They may not place additional restrictions compared to the normal _Freedoom_ license. * Do not try to emulate _Doom_ resources exactly. Where possible, put effort to make new versions look visibly different from _Doom_. This is a tough call, because our compatibility with _Doom_ mods limits how far we can deviate, but it is feasible. * Be especially careful of “free textures” (or “free sounds” or “free graphics”) sites. Although these would appear at first to be okay to use, many are free for “non-commercial use only.” One of the things we want to be able to do is put this in GNU/Linux distributions (which can be sold or developed commercially). === Levels All levels for _Freedoom_ must be vanilla-compatible, requiring an expanded-limits or limit-removing engine is not permissible. This means you may not exceed the limits of the original _Doom_ engine, and do not depend on additional mapping features. Levels should be in _Doom_’s original format, not in “Hexen”-format. It is sensible to also heed the following guidelines: * Make sure that skill levels are implemented, and that all multiplayer start points, both cooperative and deathmatch, are present. * Try to make levels appropriately difficult for their position within the progression of the game. Also bear in mind that not all players may be as skilled a player as you. * Do not use tricks that exploit _Doom_’s software renderer; some engines, especially those that use hardware accelerated rendering, may not render it properly. Examples of tricks to avoid include those used to simulate 3D bridges and “deep water” effects. * While unrestricted by limits, do not make excessively complicated scenes. It is desirable that _Freedoom_ levels should be playable on low-powered hardware, such as phones and old computers. * Test your levels in https://www.chocolate-doom.org/[Chocolate Doom] to make sure that vanilla compatibility is maintained. This is an engine with strict adherence to vanilla Doom limits and bugs, and working in it assures that levels can be played with any _Doom_ engine. * Use a Doom editor to check for errors. In http://eureka-editor.sourceforge.net/[Eureka] it's possible to check for errors with the Check / All menu, or by pressing `F9`. * If possible run `make test` and fix any errors found. Note that some of the errors can be fixed by `make fix`. === Graphics Graphics should generally have the same color and size as the original _Doom_ graphics, as to remain compatible with mods. Otherwise, levels may end up looking like a nightmare in design. They may be thematically different as long as it doesn’t clash. _Doom_ uses a fictional corporation abbreviated as “UAC:” this is trademarked by id Software and cannot be used in _Freedoom_. Instead, use the initials “AGM” for _Freedoom_. === Documentation _Freedoom_ always needs help with documentation, so please send your patches, but keep in mind: * We use http://asciidoc.org/[AsciiDoc] for writing the documentation. AsciiDoc is a simple plaintext-based format which is simple to read and write in its source form, and can generate nice HTML documents out of them. * Headers are formated in a wiki-style format, this makes it easier for Vim (perhaps other editors, too) to automatically re-format text. * Text is kept at 72 characters wide. In Vim, you can set the editor to automatically insert line breaks as you’re typing by performing `set textwidth=72`. Special exceptions to the width rule might be allowed when necessary (for example, inserting long URLs). === Submitting your work The most common, and a fairly simple method, to submit your work is by posting it on the https://www.doomworld.com/forum/17-freedoom/[Freedoom forum] on Doomworld Forums. This allows a great number of people to review the contribution and provide feedback, although the registration process is known to be cumbersome. An alternative to using the forum, is to post your submission on the https://github.com/freedoom/freedoom/issues[issue tracker], which may also be peer-reviewed and provide a feedback cycle. Unfortunately, the Freedoom project cannot provide hosting space in the form of a web page nor FTP, however there are many free file hosts to use when you need a location to upload files. Sites and services such as https://www.dropbox.com/[Dropbox] and https://mega.co.nz/[Mega], as well as others, are common and should be simple to use. ==== Crediting information _Freedoom_ is made up of submissions from many people all over the globe. All of them, and you, deserve credit! Please do not forget to provide your name and email when submitting resources. ==== Using Git You can also commit on a clone of the _Freedoom_ repository, although this is a technical task and it is okay to let other _Freedoom_ maintainers to do it instead: that is our normal mode of operation. However, pull requests are much appreciated and you may submit them in any manner you wish, with GitHub’s direct pull requests being the simplest, but by far not the only means. Freedoom uses the commit message style commonly seen in distributed version control systems, adopted by projects such as Linux and Git. For an explanation of this style, see https://chris.beams.io/posts/git-commit/[How to Write a Git Commit Message]. If you create a git commit for someone else it is helpful to set the author of the commit so that they get credit. Ask them what name/alias and email they would like to use. For example: [source,bash] ----------------- git commit --author "Bob Smith <bob@example.com>" ... ----------------- If they prefer not to give an email then the email can be omitted, so just "Bob Smith" in the above example.