1) What is the correct file format for textures? E.g. let's say I want to modify an existing texture. I know how to use TexMex to export it from a texture wad, and how to add it back in, but I'm not sure what file format I should choose when doing so (I am guessing the answer is not jpg).

2) Would Gimp be a suitable programme for modifying/creating textures?

3) I think I understand the theory behind using skip textures, but why is it possible to see skip textures (as in, see a brush face with "skip" written all over it) in some maps? Shouldn't those brush faces be invisible? An example would be Day of the Lords: if you noclip through it, there are moments where you can see "skip" written on brush faces. 

Correct file format is .pcx file

I'm sure gimp would work ok. I use paintshop pro 7.

You shouldn't be able to see skip textures, must be one of those weird quirks of the game if you can see them by noclipping through stuff. 

http://www.celephais.net/stuff/texturefaq.htm

The skip faces you see are accidental leftovers i'd say, todays compilers "skip" them ahead of the final bsp compile, were the old tools just draw them and had to be removed with a special compile switch and/or tool.

Gimp is fine, dont expect it to work wonders tho.. 

Thanks for that link; I was actually reading through that before posting to see if it would answer any of my questions (I had a look here http://quakewiki.org/wiki/Textures too).

So if I shouldn't expect too much from Gimp, what is the better alternative? (Just curious; I wouldn't be able to afford any non-free software anyway) 

I've always found Gimp and Photoshop too much of a pain to use for Quake textures. Their world is 24 bit.

I have an old copy of PSP 4.0 (still runs on Windows 7) that I use for making and modifying Quake textures. It works with 256 color palette graphics pretty well. I've always used the .bmp format.

I tried a newer version of PSP (x5), but it was way overly complicated for most of what I do, so I deleted it. 

What kind of pain you have using Photoshop to make Quake textures? You can switch between RGB and "indexed" color modes, I have the Quake palette with and without fullbright lines... Want help? 

It's worth putting time into to learn imo. There are good reasons it's an industry standard (and not so goon ones).

Of course, it can be pretty cost prohibitive, which is one of the reasons I should eat my words and learn GIMP. 

Photoshop is great for Quake textures. Make heavy use of the 'gradient map' layer, and make yourself a set of gradients that match the rows of the Quake palette to use with them. 

I use LVPro 

It's just a personal preference thing, but I find these modern graphics/photo editing programs to have have an overly complex and cluttered up interface for something as simple as editing a bitmap.

I do have a copy of Gimp in my portable folder, some day I may give it another look. 

 

I've never thought of the Photoshop interface as cluttered. If you use hotkeys to flip between tools and create new layers when you need them, the interface is basically negligible. 

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! 

I think I mentioned finding that Grafx2 thing here a year or two ago. I've played around a bit with it, but never tried using it to actually make anything.

I mainly use it as an accessory to look at things such as which colors are actually used in a texture and how many pixels there are of each color used.

The interface is hard to get used to, but it does work. 

To make a new art tool and call it TrenchBrush 

how do I give a static entity a damage exposure? 

you cannot, it is static! 

 

 

Go code! 

...for all the answers to my texture programme question way back in #15383. I guess the discussion has since taken on a life of its own, but I still wanted to say thanks. :) 

forget the static entity, let's say I want to give a place a damage function.
Would a door that's blocked someway, and made invissible be a manner? 

the thing you want is a trigger_hurt

I think 

I'm currently working on a new map, and I keep getting a leak message. When I load the pts in Trenchbroom, the line squiggles all over the level, and is nearly impossible to find where the leak is coming from. I tried zeroing in on the coordinates that the compiler pops out, but of course, its just the player entity.

Also, I'm getting a lot if clipping warnings, but I'm not getting an outputted .por file.

Does anyone have advice for this?

Thanks.

Ruin 

Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? 

Have played about making a tiling texture in grafx2. It does support this, but the interface and documentation is really hard to follow, so a quick guide:

Imagine we want to make a 64x64 tiling texture, but while we work on it we'd like to have a 2x2 array of our texture to see how it tiles. Start a new image in grafx2 and click on the screen size icon. In the box you can edit the dimensions of the texture to be 128x128 (the size of the 2x2 tiling of our desired texture). How to do this was certainly not as obvious to me as to the developers!

Next click on the FX icon, and click on Grid. Set the grid size to be 64x64, but turn off Snap. Now click FX again (confusingly the Grid icon will not appear active if you have turned off the snap feature, but it is working). Click tilemap and then close the FX box. Now you can draw on the texture and all four tiles are altered at once.

This is great until you want to edit a texture, where you need to do things slightly differently. Load the original texture and then resize the image to fit a 2x2 grid. But before you turn on the grid and the tilemap, you need to copy-paste the tile into the other four quadrants, or it won't work.

Why? Well, the program is a bit too clever for its own good. When you turn on the tilemap, it looks to see which grid squares are currently identical to one-another, and connects matching patterns of tile for simultaneous editing. This lets you paste an entire screen from Mario Bros, then edit all the bricks at once, then all the grounds at once etc. But when we have an existing texture and 3 surrounding empty tiles, the 3 empty tiles are tied together, but the actual texture is kept separate!