Any utility that assists in the creation of mods, assets, etc, go here. For example: Ultimate Doom Builder, Slade, WadSmoosh, Oblige, etc.
Forum rules The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Skip files that have already been crushed before (a cache of file hashes is kept in `bin\hashes.txt`) -- incrementally crush your files without having to waste time on files that had been crushed before!
WADPTR's sidedef packing is disabled to prevent glitches in maps
Added `/NOPK3` and `/NOWAD` options to ignore these types
Added `/ZSTORE` option to repack the PK3s without compression: Whilst the PK3 file will be larger than before, it will boot faster. If you are compressing a number of PK3s together, then using /ZSTORE on them might drastically improve the final size of .7Z and .RAR archives when using a very large dictionary size (256 MB or more)
Fixes for file size reduction reporting
The added file caching to skip previously crushed files should make this release much more practical for use in a development project. Whilst the gains might be minimal in some cases, you won't have to think about what files you've crushed or not since last time.
I'm working towards adding logging so that it's safer to throw entire directories full of PK3/WADs at DOOM-Crusher and you can be assured that nothing breaks afterwards.
Enjay wrote:One thing does concern me from the docs though. I'm not sure how the map sidedef packing is done but if it is the kind of sidedef packing where linedefs which share identical siddefs are given the same sidedef references I have experienced problems with that in the past (although, being perfectly honest, I forget what the problems were).
A side effect of sidedef packing IIRC is that if you have scrolling effect on a line, it will affect the other lines that use the same sidedef (and that's not necessarily desired). And still IIRC, it can even be exploited deliberately by using several lines scrolling the same to get a faster scrolling effect, because each line will cumulatively apply.
First, my apologies for v1.1 being completely broken; I hadn't touched the code for a while and forgot how terribly fragile batch scripts can be.
Fixed options not applying!
Many major fixes and improvements to caching:
If skipping PNG/JPG files, allow a PK3/WAD to be added to the cache if does not contain any such files
Separate hashes into different buckets for file-type, this resolves the issue `/ZSTORE` not repacking PK3s that had been maximally compressed and cached
A "cache" folder is now used. Your existing "hashes.txt" will be invalid due to critical bugs in v1.1, sorry
Fixes and improvements to filesize and percentage reporting
Added basic logging (a replica of what appears on screen), see "bin\log.txt", more advanced logging is planned which will capture full error details
Signigicantly faster WAD processing (lumpmod modified to identify PNG/JPG lumps, with thanks to _mental_)
Gez wrote:
A side effect of sidedef packing IIRC is that if you have scrolling effect on a line, it will affect the other lines that use the same sidedef (and that's not necessarily desired). And still IIRC, it can even be exploited deliberately by using several lines scrolling the same to get a faster scrolling effect, because each line will cumulatively apply.
In ZDoom sidedef packing is irrelevant because the engine requires unique sidedefs in the game and unpacks them again.
For other engines a good sidedef compressor ignores sidedefs with attached specials.
Known issue: Above approximately 30 MB the percentage calculations are completely wrong; this is a limit of Windows' Batch processor and I'll fix it in the next release or so -- it has no effect on the actual functionality of DOOM-Crusher.
Fixed hash check failing
If JPG/PNG/WAD optimisation encounters an error, a parent WAD/PK3 will not be added to the cache. This is so that it will be retried in the future until there are no more errors
Command line options given displayed in the header
Never ever edit original retail files in any way for any reason. It screams sacrilege all over the place. Anyway, you cannot tell me you need the couple of MBs this may possibly "save" - if it's even that much.
DOOM-Crusher will not modify IWADs -- it checks the file header -- and yes, it will work with what WADSmoosher produces. DOOM-Crusher is intended for people developing WADs so that they can distribute the smallest possible WAD and do so as they develop without having to repeat the crushing they did before (DOOM-Crusher skips files that it has crushed before). You won't save much on most WADs outside of ones that have thousands of PNGs that were exported lazily from Photoshop.
I can't find any documentation that explains where to put PNGOUT.EXE. Can I just drop it in the bin subdir?
(edit) N/M, I figured it out. It goes in bin/pngout/
A massive overhaul of the project; the batch code is significantly more reliable when handling unusual file-names and edge-cases. It's been run over 20 GB of DOOM WADs and I'm confident it's capable enough for developers to use regularly now. Remember -- the benefit of using DOOM-Crusher is that it doesn't crush files it's crushed before!
I can confirm that DOOM-Crusher is working properly now, with the new v2.1.1 update. Crushing down Brutal Doom v21 (RC9) even as we speak, in the hopes of ekeing out an additional performance boost on my phone.
I doubt it'll give you a performance boost unfortunately, this only impact WAD loading. Since the images are pushed to the GPU the size there will be the same regardless. I am working on features to allow for actual resizing of textures and converting to JPG to drastically reduce the size of WADs (with loss of quality).
However, if it's Brutal DOOM you want to play, you'll want BDLite: viewtopic.php?t=62203
Brutal DOOM is slow because of its bad code and this cleans it all up into something much more performant.