News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
 
Pixel art exists due to hardware limitations of the past as well. So?

Then again, I'm one of those misguided individuals who still produce art that's neither pixel art nor "good" art. My motives in this conversation are pretty obvious. 
Just A Comment 
I did not grow up playing Quake DOS and the first time I did play Quake was the N64 version. I started messing with Quake PC last November and used the Epsilon mod. I originally enjoyed the flashy visuals and weather effects but eventually I transitioned to Quakespasm and never looked back. I am just putting this here as someone who isn't specifically biased to old school quake...ness.

Anyway, I would love to see weather effects in quakespasm/maps. I'd make every flipping one of my maps rain because I love rain in games. 
 
Sitting next to his partner Kevin Cloud, [Adrian Carmack] clicks his lightpen all day long, making minuscule adjustments, one pixel at a time, to countless texture tiles: lichened stone, pitted wood, corroded metal, viny corpuscular stuff. - Wired

vs

Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time - some fucking rando

Who do I trust?? 
 
Technically, Quake has little to no pixel art. Pixel art (in the modern sense at least) requires you to work with the palette colors directly, and 256 colors is a bit too much to handle efficiently.

Still, this kind of art (when it's done well) shares some traits with pixel art, such as a high level of precision when small details are concerned. It's kind of a necessity when you only have so many pixels to convey an idea. 
 
Mugwump, if you want rtlighting in quake, you need one of FTE, DP, or Tenebrae. They each have different featuresets and their own compatibility quirks too, hurrah.

I personally tend to use vanilla content more often than not. Its at least more consistent with itself, and imho replacement models tend to have goofy animations that I can't stand. Maybe I just don't like change. 
 
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. 
There's Something Magical About Low Res / Pixel Art 
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. 
Sieg Heil 
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 
 
 
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. 
I'll Write Something Relevant To The Thread For A Change 
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 
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 
Do you know how DarkPlaces does colored dynamic lights?

(Hint: it's not pretty) 
Damn 
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) 
Kinn 
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 
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. :( 
 
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 
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. 
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.