Freedoom now accepts PNGs!

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. 

2 people like this

Share this post


Link to post

Oh? There goes the vanilla compatibility goal.

Share this post


Link to post
1 minute ago, Jayextee said:

Oh? There goes the vanilla compatibility goal.

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

 

It's nice that they resurrected the project.

Edited by axdoomer

Posted (edited)

Share this post


Link to post

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 by Voros

Posted (edited)

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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 by chungy
1 person likes this

Posted (edited)

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now