else is idc 

Dwere, you didn't think that the missing body from the texture was because the body was supposed to be rendered in 3D? Tsk-tsk...
Before you leave this thread, I'd like to see a screenshot of this body rendered in 3D, or a link to a mod that enables that.

I'm assuming other textures with similar detailing preserved, but merely stretched/filtered, were always made specifically for such a mod, so you're not supposed to see the lazy parts.

I'm really not sure why this is such a tough thing to believe.
There's a saying about thirteen strikes of the clock. I've clearly seen the assets that weren't made using pixel art techniques, so I find it logical to believe that such methods were used on a regular basis. Why not, if it can make your life easier?

I admit that I don't know the exact capabilities of the tool that id used at the time (Deluxe Paint?), but I've heard it had some advanced features like blurring, even though it wasn't a true color image manipulation program.

Do you think they would have gone with blocky pixels if they had a choice about it?
Again, you could say the same about early pixel art examples. This is irrelevant to the question of how aesthetically pleasing is the art itself, or if the technique used should be abandoned.

Low-res paletted art generally takes less time to create than high-res true color art despite the former's limitations, so it still has its applications in non-commercial works where your resources are very limited.

Even a "retro" project is hard to pull off with an acceptable level of quality, so it's no wonder that "modern" amateur projects are so rare (and typically look worse than their technical level allows). 

MFX needs to go map...

OTOH. Yes, if you redid everything in Quake, including all hi-poly models, increased the brushwork tenfold, etc etc, then sure hi-res textures and bump-mapping and shit would look good in.

At the moment, it is simply a matter of objective scientific fact that pushing some graphical aspects very far forward whilst other graphical aspects lag behind makes the game look like ass.

(Conversely, some graphical aspects - coloured lighting, fog, transparency, particles etc - can be pushed a bit and still be perfectly harmonious with the basic graphics when used well. Why is this? Who knows, just another immutable law of the universe).

This doesn't mean the potential isn't there, but the whole lot has to be over-hauled in harmony, not disharmony. 

I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game. After a while, they dropped the models part to focus on the retexturing. So the body was never actually made and the texture was "forgotten" and left as is. However, there is a fix for it: a hi-res body was added to the texture by someone else. You won't find it in QRP and I don't remember exactly who did it and where you can find it. Maybe in SMC but I'm really not sure. 

 

or new kinn posts. He has been on fire lately. 

But using his own custom textures all of which are made from the text of his recent posts, and of course are fully hi-res, hi-definition, bump-mapped, specular-mapped and generally fucked up beyond all comprehension. 

with walls textured in his Quake Hitler pose. 

Version 0.92.1 of QuakeSpasm is released: This is a minor bug-fix release.
Changes since the previous version:

* Fixed large menu scale factors (was broken in 0.92.0).
* Fixed PAUSE key (was broken in 0.92.0).
* Updated some of the third-party libraries.

http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/ 

I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game.

What about remaking all the maps to have the high levels of detail that would justify the replacement textures and models? 3200 poly monsters in 400 polygon worlds look just as out of place.

But it's all academic anyway, Quake's vagueness is part and parcel of the deal now, and you can't upgrade your way out of it without disappointing a certain proportion of the player base. For example, this ogre replacement has been objected to on the grounds that he's holding the chainsaw in a hand, rather than it being grafted onto his arm. To some that was a limitation required in 1996, to others the body-horror was part of the appeal (this may explain why Edie is part-ogre rather than part-human).

Similar debates have raged on this board over whether Shamblers have fur or ragged pale skin, whether Fiends have eyes, and whether the Vore has a feminine physique or not (note to func_ regulars: please resist the natural temptation to reignite all of these below). The more you define the detail, the fewer people will agree with your interpretation. Best to let people's imaginations fill in the gaps, like a good book spared an imperfect film adaption. 

Amen. 

Thanks OZ! 

really preaches it. 

Support for colored text in centerprint messages. I'm wanting to use them as headers on different bools that you read in this one map mine. They look fine in Darkplaces but have ^7 characters showing in QSPSM. 

@Veyron - my build server is back up now

re: rtlights and water shaders, I also don't think these fit in QS (both code wise, and engine focus). I think it's good for the Quake ecosystem to have multiple engines with different specialties, QS shouldn't have every possible feature.

IMO, if you run in to a map that FTE and/or DP have compatibility issues with, you should make a detailed bug report explaining the problem. 

Getting stuck on what feels like tiny brushes. Ramps in general are pretty sticky to traverse in this engine. Maybe I'm missing something, same problem occurs no matter what the fps. Here's a screenshot. 

That can happen when three or more different planes intersect along the same line. In this case the floor, the ramp, and the near wall of the room. Is that a map you made or just one you're playing? 

That's good to know thanks. Nope, it's e1m1. [= 

Leave host_maxfps at 72, otherwise it'll mess with the physics. 

It happens even with host_maxfps 72 though. 

Quake has 2 colors for text --- gray and "bronze". With some QuakeC compilers like FrikQCC you can add do "/bThis is bronze text/b"

Of course, FTEQCC is the go to compiler these days and I can't remember if FTEQCC supports that (at one time it didn't), but it is still possible by pasting in text from a Quake text maker like:

http://www.quaketerminus.com/hosted/oqnm_4_20/oqnm_4_20.htm

This method does not need any compiler support, you should be able to put that text even in map titles and such. 

I did notice the funky physics when playing on 250. Knocking it down to 144 keeps it fluid and fixes the bobbing around on descending lifts. Will probably end up playing on 72 if I run into anything worse. 

My light.exe also processes "\bThis is bronze text\b" anywhere in the map file so you can easily use it in trigger messages, etc.

--
re: e1m1, I can get stuck walking towards the ramp from the e1m1 exit slipgate with winquake.exe (and in QS as well).
So at least it's not a new bug. :-/ 

@Qmaster. A 2nd option ...

Make your own conchars and distribute it with your map.

Then the "bronzed text" can be whatever color you edit the conchars to be. 

@ericw -- pretty cool (although I won't ask why the light.exe is what would do that instead of the bsp compiler, haha)