SLADE Discussion - Latest: v3.2.7 (25/Dec/2024)

[Nash]

Gez: Re Portable

Cool trick! If I create a portable file now, will my %APPDATA% stuff be transferred over as portable successfully? Or do I have to setup everything again from scratch?

[NeuralStunner]

[Can't change offsets]

Exact problem I (still) have. (The "base resource archive" thing I associated previously doesn't actually make a difference.)

Also, I've found that the various "set sprite offset" options are only bugged out when working with something other than Doom GFX.

Although the HUD offsets for various games are still bogus. The "HUD" setting itself is going to be too low unless the weapon grpahic has an extra 32 pixels that'll be off the bottom of the screen. You need the +32 to get legit fullscreen HUD offset. (Users making new Heretic/Hexen weapons are going to be left wondering why there are big gaps.)

[Enjay]

Is there a way to set which colour will be used as a background colour when using Slade to convert to a "PNG Paletted"type from a Doom graphic?

This is layman's terms because I don't really know what is going on "under the hood" in the PNG format. What I mean by my question is that when a graphic is converted to a paletted PNG, the transparent areas show transparent in programs that support paletted PNGs but in other programs that have limited/no support for transparency in that format, the transparent area will appear coloured.

The problem is that it seems to be pretty random as to which colour this ends up being. Sometimes it can be a colour that makes it difficult to edit the graphic because the background colour is also on the sprite, making it difficult to use flood fill and colour-replacer tools and leaving the user to guess where the sprite stops and the background begins. Being able to set the colour in Slade would mean that I could pick a colour that I know is not used in the sprite and thereby make editing the graphic much easier. I've tried setting the transparent colour in the Gfx conversion box but that doesn't seem to do what I want (I'm guessing that it is only used when converting to Doom format graphics to identify areas to become transparent).

This screenshot of PSP's image browser shows the kind of "problem" that I am talking about.

---

The images in the screenshot all have transparent backgrounds and appear correct in game. However, PSP only has partial support for paletted PNGs and so shows the underlying background colour. As you can see from the shot, Slade picked a variety of colours when optimising the images and some of the colours are quite unhelpful. What I would like to be able to do is to set the background to a specific colour (probably 255 0 255 in my case) and have all the images use that.

This, BTW, is why I was using true colour PNGs when I discovered the palette conversion bug reported in the bugs forum. PSP fully supports transparent areas in true colour PNGs. When I used Slade to convert the sprites from Doom format to PNGs, the graphic was created with a transparent area that did not interfere with any of the colours in the image and I could edit away 'til my heart's content in PSP. Then, of course, I found that ZDoom wasn't handling the conversion of these graphics to the Doom palette in the way that (I think) it should.

So, short version (again), can I set the (often not seen) background colour when converting to paletted PNGs in Slade?
If not, is it something that could be added?

[wildweasel]

[Can't change offsets]

Exact problem I (still) have. (The "base resource archive" thing I associated previously doesn't actually make a difference.)

Also, I've found that the various "set sprite offset" options are only bugged out when working with something other than Doom GFX.

I ended up fixing this problem on my end by deleting SLADE's configuration out of my AppData folder.

[Enjay]

Just tried. Didn't work for me.

[RiboNucleic Asshat]

Today I started having a problem that pisses me off to no end.

I have a large file with a bunch of music and sprites in it that adds up to 500mb or so, and starting today I can no longer save. Even if I make no changes and hit the save button, SLADE crashes halfway through the process and I can't do a damn thing about this. I've even tried splitting the music off into a separate file but it spews so error about an unhandled exception when trying to paste, and simply cropping the archive to the music STILL won't let me save. What really pisses me off, though, is that everything was working perfectly yesterday, and It decided to break only today. Updating to the latest SVN did nothing (in fact, it broke it further since I can no longer adjust sprite offsets) besides change the message to a new one.

The message I'm getting:

Code: Select all

Version: 3.1.0 alpha (r1419)
No current action

Stack Trace:
0: [unknown location] memcpy
1: [unknown location] [unknown:4566759]
2: [unknown location] [unknown:5763616]
3: [unknown location] std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy
4: [unknown location] std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy
5: [unknown location] [unknown:4205539]
6: [unknown location] [unknown:4205547]
7: [unknown location] [unknown:2417653]
8: [unknown location] [unknown:1187497611]

EDIT It's a personal mod, by the way. I'm not one of those assholes who crams a WAD full of junk and releases it.

[Gez]

Re: offset issues: please try r1422 and see if problems persist.

Re: large archive crashing: I'm suspecting SLADE of having memory leaks. I hope sirjuddington will be able to look into it, but he has been away for a while and had some sort of medical troubles.

If I create a portable file now, will my %APPDATA% stuff be transferred over as portable successfully?

It will not be accessed at all. You can, however, copy it yourself.

Is there a way to set which colour will be used as a background colour when using Slade to convert to a "PNG Paletted"type from a Doom graphic?

I think this is done within FreeImage, not in SLADE code.

[Enjay]

Re: offset issues: please try r1422 and see if problems persist.

Seems to be fixed. Thank you.

I think this is done within FreeImage, not in SLADE code.

So presumably nothing can be done in Slade about this?

[Gez]

Not easily, no. One would need to add an extra conversion step where the image is searched for unused palette colors, then all the masked pixels are set to that color, and then the image is converted to PNG without transparency, and finally a tRNS chunk is added. I suppose something like that could be added as an option, but I hope you'll forgive me if I don't make it a priority.

[Enjay]

I hope you'll forgive me if I don't make it a priority.

Fair enough. We're all doing this as a hobby.

I thought I'd be able to use BagheadSpidey's batch image converter. It does exactly what I want. However, the version released with DoomCrap seems bugged. I remembered that there was a problem with it and so I hung on to an old version that did work. Unfortunately, I lost that when my HD crashed.

*edit typo

[Kappes Buur]

..... Unfortunately, I lost that .....

Perhaps this one?

[Enjay]

Thanks but, no, not that one. The program that I am looking for is "DoomPicDump" which was actually a script generating program that could look in a directory of BMP sprites, look for Doom graphic LMP files of the same name and read the LMP files to find out their offsets. The script would then call various utils to convert the BMP to a PNG and then apply the offsets from the LMP to the PNG. Using it, it was possible to convert thousands of BMPs to PNGs with offsets in a matter of seconds. It also had a number of other nice little options like background colour and scaling.

Grabpng is one of the utils that the script calls but there was more to the program than just grabpng.

[Kappes Buur]

This is the only version I have outside of DoomCrap.

[Enjay]

That is much better than the one in the DoomCrap package. It works without any further adjustment.

Unfortunately, it isn't a version that has the one key feature that I was looking for - the ability to specify the "mask" colour and have it kept in the palette. This version works but the mask colour is set to some other value during the conversion (just like Slade3 does it). I know that there was definitely on version that allowed the specifying and preservation of the mask colour because I remember discussing that with BHS and I still have some old sprites where the background colour was specified by me.

All that being said, this works much better than the version I had from DoomCrap and it will be very useful to have around. Thank you.

[edit]w00t! I managed to figure out where in the script the background colour was being set and I can change it manually to which ever RGB value that I want. Not as convenient as being part of the UI, of course, but it does exactly what I was looking for. Thanks once again.

[edit2] Just for info, I've discovered a minor inconvenience with it: if the lump has negative offsets, the resulting PNG has incorrect offsets saved. This really only affected weapons in the conversion that I was doing and weapons are amongst the least sprite intensive types of actors (number wise) so it wasn't hugely problematic. I just thought it was worth mentioning in case other people were using this program.

[Enjay]

I've been wondering for a while...

Occasionally Slade will not be able to identify a lump, or identifies it as an incorrect type. If the user knows what the lump actually is, is there any way for the user to force Slade to recognise it as the correct type and thereby have the lump-type-sensitive features enabled?