Automatically load png images as patches?

After reading through the many posts pertaining to png support, it seems there may be some demand for being able to import png images (in raw data format) directly into patch & texture format - the way bmp images currently can be (or the way images in other formats are imported while being converted into the DooM format).

I have a whole bunch of png images from which I would like to create patches & textures. Right now I have to create the textures manually. It would be great if the process could be automated. Something for the near future, perhaps?

Actually that's what XWE used to do by default. Whenever you imported a PNG (or any other image for that matter), WXE converted it into the Doom graphic format. People kept asking me NOT to do this, so the new beta (or was it 1.16?) has a default option, where PNGs are imported as Raw data always. You can turn this off though under View -> Options. Is this what you meant?

My question is, "why would people want to import pngs as raw data?"

Csabo said:

Actually that's what XWE used to do by default. Whenever you imported a PNG (or any other image for that matter), WXE converted it into the Doom graphic format. People kept asking me NOT to do this, so the new beta (or was it 1.16?) has a default option, where PNGs are imported as Raw data always. You can turn this off though under View -> Options. Is this what you meant?

I'm assuming that retaining the raw data for the png image includes the original color pallette plus relevant headers. In other words, for a program such as GZDooM to display the graphic with the original (i.e., proper) colors, it needs to retain its raw data. If so, then I do indeed want the png images imported in their raw data form. What I was asking for was the ability to import the png graphics in raw data form while simultaneously inserting them into the PNAMES lump and creating textures from them. Currently (i.e., v1.16) if I double click the "Patches" button in the bottom task bar I can mass import images (including in png format), which then get properly inserted into the PNAMES lump and have textures automatically created from them, but get converted into the DooM graphic format. I don't see the same option for importing png images in raw data form. Does the beta have this option? If so I will give it a try.

mac53 said:

My question is, "why would people want to import pngs as raw data?"

The way I understand it, some source ports (e.g., GZDooM, and perhaps jDooM) can use graphics in png format, the advantage of which is that the original colors are retained without needing the images to be converted into the DooM graphic format (which is often only an approximation of the original colors). In addition, GZDooM and other such ports allow (and properly display)png images with varying color pallettes. In other words, even though each image may be restricted to a 256-color pallette, several images may collectively contain far more than 256 colors.

I'm undergoing a doom 2 sprites enhancement project as we speak. I've already converted the 256 color bmp's to 24 bit [True Color] pngs, has reduced the gamma of each file and increased them to 200 pixel resolution. Am I understanding you correctly, that when it comes time for me to make my new sprites wad that it's best that I load these into Xwe as "raw data" and not as a "Sprite"? I'll use the "Sprite" headers of course! My map is of zdoom/hexen configuration, recommended Gzdoom port-engine for game play. These "raw data" which shows a pngs and not sprites when loaded in, will show up in my map as sprites? Am I understanding you correctly?
Because if so... this is cool!
------------------------------------------------------------
Edited...

After these sprites are loaded in as "Raw data", how do I set the x-y offsets?

------------------------------------------------------------
Edited...

After these sprites are loaded in as "Raw data", how do I set the x-y offsets?

Disregard this question... I found it out!

Rex, I don't think what you are trying to do is supported by any source ports. That is, patches and textures must use the Doom format. PNGs can be textures too, but they have to be inbetween TX_START / TX_END markers, or something like that. I'm not 100% sure on this though. This is a ZDooM specific issue, please ask around or search the ZDooM forum. Once you know how do to this, and find that XWE is really missing this as a feature, let me know.

Csabo said:

Rex, I don't think what you are trying to do is supported by any source ports. That is, patches and textures must use the Doom format. PNGs can be textures too, but they have to be inbetween TX_START / TX_END markers, or something like that.

Csabo, you are probably right. I knew that the TX markers allowed png format images to be used directly as textures and flats, but I assumed that putting png format images into PNAMES & TEXTUREx also worked. I will check in the ZDooM & GZDooM forums.

Incidentally, I used XWE to insert png format images into a wad, and put them between PP_START & PP_END textures, into PNAMES, and into the TEXTURE1 lump. The curious thing is that in the "All" screen the patches are being designated as Type PNG, and they do not show up in the "Patches" screen, but they are in the PNAMES lump and are in the TEXTURE1 lump. In other words, I can select them as patches when creating textures. I have looked at the wad in DooM Builder, and the textures show up just fine. Does this somehow contradict what you posted about png images needing to be between TX markers?

I can send you the wad separately, if you wish.

Csabo said:

Rex, I don't think what you are trying to do is supported by any source ports. That is, patches and textures must use the Doom format. PNGs can be textures too, but they have to be inbetween TX_START / TX_END markers, or something like that. I'm not 100% sure on this though.

Csabo, I checked on the GZDooM forum, and the source port supports png format images whether they are between TX markers or in PNAMES & TEXTUREx format. Here is a link to the thread.

Thanks for looking into this. I added it, grab the latest. This was a very simple change, XWE was only adding lumps to patches/textures if it was Doom format, now it allows PNG too.

Csabo said:

