News | Forum | People | FAQ | Links | Search | Register | Log in
General Abuse
Talk about anything in here. If you've got something newsworthy, please submit it as news. If it seems borderline, submit it anyway and a mod will either approve it or move the post back to this thread.

News submissions: https://celephais.net/board/submit_news.php
First | Previous | Next | Last
Oy Vey 
my reading skills are up to par 
 
yeah hey okay so I was thinking:

there are two rows in the Quake palette which are nearly totally unused.
http://lunaran.com/pics/quakepal.png

One is that weird second blue row that grows in saturation as it brightens, the last row before the fullbright fire row. As far as I've seen, the only stock textures and assets that use that palette row are that one blue dragon stained glass window, and the textures from the dopefish secret. I'm fairly certain everything else that's blue uses the upper sky-blue row.

The other is whichever of the two very similar purple rows you could personally stand to do without. The only significant purple things in Quake are voreballs, runes, the one sky texture used everywhere, and the particles thrown when a spawn explodes. These two rows could easily be averaged/collapsed into one.

My point is, there's essentially two whole free rows of the palette that are up for grabs with minimal changes to Quake. Any mod can provide its own palette.lmp override in its basedir and get whatever mileage out of a partially customized palette the artist feels he needs, without really screwing up any stock textures or assets at all. No special engines required. The only thing that would really need to be included would be replacements for the voreball and end runes which make sure they're the same purple as the sky. (If you didn't mind voreballs and tarbaby dust being some other color you could even have three rows.)

However, there are additional costs: namely, assets for a palette-plus mod would no longer be shareable, because once you move them back to /id1/ or any other mod you'd wind up with blue and purple shit all over. That runs the risk of creating mutually exclusive asset ecosystems, and this community's been traditionally about freely sharing in that regard. Then again, we've all been using textures from Hexen and Alice and sundry sources with bad-to-passable palette conversions for decades and it hasn't turned anyone off, so an additional stock-palettized wad could easily be created as long as the losses wouldn't be too visually egregious. Plus, wouldn't it be nice to be able to use said Hexen and Alice textures with one or two rows of their actual palette brought with them?

Tool support would be a problem: not every common Quake editing app supports custom palettes. QE3 does (getting that editor to actually find the damned palette lump on disk is like obstacle #1 to getting QE3 to work at all), but others don't. TexMex, critically, simply has the stock Quake and Quake2 palettes hardcoded, and mickey vanished from the scene and took the TexMex source with him 15 years ago.

This might all be way too much bother for 32 extra shades of brown (lol), especially when engines exist that load full color TGAs, but it's something I've been thinking about. 
 
The yellow row is also barely used. So is that sort of aqua greeny row above.

To be honest I have thought about this a lot (I'm actually in the middle of making a new texture set myself). I think the cons outweigh the pros personally.

To get more colours into quake I would simply use TGAs. 
 
because then there would be a reddit thread where eighty people coordinate to play one copy of a game and then what text_fish said.

Okay, maybe there would have to be a limit on your time played. Similar to getting a refund, but more lenient. 
Lun 
if I'm being honest I think I would prefer the Unreal engine 1 implementation of pcx textures. Which is basically that every texture has its own unique palette. File size would be much smaller than using .tga files, it would be self-contained with the .bsp file for neatness. 
Fifth 
That would require modified compilers, a new bsp format, and new engine support. 
 
File size? Really? 
Kinn 
I'm sure EricW would be happy to implement all three. ;)

He's a god-damn wizard you know. 
Why Use TexMex Instead Of Fimg? 
 
 
Yeah but I just think its dafter than a box of weasels to have to modify the code of a number of tools, engines and file formats, to support baked-in unreal-style pcx textures, when external TGA support is overwhelmingly superior AND backwards compatible AND available right now :}

Filesize is a non-issue imo. 
 
We'll agree to disagree. ;) 
 
Fitzquake / QS already supports actual pcx textures, you could put them in a oak file with your map if you don't like loose files. 
 
Oak = pak, thanks iphone 
 
Fifth, been there, done that - halflife bsp.
palettes still suck, as do standard texture resolutions.

storing image data inside your bsps themselves is not good for file sizes, even if they're RLE pcx files.

either way, (gl) engines generally already support both pcx and tga external textures.
If you want to strip the textures from bsps all you have to do is to set all the offset values of your mipmap images to 0 and strip the image data. Its not a problem unless an engine can't load the correct external texture, in which case you'll just get corrupt textures rather than anything crashy. 
 
palettes still suck, as do standard texture resolutions

Regarding texture resolution, I beg to differ. Quake's pixel vision is a seriously legit art style that would still be relevant if someone wanted to make more colourful, but still retropixelly textures.

If you are one of those heathens that plays quake in GL blurry mode, then ugh. 
 
hey let's have this argument again 
Trigger Warning 
I play Quake with linear filtering and model interpolation disabled. 
Well Anyway 
with TGAs, you can always palettize and maintain pixel resolution yourself. at least the option is there either way. 
TGA Jam? 
 
 
yeah tgas can also be 8-bit if you want to save those precious kilobytes, or want to maintain the retro cred.

Interestingly, initial tests indicate an 8-bit tga is slightly smaller in filesize than an 8-bit pcx. Heh. 
 
I suggested the compiled in custom palette mostly for the sake of neatness. I never have my maps as separate .pak files because I find it a bit unnecessary to devote a whole folder for 1 map. 
Ammo And U 
HYPOTHESIS
After my post in the Katedra thread I was curious what actually makes a good baseline ammo HP to monster HP ratio, so I cheesed some debug info into progs.dat and loaded all the stock maps with it, as well as an utterly unscientific list of random custom maps I had at the ready.

EXPERIMENT
My metric was to add up monster health, except for zombies, then add up all ammo HP, subtracting the number of zombies from the number of rockets before figuring them in.
- Multipliers: 25 per shell, 9 per nail, 30 per cell, 180 per rocket.
- Starting shells were not counted.
- Totals include all ammo in secrets (there's no way to programmatically filter them out).
- No rockets vs Shamblers math was done. We can assume players don't use rockets on shamblers anyway.
- Chthons, Shubs, and crucified zombies were excluded.
- Numbers for E1M7 are inaccurate anyway due to meat fireworks.
- All numbers are skill 2.

http://lunaran.com/quake_mapammo.txt

Obviously there's a lot of assumptions inherent in this, and how hectic any given map's combat is (hecticness? hecticity? hectitude? let's go with hectitude.) the hectitude of any given map's combat is going to affect how these numbers actually feel in practice, but this is a good learning exercise to establish some boundaries.

CONCLUSIONS
- the first map of an episode always has way more ammo than necessary. (if I had counted starting shells these numbers would be a little higher even.) e2m1 wins the award for most excessive ammo placement, with enough ammo to kill every monster in the map 7 times. however, we can consider these numbers flawed, because enforcers' cells are all dropped in the first map but can't be used until the player has a lightning gun.
- e1m3 wins for most rockets, with 101. (you can only carry 100.)
- ratios otherwise hover around the 2.0-2.5 mark. episode 1's are the highest, episode 4 the lowest, predictably, although the plethora of quads in e4 probably offsets that.
- even though players of one-off custom maps don't have the benefit of bringing all the previous map's ammo with them (because there was no previous map), the handful of custom maps I checked were still a little more scarce with ammo than the id maps.
- the ammo to monster ratio in Katedra is just under 3:1. 
 
CORRECTION
- e2m4 wins for most rockets with fucking 118 
Run It On 
smqe08d_lun.bsp 
Lunaran: 
Very interesting. 
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.