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
 
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. 
Mipmaps 
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 
Natively 8 Bit Editor 
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. 
Pixel Pushing 
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 :} 
Kinn... 
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. 
I'll Pester Sleepwalker 
To make a new art tool and call it TrenchBrush 
Fast Question 
how do I give a static entity a damage exposure? 
Fast Answer 
you cannot, it is static! 
PaintBroom 
 
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.