Thanks for looking into this. I added it, grab the latest. This was a very simple change, XWE was only adding lumps to patches/textures if it was Doom format, now it allows PNG too.

Very cool. This will save a sh*tload of effort to create textures from png format "patches" loaded in raw data format, especially in my case with 500+ images for textures.

Is the version you did this with the beta, or can you fix the stable (v1.16) version with the new feature? As there may not be a widespread demand for what I was asking for, perhaps you can do a "limited release version" (say v1.16a) and send it just to me, particuarly if you are reluctant to create a separate version with just this change to v1.16. (If there is a greater demand then maybe you can release it as a new version.)

Thanks very much.

There's really only one version for me, the current one. XWE is a small project, I don't use any kind of version control software for it. The only reason I call the current one beta is because I'm too lazy to update the homepage all the time, especially for small changes.

The current one is much better than the last "official" release in every respect, it's bugfixes, improvements and new features all around. The only problematic one is the "check-if-file-was-modified-by-external-program". I might make this optional or something. Works here, but people have been complaining about it popping up at weird times, and no-one seems to want to track down if there's really an issue with it.

Csabo said:

The only problematic one is the "check-if-file-was-modified-by-external-program". I might make this optional or something. Works here, but people have been complaining about it popping up at weird times, and no-one seems to want to track down if there's really an issue with it.

I have been reading about the "problem". When I have some time I will check the issue out on a test wad. Because of my crazy travel schedule I am sometimes slow to get around to new things, but I will certainly try.

A couple of things about the automatic png-to-patch/texture-as-raw-data feature:

1. While it makes loading png images directly as patches and textures easy, the default texture size is 128 * 128. In other words, the textures are not automatically sized to the corresponding patches. This requires manually re-sizing the textures in the TEXTURE1 lump. Is there a way to do this automatically when the images are loaded?
2. I'm not sure if this is a function of the png format or a problem with the beta, but after I deleted some textures, patches, and corresponding entries from the PNAMES lump the order of the patches in the textures got messed up. For example, the texture xsign24 had the patch xsign25, texture xsign25 had patch xsign26, and so on until the end of the texture list. [The PID numbers were similarly messed up. I mention this just in case you're wondering if the PatchNames were messed up but the PIDs were OK.] This is requiring me to go down the texture list and manually change the PatchNames.
3. Curiously, the wad with the same patches & textures in doom graphics format is not messed up. [I have created a "parallel" wad with the same entries as the png wad, but this time I used XWE v1.16 to load them, which it did and converted them into the doom graphic format.] Which is why I was not sure if the problem I experienced is a function of the png format.

Issue 1. happened because XWE did not bother to read the width/height information for PNG files. It was enough to identify the lump by the image header, since width/height will be automatically available once it's loaded. For this function however it's necessary, so I added this to the latest beta.

Not sure why issue 2. would happen. You are doing all the correct steps: when you delete a texture and a patch, the corresponding line has to be deleted from PNAMES too, but if that's done, everything should be fine. Perhaps there's a bug there, if you could break it down to steps that I can reproduce it would help.

Csabo said:

Issue 1. ... For this function however it's necessary, so I added this to the latest beta.

Many thanks. As it happens I was not averse to undertaking a manual task, so I had already gone into the wad and correctly resized the textures. Still, this will come in handy if I do something similar in the future.

Not sure why issue 2. would happen. You are doing all the correct steps: when you delete a texture and a patch, the corresponding line has to be deleted from PNAMES too, but if that's done, everything should be fine. Perhaps there's a bug there, if you could break it down to steps that I can reproduce it would help.

To test out if the problem is a recurring one, today I deleted two patches and the same problem happened. I'm sure you can replicate the problem yourself on any wad with custom textures, but I'll be happy to send you the wad that got messed up today.

I tried deleting the patches in several different ways - first deleting the textures & patches then deleting the PNAMES entries, next deleting the entries from PNAMES then deleting the actual patches & textures. Each time I was having the problem. Then I tried something different - I deleted the patches & textures but NOT the corresponding entries in the PNAMES lump. Voila! The problem went away. Of course the dummy entries are still sitting in the PNAMES lump, but I don't know if this will cause any problems (I recall DooM giving an error message that seems related to this type of mismatch).

Ah, you are right. If you delete a line from the PNAMES list, the PIDs will change. In this case the whole TEXTURE1 lump should be reprocessed, but XWE does not have this function yet. The way the PNAMES lump currently works makes this too complicated. PNAMES should have it's own little "editor", where the delete feature would reprocess the TEXTURE1 lump (and the user wouldn't get to just "do anything", otherwise there's no way to know what's going on). I'll put this on my TODO list.

The important issue for me is: should I avoid deleting patches, even if I leave the PNAMES lump unchanged? Is there a problem with leaving entries in the PNAMES lump, when the associated patch has been deleted from the wad?

It's really not a big deal if I leave a couple of unused patches in the wad. The resource wad itself is over 11MB, and that's before I put the maps in (and as you know my maps tend to be a hefty size). Having a few patches of 15K each will hardly cause bloat in my wad.

Thanks, anyway.