No one has to like amateur HD content. More often than not it's just weak.

Today I looked inside QRP_map_textures_v.1.00.pk3 that I happen to have. One of the first textures I clicked on was this little gem:

http://i.imgur.com/X0UA87y.png

This is a texture of the "bodies" series. Guess what's missing:

http://i.imgur.com/PSVK70R.png (this is the original)

I know drawing is hard, but come on. It's supposed to be an improvement. Although, FWIW, if they'd actually draw the contents of the texture properly, it would still look awkward on a flat 2D surface. You can barely get away with such "macro" detailing on a pixelated texture, let alone a high-res one. 

I like the low res art style. It's kind of funny, back in the old days I used to have a 3dfx card coupled with a Matrox 2d card and often I would prefer to play in software mode. The only time I jumped to the 3dfx card was if I was play Q2 and beyond. 

Because of the lack of space for information, pixel artists have a somewhat impressionistic approach. The result, to me, kinda causes you to "fill in the gaps" with your imagination, giving the world a real sense of depth and interest. This works well with quake's otherworldly setting.

I love high fidelity art as well. But that's a different beast all together and puts a whole different set of demands on the artist.

In my experience, HD content for quake may be "good" in isolation, but in the context of other assets and game geometry it often comes off as inconsistent, out of place and amateurish.

A true HD quake would have to be a total remake with a focused and coherent vision from the ground up. 

Words you can hear in the mouths of zealots and dictators

Cool, so I'm essentially Quake Hitler for simply pointing out why QuakeSpasm does not support the features you describe. Again, I'll repeat that I personally have no say over what features QS does or does not have. I'm just an end user. I happen to agree with the QS design philosophy though, as do I think most people on this forum.

We're not gonna dwell on it forever, this is not the place for this discussion

Hey, you dropped this turd on the carpet, don't think you're getting away without having a good sniff of it.

Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time

It's pixel art. There was no "downgrading" of existing higher colour or higher resolution artwork. The artists literally sat in front of Deluxe Paint with the Quake palette loaded and painted stuff precisely at the pixel level. Maybe you're using a different definition of "pixel art", in which case this is just a retarded argument over semantics and I haven't really got the time for that.

I'm not quite sure how someone could fire up id.wad in TexMex and look at arch textures like "church7" or things like "window030", "adoor01_2", "enter01", any of the stained glass windows, hell, pick almost any texture in the wad that's not just a plain stone surface...and then claim the artist wasn't precisely and purposely laying down palette colours at the pixel level... 

 

Making all those references to the not shooting Hitler bit from The Office has finally taken its toll. 

Actually, it's precisely the stone surface textures that make me really doubt that each pixel was done in a controlled way. You just don't do that. It's slow. Have you seen the amount of colors used?

While there wasn't any conversion from true color to indexed, it's pretty clear that some "dirty" tricks were still involved. But it really is a pointless argument, because being/not being pixel art doesn't make the assets good or bad automatically. 

Since the engine supports colored static lighting, are there any plans to add some colored dynamic lighting functionality? Right now all dynamic lights are white. 

Have you seen the amount of colors used

It's a very manageable amount actually because the contrast of the textures is very low compared to the range of the colour ramps used - so the number of colours used from each ramp is low, and taken from the darker end of the ramp.

The light colours in the palette only get seen in the game once the lighting engine does its thing.

Trust me, I am currently creating my own quake texture wad by working directly with the palette colours and ramps, using a bespoke pixelling program I wrote for a company I worked at (which was inspired by pixel apps like DPaint and Pro Motion).

Here is a just one example of one of my textures. I don't pretend to be an amazing artist but the aim is to at least be consistent with the style and quality of quake's original textures. The number of colours used is really really low, simply a handful of colours from the lower end of about 3 of the ramps was used in this one, and this texture look literally minutes to bash out:

http://i.imgur.com/YN5DBmG.png 

Do you know how DarkPlaces does colored dynamic lights?

