pk3make 1.1__tar.gz

pk3make-1.1/.github/workflows/python-publish.yml

@@ -0,0 +1,70 @@
+# This workflow will upload a Python Package to PyPI when a release is created
+# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries
+
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+name: Upload Python Package
+
+on:
+  release:
+    types: [published]
+
+permissions:
+  contents: read
+
+jobs:
+  release-build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.x"
+
+      - name: Build release distributions
+        run: |
+          # NOTE: put your own distribution build steps here.
+          python -m pip install build
+          python -m build
+
+      - name: Upload distributions
+        uses: actions/upload-artifact@v4
+        with:
+          name: release-dists
+          path: dist/
+
+  pypi-publish:
+    runs-on: ubuntu-latest
+    needs:
+      - release-build
+    permissions:
+      # IMPORTANT: this permission is mandatory for trusted publishing
+      id-token: write
+
+    # Dedicated environments with protections for publishing are strongly recommended.
+    # For more information, see: https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-protection-rules
+    environment:
+      name: pypi
+      # OPTIONAL: uncomment and update to include your PyPI project URL in the deployment status:
+      # url: https://pypi.org/p/YOURPROJECT
+      #
+      # ALTERNATIVE: if your GitHub Release name is the PyPI project version string
+      # ALTERNATIVE: exactly, uncomment the following line instead:
+      # url: https://pypi.org/project/YOURPROJECT/${{ github.event.release.name }}
+
+    steps:
+      - name: Retrieve release distributions
+        uses: actions/download-artifact@v4
+        with:
+          name: release-dists
+          path: dist/
+
+      - name: Publish release distributions to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist/

pk3make-1.1/.gitignore

@@ -0,0 +1,171 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
+.pdm.toml
+.pdm-python
+.pdm-build/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# PyPI configuration file
+.pypirc

pk3make-1.1/LICENSE

