Each time you save something in it, the quality downgrades. 

As Spirit said. It's nowhere near as feature rich as Photoshop or Gimp, but its tools are basic enough for anyone to create and or edit some really good textures. That and it was made for the sole purpose of creating Quake textures, so that should be a plus. 

I use Wally just to handle wads. 

That editors and engines haven't moved on from the ".wad" file format! For mappers that is. A few older external programs could be eliminated along with it. 

That editors and engines haven't moved on from the ".wad" file format! For mappers that is. A few older external programs could be eliminated along with it.

Reading individual 8-bit images from a folder, instead of .wad files, could be neat (if you happen to use the one compiler and one editor that might actually implement it). 

Most new GL engines support "external" textures, 24 bit plain files on the filesystem. Quakespasm, Fitzquake, Darkplaces do. They override textures inside BSP files and have to be placed at <mod folder>/textures. They can even be used on a single level if you place them at <mod folder>/textures/<map name> 

... meaning you don't have to bother about Quake palette anymore if you don't care about backward compatibility. 

Sorry, you mean at development time. I believe QuArk works the way you want. 

Sorry, you mean at development time. I believe QuArk works the way you want.

If only the other 99% of QuArk worked the way I want. 

 

If only the other 99% of QuArk worked 

What's the 1% that works ... the About Box? 

What's the 1% that works

The "X" button in the top-right corner of the workspace seems to function as intended. You probably don't need much else actually! 

I meant more specifically, an uncompressed archive format(.zip) with the same directory structure as .wad files. Then they could be manipulated by the OS natively. Obvious Ex: Q3A's .pk3 It was just a thought I had while reading the comments above my post. 

1- The editor can deal with plain file textures;
2- A little program that packs texture files into a wad, just to feed qbsp. The wad can be deleted afterwards;
3- The engine deals with plain file textures.

It would take changes in the editors we love, like Jackhammer and Trenchbroom and this new compile step before qbsp. 

If you have to make a wad anyway for bsp, what's the point of making the editor and engine read individual texture files? 

There's something else that individual texture files don't have: mipmaps. You probably want these. 

If you're using GL engines you don't need mipmaps, right?

If this wad is made automatically out of your sight during compile process, you don't have to know it even exists and you don't need Wally or TexMex. 

Personally I can only see the point of bypassing the .wad process if you are making your own textures and don't want to keep remaking a .wad every time you add/change/remove a texture. Having an editor and bsp compiler that works with image files directly, not wads, might be a small timesaver/convenience.

But...if you still have to run a tool to generate a .wad before you run bsp.exe, then what do you gain exactly? And again, I dunno why you'd need the engine to read the texture files separately when you are baking them into .bsp? 

You only have to add another command to your automated compiling batch.

I'm pretty sure you can't have a TGA alpha "fence" texture inside BSP. It has to be an external TGA file.

I can provide 24bit versions of my textures in plain files. 

in theory the GL engine could use the mipmaps from the bsp, but in practice most don't, they just recalculate the mipmaps at load time in 32-bit color (which probably gives a better result.) 

If it's really important to you, you could script it all with some commandline tools. Quakeforge for example has uptodate texture tools 

While I can't actually claim I've ever produced anything useful from it, I have had a couple of tries pottering about with a graphics editor called Grafx2. It's designed to work with 8 bit (or fewer) palettes, so all the tools are focused on that kind of work. It has support for different gradients within your palette, and will dither them in a variety of ways. On the downside, it's originally a DOS tool and the interface is still pretty retro, but it's an interesting alternative to a classic photo editing tool. 

At work a couple of years ago, I designed and wrote a bespoke pixel-pushing tool in Unity, for making proper pixel-art 8-bit textures (that use a specific palette with defined gradients and whatnot).

Had some crazy features like painting relief maps, and then lighting them to get realistic highlights and shadows. That was probably a bit OTT, as I found the hand-drawn painterly stuff always had more charm.

A useful feature was the ability to paint on a tiled canvas. Really sucks that you can't do that in photoshop.

At some point I'd like to get permission to release it into the wild. It was PERFECT for quake textures, as I made double sure :} 

You have my permission to release it. Thanks!