mtrop / doomstruct Goto Github PK

Fixing issue MTrop/DoomTools#46 requires a change to be made in DoomStruct to allow read-only exclusive modes on WAD files. This needs to happen in order to fix it!

This is an incorrect handling of a delete - since entries can refer to absolutely any position in a WAD, the removal of content will require a deep search of what touches that data, and must adjust accordingly.

DoomStruct's map detection (MapUtils.isMapDataLump(String)) should also consider lumps like GL_MAP01 as part of a map, and not a separate one. It currently separates it out.

OTEX is a well-known texture set that contains a texture entry with a + in it, namely O2V+35_0, but as far as I know, this is an illegal entry according to https://doomwiki.org/wiki/TEXTURE1_and_TEXTURE2, but I'm assuming both SLADE and Doom allow it.

Is there any documentation out there that can conclusively say what is allowed or disallowed in an entry? Is this just a standard by consensus? Will some experimentation be necessary?

See MTrop/DoomTools#110.

Correction must be made here.

Within NameUtils.java the lump names regex appears to be too strict. It's possible for patches to use the plus character ( + ) in their name, but doing so causes it to throw an error due to invalid characters. A live example of a WAD with this naming can be seen in Otex v1.1 (https://www.doomworld.com/idgames/graphics/otex_1_1)

I'm unsure what other characters may be missing from the regex, if any.

I don't know what I was thinking with this one. Remedying this will change object hierarchies, but since MapObject is just a constants interface, the damage would be minimal.

The planned correction would be to separate the two, and re-implement where necessary.

An option to change or disable the hardcoded palette translucent index of 255 would be useful.
Hexen has a few cases where 255 is not always translucent. Such as SKYFOG2, finale1 and finale2.

Most graphics in Doom editing do not always exceed 254 pixels in height. However, a lot of source ports use them, and DoomStruct unfortunately does not support this (in the form of horrible data corruption on write).

A fix will need to be made to support this.

What it says on the tin. "Tall patches" are still a problem. This time, it's if it has significant translucency in the middle of a column of pixels.

Must diagnose why.

WadBuffer currently has no way for users to control how its internal buffer expands. This would create problems with large WADs and small heap allocations. FIX!

This project should probably end up in Maven Central at some point, but I was lazy about it/didn't anticipate demand.

Stuff that needs to happen on my end:

• Add the net.mtrop group to Sonatype/Maven Central (for this project and potentially others).
• Convert the Ant build scripts to a POM.
• Push to Maven as the doom artifact.

Currently, the entirety of a UDMF structure is loaded into memory. This is terrible for maps that are incredibly large, and not all of the map data may be important.

In order to reduce the memory footprint, the UDMF Reader should also optionally employ a parse-and-apply method for reading and resetting a UDMF object's fields, like what can be done with the binary objects.

The boolean flags in HexenThing are not read nor written, and should be removed completely. Doubly so since their presence runs counter to library philosophy.

java.lang.IllegalArgumentException: The provided entry name, "^BRICKS", is invalid. It must be up to 8 characters long; all characters must be A-Z (uppercase only), 0-9, and [ ] - _ plus the backslash \.

This is when trying to load and merge a valid WAD file in the wadmerge utility.

Hi, 1st I am new to Java and I hope I didn't screwed this up.
I actually want to use some sprites from doom.wad in libGDX as texture. Currently I read from Picture pixel by pixel and call Palette.getColor() which sometimes throws an error.

I tried to debug it but only got hold of java.awt.Color(int r, int g, int b) and for this index the r-component is -93.

(BTW eclipse just told me: Unable to install breakpoints in net.mtrop... due to missing line number attributes. Modify compiler options to generate line number attributes")

public class Test {
	public static void main(String[] args) {
		try {
			WadFile wad = new WadFile("doom.wad");

			final Palette pal = wad.getDataAs("playpal", Palette.class);

			var c2 = pal.getColor(67);
		} catch (Exception e) {
			System.out.println(e);
		}
	}
}

A new version byte was introduced a while back for extended Demo header versions and this will throw an exception in Demo.java if read.

This issue is for adding support or some other handling at some point.