@@ -0,0 +1,157 @@
+# GNU LESSER GENERAL PUBLIC LICENSE
+
+Version 3, 29 June 2007
+
+Copyright (C) 2007 Free Software Foundation, Inc.
+<https://fsf.org/>
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+This version of the GNU Lesser General Public License incorporates the
+terms and conditions of version 3 of the GNU General Public License,
+supplemented by the additional permissions listed below.
+
+## 0. Additional Definitions.
+
+As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the
+GNU General Public License.
+
+"The Library" refers to a covered work governed by this License, other
+than an Application or a Combined Work as defined below.
+
+An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+A "Combined Work" is a work produced by combining or linking an
+Application with the Library. The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+## 1. Exception to Section 3 of the GNU GPL.
+
+You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+## 2. Conveying Modified Versions.
+
+If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+-   a) under this License, provided that you make a good faith effort
+    to ensure that, in the event an Application does not supply the
+    function or data, the facility still operates, and performs
+    whatever part of its purpose remains meaningful, or
+-   b) under the GNU GPL, with none of the additional permissions of
+    this License applicable to that copy.
+
+## 3. Object Code Incorporating Material from Library Header Files.
+
+The object code form of an Application may incorporate material from a
+header file that is part of the Library. You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+-   a) Give prominent notice with each copy of the object code that
+    the Library is used in it and that the Library and its use are
+    covered by this License.
+-   b) Accompany the object code with a copy of the GNU GPL and this
+    license document.
+
+## 4. Combined Works.
+
+You may convey a Combined Work under terms of your choice that, taken
+together, effectively do not restrict modification of the portions of
+the Library contained in the Combined Work and reverse engineering for
+debugging such modifications, if you also do each of the following:
+
+-   a) Give prominent notice with each copy of the Combined Work that
+    the Library is used in it and that the Library and its use are
+    covered by this License.
+-   b) Accompany the Combined Work with a copy of the GNU GPL and this
+    license document.
+-   c) For a Combined Work that displays copyright notices during
+    execution, include the copyright notice for the Library among
+    these notices, as well as a reference directing the user to the
+    copies of the GNU GPL and this license document.
+-   d) Do one of the following:
+    -   0) Convey the Minimal Corresponding Source under the terms of
+        this License, and the Corresponding Application Code in a form
+        suitable for, and under terms that permit, the user to
+        recombine or relink the Application with a modified version of
+        the Linked Version to produce a modified Combined Work, in the
+        manner specified by section 6 of the GNU GPL for conveying
+        Corresponding Source.
+    -   1) Use a suitable shared library mechanism for linking with
+        the Library. A suitable mechanism is one that (a) uses at run
+        time a copy of the Library already present on the user's
+        computer system, and (b) will operate properly with a modified
+        version of the Library that is interface-compatible with the
+        Linked Version.
+-   e) Provide Installation Information, but only if you would
+    otherwise be required to provide such information under section 6
+    of the GNU GPL, and only to the extent that such information is
+    necessary to install and execute a modified version of the
+    Combined Work produced by recombining or relinking the Application
+    with a modified version of the Linked Version. (If you use option
+    4d0, the Installation Information must accompany the Minimal
+    Corresponding Source and Corresponding Application Code. If you
+    use option 4d1, you must provide the Installation Information in
+    the manner specified by section 6 of the GNU GPL for conveying
+    Corresponding Source.)
+
+## 5. Combined Libraries.
+
+You may place library facilities that are a work based on the Library
+side by side in a single library together with other library
+facilities that are not Applications and are not covered by this
+License, and convey such a combined library under terms of your
+choice, if you do both of the following:
+
+-   a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities, conveyed under the terms of this License.
+-   b) Give prominent notice with the combined library that part of it
+    is a work based on the Library, and explaining where to find the
+    accompanying uncombined form of the same work.
+
+## 6. Revised Versions of the GNU Lesser General Public License.
+
+The Free Software Foundation may publish revised and/or new versions
+of the GNU Lesser General Public License from time to time. Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Library
+as you received it specifies that a certain numbered version of the
+GNU Lesser General Public License "or any later version" applies to
+it, you have the option of following the terms and conditions either
+of that published version or of any later version published by the
+Free Software Foundation. If the Library as you received it does not
+specify a version number of the GNU Lesser General Public License, you
+may choose any version of the GNU Lesser General Public License ever
+published by the Free Software Foundation.
+
+If the Library as you received it specifies that a proxy can decide
+whether future versions of the GNU Lesser General Public License shall
+apply, that proxy's public statement of acceptance of any version is
+permanent authorization for you to choose that version for the
+Library.

pk3make-1.1/PKG-INFO

