Kinn
#15399 posted by adib on 2015/09/11 16:09:24
Sorry, you mean at development time. I believe QuArk works the way you want.
#15400 posted by Kinn on 2015/09/11 16:12:00
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
#15401 posted by adib on 2015/09/11 16:18:29
Context!
#15402 posted by ijed on 2015/09/11 17:29:42
If only the other 99% of QuArk worked
#15403 posted by JneeraZ on 2015/09/11 17:35:08
What's the 1% that works ... the About Box?
#15404 posted by Kinn on 2015/09/11 18:15:34
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 :(
#15405 posted by damage_inc on 2015/09/11 18:20:44
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
#15406 posted by adib on 2015/09/11 19:45:58
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.
#15407 posted by Kinn on 2015/09/11 19:52:20
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
#15408 posted by Kinn on 2015/09/11 20:00:02
There's something else that individual texture files don't have: mipmaps. You probably want these.
No, You Don't
#15409 posted by adib on 2015/09/11 20:09:13
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.
#15410 posted by Kinn on 2015/09/11 20:32:18
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?
#15411 posted by adib on 2015/09/11 20:51:21
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
#15412 posted by metlslime on 2015/09/11 21:55:58
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.)
#15413 posted by Spirit on 2015/09/11 22:21:31
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
#15414 posted by Preach on 2015/09/12 17:44:50
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
#15415 posted by Kinn on 2015/09/12 18:00:50
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...
#15416 posted by generic on 2015/09/12 19:05:56
You have my permission to release it. Thanks!
#15417 posted by Rick on 2015/09/12 20:59:30
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
#15419 posted by madfox on 2015/09/13 03:26:06
how do I give a static entity a damage exposure?
Fast Answer
#15420 posted by necros on 2015/09/13 04:31:26
you cannot, it is static!
PaintBroom
#15421 posted by SleepwalkR on 2015/09/13 08:20:39
BrownStrokes
#15422 posted by Kinn on 2015/09/13 10:05:51
YES
Go code!
|