(Hint: it's not pretty) 

that looks great 

And what I mean, let's say you want a fireball to be orange lighting?

How do you tell DarkPlaces to make a fireball's dyanmic light orange?

(It's an uglier hack than a tour inside a hotdog factory) 

Well, the stock textures are typically more smooth, and also occasionaly more "chaotic" in the sense that you can spot pixels that don't really belong color-wise. Some of these cases are clear mistakes that would've been hard to commit when picking colors manually.

In some cases you can clearly see that they blended two or more materials together. Quake even has some textures that are derived from Doom textures that were made of toy photos. And it's an efficient way of doing things. Although if you really made that texture in only a few minutes, I can only applaud your skill. 

I take it a cleaner solution doesn't exist?

Adding colors to old content retroactively isn't really necessary. I was thinking more along the lines of giving modders a way to assign colors in new mods. Like reading a certain entity field (if it is defined in QC), for example. 

Dynamic colored lighting does not go well with static baked-in lighting at all. :( 

Dynamic colored lighting does not go well with static baked-in lighting at all. :( 

I think color for the built-in dynamic lights would be a good addition. There are not that entities that move and give off light. Would it really be difficult to add?

(Lava balls
Magic bullets
Vore balls
Lightning
Rockets...)

What else?

Now, if somebody wanted moving light sourced from specific textures on doors, func_trains, and such, then I can see that being more of a problem. 

But a cleaner solution than what?

I asked if you knew how DarkPlaces does it. And clearly, you don't.

One would naturally conclude:

- You have so little interest in the feature that you never have used it for yourself in DarkPlaces. 

My only interest in colored dynamic light is from a mapping point of view. It just looks very weird to see the fireballs, rising from deep orange-red lit lava, giving off pure white light.

The others I mentioned would be nice, rockets etc., but beyond that I don't see it as all that necessary for Quake. 

But a cleaner solution than what?
Than a solution used in Darkplaces, which you clearly see as ugly. I trust your opinion.

You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
I have little interest in Darkplaces.

But it's pretty clear from your reaction that this is an unwanted conversation for you. 

Like the rather icky r_noshadow_list stuff, could we just not whack a great big string into the config file that maps modelnames to colours?

It's ugly but we already have a precedent for doing things that way...

//

That particular texture was really quick because it's just quick splotchy strokes with a bit of shade and highlight. Doing precise metalwork shapes and stone carving decor and whatnot is a bit slower obviously. 

Maybe if you educated yourself to understand what it is you think you want, you might see why it is unlikely to happen.

But instead, all your bring to the table is
- a lack of knowledge
- can't even be bothered to try it in DarkPlaces
- ignorance of not knowing what you are asking for

I think it is a bit rude to ask the Quakespasm guys for something you don't even know what it is, nor how it should work. 

On adding too much to the engine...

"Like reading a certain entity field (if it is defined in QC), for example. "

I'm pretty sure that is the kind of hackiness that baker was talking about. Modding in the engine is counter to what the philosophy of mods is to begin with.

Mods are programmed within the framework of what they're allowed to access / execute. Not only does it add bloat, but it also has the potential to break that mod for other engines. As soon as you bypass the vanilla framework you might as well just hard code the progs into the executable.

These features can be added, but where do you draw the line? I think the QS (and beyound that fitzquake) developers have done a great job at keeping engine bloat to a minimum.

I honestly think that quakespasm is not suited to visual enhancing features like darkplaces and co.

But you know what I did when I wanted IRC support in quakespasm? I learned some C and forked it myself. I wholeheartedly recommend that if you really want a feature added, then this is the way to go, not only do you learn a new skill, but you also get the feature that you want.

/rant over. 

I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while 

Let me get this straight. Before I request a feature in an engine I'm interested in I need to:

- Be a programmer myself;
- Try the feature in an engine I'm not interested in;
- Understand that the feature is hopeless crap using my programmer knowledge;
- Never ask for it, because it's crap.

Did I miss anything?