@@ -0,0 +1,138 @@
+Metadata-Version: 2.4
+Name: pk3make
+Version: 1.1
+Summary: Build system for Weissblatt PK3 files
+Project-URL: Homepage, https://github.com/liquidunderground/pk3make
+Project-URL: GitHub, https://github.com/liquidunderground/pk3make
+Project-URL: Issues, https://github.com/liquidunderground/pk3make/issues
+Author-email: Zibon Badi <zibonbadi@gmail.com>
+License-Expression: LGPL-3.0-or-later
+License-File: LICENSE
+Classifier: Environment :: Console
+Classifier: License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+)
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Build Tools
+Requires-Python: >=3.12
+Requires-Dist: colormath2
+Requires-Dist: natsort
+Requires-Dist: pillow
+Description-Content-Type: text/markdown
+
+# PK3Make
+
+"Make" for Weissblatt PK3 files
+
+## Installation
+
+1. Set up a [virtual environment](https://docs.python.org/3/library/venv.html)
+2. Install dependencies `pip install -r requirements.txt`
+
+## How to use
+
+PK3Make supplies multiple subcommands. To get an overview type:
+
+    ./pk3make.py --help
+
+To fully build your project akin to a makefile, simply type:
+
+    ./pk3make.py make ./PK3Makefile # Default PK3Makefile
+
+### Notes, Tips and Caveats
+
+All text files are assumed to be UTF-8 encoded. PK3Make will automatically attempt to convert CRLF to LF newlines but using LF newlines is recommended.
+
+PK3Make will not find hidden files. To avoid `DuplicateLumpError`s, place
+  your workfiles in a hidden directory, for example `.local/`.
+
+Should your project contain custom palettes,  place it's corresponding
+  LUMPDEF before any `graphic`, `flat` or `fade`. That way, PK3Make can
+  cache your palettes and speed up build times by reducing thread idle.
+
+
+## But why?
+
+To put it bluntly: No other tools suited Weissblatt.
+
+Although the PK3 specification for Weissblatt's engine is based on
+[ZDoom PK3](https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement),
+it's directory namespaces are very different. This made Doom's usual
+autobuild toolkit [DoomTools](https://mtrop.github.io/DoomTools/) a
+poor fit for development. Due to the size of the Weissblatt project, manual
+assembly using SLADE was also out of the question.
+
+I chose Python as the basis for PK3Make because it is platform-independent,
+easy-to-read and ubiquitous and although some Doom/Weissblatt-specific
+modules needed to be written from scratch for PK3Make, Python's vast
+standard library and otherwise mature PyPI repository helped stem some
+of the heavy lifting for things such as image processing.
+
+# PK3Makefile reference
+
+PK3Make uses it's own build definition language called `PK3Makefile`, inspired by the `METAINFO` spec from
+[Matt Tropiano's dImgConv](https://mtrop.github.io/DoomTools/dimgconv.html).
+
+`PK3Makefile`s are processed line-by-line with everything following `#`
+being treated as a comment. Otherwise it is split into *Build Options*,
+which define PK3Make's general behavior and *LUMPDEFS*, which define what
+files to put into your PK3 and how to build them.
+
+## Build options
+
+Build options are specified per-line and follow the pattern
+
+    ?<OPTION>: <PARAM>
+
+PK3Make supports the following options:
+
+`?srcdir: <DIR>` specifies the directory to pull it's base assets from.
+PK3Make will attempt to find all defined lumps within this folder and
+mirror it's path within `?workdir` after compilation.
+
+`?workdir: <DIR>` specifies the temporary working directory. PK3Make will
+check the timestamps between this and `?srcdir` and rebuild/copy any
+outdated files into `?workdir` during the compilation process.
+
+`?palette:` defines the main color palette, by `LUMPNAME` (`PLAYPAL` by default)
+
+`?destfile:` describes a filepath to the destination PK3. This is where
+`?workdir` will get copied to during packing.
+
+
+## Lump definitions
+
+Lump definitions follow the following pattern:
+
+    <LUMPNAME> <TYPE> <OFFSET>
+
+`LUMPNAME` describes the filename as used in-engine. Just like the engine,
+it is matched against the first eight characters of the basename in a
+case-insensitive manner.  [Globbing] such as `D_*.mid` is allowed, in which
+case `TYPE` and `OFFSET` are applied to all matching lumps.  `LUMPNAME`s
+starting with a "/" are treated as explicit file paths and match against
+the full file path, starting at the source directory.
+
+[Globbing]: <https://en.wikipedia.org/wiki/Glob_(programming)>
+
+`TYPE` determines how the file is treated during compilation. It can be one
+of the following:
+
+- `colormap`: File is a Colormap. OFFSET specifies the lump name for the palette from which it is generated
+- `fade`|`flat`: File is an image and should be converted to a flat. Only PNG images are supported.
+- `graphic`: File is an image and should be converted to a Doom Picture using `OFFSET` (see below) as a picture offset. If missing, the offset is assumed to be `0 0`.
+- `marker`: File does not exist and is a 0-byte marker. Explicit path definition required.
+- `palette`: File is a graphic and should be converted to a color palette. Only PNG images supported.
+- `raw`: Copy the file over as-is. When `preserve_filename` is given in the offset, the original filename will be preserved.
+- `tinttab`: File is a TINTTAB. OFFSET is defined as `<PALETTE> <WEIGHT>`. Upon generation, `PALETTE` orthogonally maps each color index against one another, `WEIGHT` specifies a bias towards horizontal/vertical colors between 0 and 1.
+- `udmf`: (Not supported yet.) File is a UDMF TEXTMAP. PK3Make will generate a directory named LUMPNAME featuring:
+  - `<LUMPNAME>`: Marker
+  - `TEXTMAP`: Original TEXTMAP file (renamed)
+  - `ZNODES`: UDMF BSP tree generated by PK3Make
+  - `ENDMAP`: Marker
+
+`OFFSET` defines the offset of doom pictures. For convenience, these can be either:
+
+- `<x> <y>`: Explicit X/Y-coordinates
+- `center`: Sets the offset to the center of the image
+- `sprite`: Sets the offset to `width/2 (height-4)`. This is a very common
+  offset for sprites placed in the game world.

pk3make-1.1/README.md

@@ -0,0 +1,117 @@
+# PK3Make
+
+"Make" for Weissblatt PK3 files
+
+## Installation
+
+1. Set up a [virtual environment](https://docs.python.org/3/library/venv.html)
+2. Install dependencies `pip install -r requirements.txt`
+
+## How to use
+
+PK3Make supplies multiple subcommands. To get an overview type:
+
+    ./pk3make.py --help
+
+To fully build your project akin to a makefile, simply type:
+
+    ./pk3make.py make ./PK3Makefile # Default PK3Makefile
+
+### Notes, Tips and Caveats
+
+All text files are assumed to be UTF-8 encoded. PK3Make will automatically attempt to convert CRLF to LF newlines but using LF newlines is recommended.
+
+PK3Make will not find hidden files. To avoid `DuplicateLumpError`s, place
+  your workfiles in a hidden directory, for example `.local/`.
+
+Should your project contain custom palettes,  place it's corresponding
+  LUMPDEF before any `graphic`, `flat` or `fade`. That way, PK3Make can
+  cache your palettes and speed up build times by reducing thread idle.
+
+
+## But why?
+
+To put it bluntly: No other tools suited Weissblatt.
+
+Although the PK3 specification for Weissblatt's engine is based on
+[ZDoom PK3](https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement),
+it's directory namespaces are very different. This made Doom's usual
+autobuild toolkit [DoomTools](https://mtrop.github.io/DoomTools/) a
+poor fit for development. Due to the size of the Weissblatt project, manual
+assembly using SLADE was also out of the question.
+
+I chose Python as the basis for PK3Make because it is platform-independent,
+easy-to-read and ubiquitous and although some Doom/Weissblatt-specific
+modules needed to be written from scratch for PK3Make, Python's vast
+standard library and otherwise mature PyPI repository helped stem some
+of the heavy lifting for things such as image processing.
+
+# PK3Makefile reference
+
+PK3Make uses it's own build definition language called `PK3Makefile`, inspired by the `METAINFO` spec from
+[Matt Tropiano's dImgConv](https://mtrop.github.io/DoomTools/dimgconv.html).
+
+`PK3Makefile`s are processed line-by-line with everything following `#`
+being treated as a comment. Otherwise it is split into *Build Options*,
+which define PK3Make's general behavior and *LUMPDEFS*, which define what
+files to put into your PK3 and how to build them.
+
+## Build options
+
+Build options are specified per-line and follow the pattern
+
+    ?<OPTION>: <PARAM>
+
+PK3Make supports the following options:
+
+`?srcdir: <DIR>` specifies the directory to pull it's base assets from.
+PK3Make will attempt to find all defined lumps within this folder and
+mirror it's path within `?workdir` after compilation.
+
+`?workdir: <DIR>` specifies the temporary working directory. PK3Make will
+check the timestamps between this and `?srcdir` and rebuild/copy any
+outdated files into `?workdir` during the compilation process.
+
+`?palette:` defines the main color palette, by `LUMPNAME` (`PLAYPAL` by default)
+
+`?destfile:` describes a filepath to the destination PK3. This is where
+`?workdir` will get copied to during packing.
+
+
+## Lump definitions
+
+Lump definitions follow the following pattern:
+
+    <LUMPNAME> <TYPE> <OFFSET>
+
+`LUMPNAME` describes the filename as used in-engine. Just like the engine,
+it is matched against the first eight characters of the basename in a
+case-insensitive manner.  [Globbing] such as `D_*.mid` is allowed, in which
+case `TYPE` and `OFFSET` are applied to all matching lumps.  `LUMPNAME`s
+starting with a "/" are treated as explicit file paths and match against
+the full file path, starting at the source directory.
+
+[Globbing]: <https://en.wikipedia.org/wiki/Glob_(programming)>
+
+`TYPE` determines how the file is treated during compilation. It can be one
+of the following:
+
+- `colormap`: File is a Colormap. OFFSET specifies the lump name for the palette from which it is generated
+- `fade`|`flat`: File is an image and should be converted to a flat. Only PNG images are supported.
+- `graphic`: File is an image and should be converted to a Doom Picture using `OFFSET` (see below) as a picture offset. If missing, the offset is assumed to be `0 0`.
+- `marker`: File does not exist and is a 0-byte marker. Explicit path definition required.
+- `palette`: File is a graphic and should be converted to a color palette. Only PNG images supported.
+- `raw`: Copy the file over as-is. When `preserve_filename` is given in the offset, the original filename will be preserved.
+- `tinttab`: File is a TINTTAB. OFFSET is defined as `<PALETTE> <WEIGHT>`. Upon generation, `PALETTE` orthogonally maps each color index against one another, `WEIGHT` specifies a bias towards horizontal/vertical colors between 0 and 1.
+- `udmf`: (Not supported yet.) File is a UDMF TEXTMAP. PK3Make will generate a directory named LUMPNAME featuring:
+  - `<LUMPNAME>`: Marker
+  - `TEXTMAP`: Original TEXTMAP file (renamed)
+  - `ZNODES`: UDMF BSP tree generated by PK3Make
+  - `ENDMAP`: Marker
+
+`OFFSET` defines the offset of doom pictures. For convenience, these can be either:
+
+- `<x> <y>`: Explicit X/Y-coordinates
+- `center`: Sets the offset to the center of the image
+- `sprite`: Sets the offset to `width/2 (height-4)`. This is a very common
+  offset for sprites placed in the game world.

pk3make-1.1/examples/PK3Makefile

@@ -0,0 +1,41 @@
+# === Example PK3Makefile ===
+#
+# This is a simple example PK3Makefile, more meant to demonstrate what you
+# can do with the format than actually being useful. 
+#
+# Use this for reference when writing your own.
+
+# --- Build options ---
+#
+# These are your general project options.
+# Please note that PK3Make will attempt to replicate
+# the file tree in your ?srcdir as needed
+#
+
+?srcdir: src # Base file tree where your PNGs, OGGs, etc. are.
+?workdir: build # Working directory to store compiled files. Useful for Out-Of-Date checking and debugging
+?palette: PLAYPAL # Conventionally PLAYPAL. For use w/ graphics/flats/fades. Used as a basis for COLORMAPs and TINTTABs
+?destfile: bin/whatever.pk3
+
+
+# --- LUMPDEFs ---
+#
+# LUMPDEFs are read sequentially, so take care where to
+# place your "marker" types. The engine will break if you don't.
+#
+# Although you will need a palette in your ?srcdir,
+# "palette" types will be dumped into your PK3.
+# To define a default palette for your graphics, use ?palette
+
+PLAYPAL palette
+PAL* palette
+CLM0031 colormap PAL0031
+COLORMAP colormap PLAYPAL
+TRANS50 tinttab PAL0031 0.5
+D_*.mid raw
+/Music/S_DIGITL marker
+O_*.ogg raw
+NUMSPR* graphic sprite
+NUMFLT* flat
+FADE* fade # For now they're flats, let's see if the engine cares
+Maps/MAP* udmf # unsupported, use compiled WADs w/ "raw" for now