Sieg Heil
#2215 posted by Kinn on 2016/08/22 18:58:33
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...
Literally Quake Hitler
#2216 posted by killpixel on 2016/08/22 19:02:43
Making all those references to the not shooting Hitler bit from The Office has finally taken its toll.
#2218 posted by dwere on 2016/08/22 19:16:09
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.
I'll Write Something Relevant To The Thread For A Change
#2219 posted by dwere on 2016/08/22 19:19:32
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.
Textures
#2220 posted by Kinn on 2016/08/22 19:42:45
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
@dwere
#2221 posted by Baker on 2016/08/22 19:53:26
Do you know how DarkPlaces does colored dynamic lights?
(Hint: it's not pretty)
Damn
#2222 posted by killpixel on 2016/08/22 19:53:52
that looks great
#2223 posted by Baker on 2016/08/22 19:55:40
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)
Kinn
#2224 posted by dwere on 2016/08/22 20:26:47
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.
Baker
#2225 posted by dwere on 2016/08/22 20:35:17
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.
From My Experience
Dynamic colored lighting does not go well with static baked-in lighting at all. :(
From My Experience
Dynamic colored lighting does not go well with static baked-in lighting at all. :(
#2228 posted by Rick on 2016/08/22 20:46:07
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.
Well -- First
#2229 posted by Baker on 2016/08/22 20:47:58
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.
#2230 posted by Rick on 2016/08/22 20:56:57
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.
#2231 posted by dwere on 2016/08/22 20:59:15
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.
Coloured Dlights
#2232 posted by Kinn on 2016/08/22 21:05:46
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.
@dwere
#2233 posted by Baker on 2016/08/22 21:07:34
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.
To Anybody Who Cares To Read This Rant.
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.
Directq And RMQ
I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while
#2236 posted by dwere on 2016/08/22 21:26:44
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?
#2237 posted by Kinn on 2016/08/22 21:29:59
Posting in this thread is like playing Dark Souls; at first you'll find it cruel and unforgiving, but after many days, weeks and months of practice you'll intricately understand the attack patterns of the various mobs that lurk here, and be able to parry and counter their posts effectively.
No
before you request a feature you need to:
- Prepare yourself for the possibility that the developers don't want to implement it.
- Not get salty when you don't get the answer you want.
Shamblernaut
#2239 posted by dwere on 2016/08/22 21:42:34
By not getting the answer I want you mean stumbling on an edgelord that I'm not even sure is one of the developers?
|