Freedoom now accepts PNGs!

[Doctor Nick]

The Freedoom build process has finally entered 21st century and now accepts PNGs! No more fucking with the cyan transparency to get your sprite to work!

I have updated the build process in my guide with the updated deutex binary. 

[Jayextee]

Oh? There goes the vanilla compatibility goal.

[Doctor Nick]

1 minute ago, Jayextee said:

Oh? There goes the vanilla compatibility goal.

Nope, deutex automatically converts them into Doom-compatible PICs. Fully Vanilla compatible!

[Jayextee]

Ohhhh, I thought you meant in the .WAD -- brainfart there. My bad. :)

[axdoomer]

What I think is the most important, is that Deutex can now add images which are larger than 127 pixels (width and height) to a WAD and it will display correctly in Doom. I wanted it to be fixed for a long time.

[Voros]

Done.

[axdoomer]

About Deutex, that's the issue and the commit that fixed it.

 

It's nice that they resurrected the project.

Edited July 29, 2017 by axdoomer

[Voros]

I'm just glad that Deutex is back on track. Was tired of renaming my MID files to MUS.

In fact, fraggle's recent issues he posted might help Freedoom's build system. There are two idiosyncrasies in Freedoom's BUILD-SYSTEM.adoc document, and they are both related to the issues he posted: explicit TEXTURE lump names and IWAD dependency.

Using something like

if (Type == IWAD)  {
// Don't look for IWAD and continue with building
} else {
// Look for IWAD
}

Could solve IWAD dependency if building an IWAD.

No idea about the explicit TEXTURE lump name though.

Edited July 29, 2017 by Voros

[RonLivingston]

I'm kinda thinking why it accepts PNG's now?

[Doctor Nick]

2 minutes ago, RonLivingston said:

I'm kinda thinking why it accepts PNG's now?

Previously, freedoom graphics had to be in GIF format, which didn't have transparency; this became a pain in the ass as you had to add the transparency color to all the sprites. Now that it accepts PNGs, we don't have that problem.

[Blastfrog]

One thing I was really hoping for was to just pull the offset coordinates from the PNGs themselves rather than manually redefining them in buildcfg.txt.

[chungy]

The PNGs neither encode that data, nor does DeuTex support it (but that's not a bad idea!).

 

I would be hesitant against Freedoom's build system depending on such a feature even if it existed. Such metadata is way too fragile.

Edited August 3, 2017 by chungy

[Blastfrog]

Well, with Slade it's easy to import and export PNGs with such info intact.

 

It's the responsibility of anyone forking the project to ensure they don't break the offsets. Easiest thing is to recommend working with them in Slade first, then just export them when finished.

 

If a sprite needs to be duplicated anywhere with a different offset, I think the manual offset system should still exist, but by default it would use the internal coordinates instead.