News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
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. 
For Index Colors 
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. 
Wally? 
 
 
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. 
Jpg Is The Worst Fucking Format For Anything Ever 
Each time you save something in it, the quality downgrades. 
+1 For Wally 
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. 
It's To Bad... 
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. 
Kinn 
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. 
Agreed 
 
Context! 
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 Forgot About Compiliers :( 
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. 
What About 
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? 
Oh And 
There's something else that individual texture files don't have: mipmaps. You probably want these. 
No, You Don't 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.