#260 posted by mankrip on 2018/03/07 16:57:41
Quake with unfiltered textures looks great, if you play it in the originally intended resolutions. In 1996, 640*480 was the highest resolution that achieved playable framerates in most high-end machines.
I used to play it at 512*384 in a Cyrix MII-300 in the early 2000s. Had a solid 12 fps which was surprisingly enjoyable, and looked pretty good to me.
Nowadays, its texel-to-pixel ratio at the highest playable resolutions is poor.
Mankrip Knows What I'm Talking About
#261 posted by Qmaster on 2018/03/07 18:53:21
We don't need filtering, just higher texel density. Love my crisp edges!
I wouldn't mind seeing a coop episode in AD. Something that detects coop and requires two people to progress if coop is on. E.g. two pressure plates require both players on them to open a door...one player stand on a pressure plate while another shoots an exposed button juuust out of view of the player on the pressure plate. You could use the dual pressure plate idea to split players up across two sides of a room, Portal 2 style, and have them fighting and helping by shooting across the gap.
#262 posted by mh on 2018/03/07 19:13:47
Unfiltered Quake looks fantastic.
Aside from the sharper edges on things, textures just pop with detail compared to the filtered versions.
Compare:
http://www.quaketastic.com/files/screen_shots/Q1-Unfiltered.jpg
http://www.quaketastic.com/files/screen_shots/Q1-Filtered.jpg
More than just fullbrights and overbrights was lost in the initial SQUEEEEEEE-fest over GLQuake.
Actually
#263 posted by bal on 2018/03/07 19:17:46
Good filtering is much more important with high resolution images than it is with low res stuff (where it just makes them blurry).
#264 posted by metlslime on 2018/03/07 20:58:55
One thing i like about filtering is that how smooth it looks in motion, in unfiltered mode is the scene is very noisy/sparkly as you move the camera.
However, filtered mode makes each pixel less vibrant/contrasty, everything gets a little bit more gray and colors shift towards the local average. For example that wall texture in e1m6 has lots of little single pixels of green and blue that pop really nicely in gl_nearest, but in gl_linear they are dulled and dim, and blend into more of an average grey. I feel that's one of the main reasons quake world textures look better unfiltered, it's the pixel art precision of some details that get desaturated and dulled in filtered mode.
Agreed!
#265 posted by Qmaster on 2018/03/07 22:35:56
Ok, since metl mentioned it, the sparkly pixel movement phenomena is temporal aliasing. I want temporal antialiasing in Quake.
Get Him!!! (Yells The Engine Coders)
#266 posted by Qmaster on 2018/03/07 22:36:28
#267 posted by mh on 2018/03/07 23:47:00
GL_NEAREST_MIPMAP_LINEAR is the best compromise IMO. Sparkles are caused more by not using mipmaps than by using nearest filtering, and linear sampling between miplevels eases miplevel transition artefacts. The other improvement is to use screen-space derivitaves from unwarped texcoords when sampling warped textures, otherwise they shift between miplevels as they warp. One of those things you normally don't notice until it's pointed out to you, then you can't stop noticing it.
#268 posted by metlslime on 2018/03/08 00:08:24
yeah my settings are GL_NEAREST_MIPMAP_LINEAR + anisotropic set to the max. The thing i don't like about mipmapping in hardware rendering is how floors (and other edge-on polygons) blur into a solid color, and anisotropic reduces that problem quite a bit.
#269 posted by mh on 2018/03/08 00:15:30
Agreed, anisotropic is essential. Different people are different, so I tend to find anything beyond 4x is not that big a deal, but I won't go below 4x.
Edged Mipmapping Artifacts
#270 posted by Qmaster on 2018/03/08 00:29:45
It would be nice if there was a way to detect the edge of a face that also corresponds to the edge of a texture and clamp the texture so that it doesn't bleed the color from the opposite side of the texture over.
What I Would Like To See!..?
#271 posted by Redfield on 2018/03/08 05:54:48
I want to see all of the models from Banjo Kazooie converted to mdl, with all of the animations kept intact. The Quake marine's model should be altered to have a backpack on his back that Kazooie occasionally pops out of. Also, the Quake marine can now double jump, and on the second jump the player can see Kazooie pop out of the backpack and flap her wings. Also, I would like to see a map that completely re-creates Gruntilda's lair and... Ahh f*ck it, I'm just going to go play Banjo Kazooie...
Seriously, I would love to see some kind of volumetric fog implementation similar to what is seen in Quake 3.
#271
#272 posted by mjb on 2018/03/08 06:12:36
Centerprint with constant cheesey rhymes
Gruntilda Says:
#273 posted by Redfield on 2018/03/08 06:24:02
Ranger will end up slobbering,
after the Shambler gives him a clobbering.
And so forth.
Volumetric Fog Is Definitely A Good Call...
#274 posted by Shambler on 2018/03/08 11:23:35
...given how well normal fog can be used.
Also pretty sure the edges of objects have the same definition i.e. a straight fucking line, regardless of what texture mode you're in. Anyway, you're all wrong, I've been playing with GL since it first came out and fuck everything else.
#275 posted by eukara on 2018/03/08 14:38:42
Just adopt Q3 BSP already if you want stuff like volumetric fog. :)
#276 posted by mh on 2018/03/08 17:37:11
Another thing that no current Quake engine does, AFAIK, is gamma-correct mip-mapping: http://filmicworlds.com/blog/gamma-and-mipmapping/
What?!
#277 posted by killpixel on 2018/03/08 18:47:55
As you should know by now, the value 187 is actually half-way between o and 255.
192
#278 posted by Qmaster on 2018/03/08 22:33:39
And The Actual Quote Is Half Between 128 And 255
#279 posted by Qmaster on 2018/03/08 22:34:00
QMaster
#280 posted by mankrip on 2018/03/09 00:32:21
Wrong. The problem is that that article was very poorly written. Here's the actual equation for gamma-correct gray:
((255^2,2)÷2)^(1÷2,2)=186,083713
Most of the gamma correction articles on the web are poorly written.
#277
#281 posted by Spike on 2018/03/09 13:49:35
in terms of photon counts, that's entirely correct.
so if you want correct lighting, then you need a pipeline that is actually aware of srgb (eg: vid_srgb 2 - note that you'll need to reload all the textures too).
using hardware srgb extensions to basically disable srgb (yes, backwards, the extensions are all a pain to read, and with drivers giving the wrong results too) gives you brighter darks and also resists oversaturation much better (which makes rtlights+specular much more tollerable).
but yeah, dark areas being brighter kinda hurts the whole quake ambience, and it draws more attention to how rtlights have sudden cutoffs instead of fading to infinity. I'm sure deathmatch players would love it though.
also reduces banding with eg r_lightmap 1.
and regarding gamma-incorrect mipmapping - textures that get darker with distance is a feature, not a bug! :P
(or use dds files that were generated with a proper tool)
A Tronyn Release
#282 posted by Tronyn on 2018/03/09 21:30:14
Er wait the thread said "Realistically" ha ha. Inspiring to see all the ideas people have.
P.S. to Qmaster: Will email you soon (i.e. this month).
#280 & #281
#283 posted by killpixel on 2018/03/10 01:55:30
That's interesting. I probably should read up on that.
What - Realistically - Do You Want To See In Quake In 2018??
Realtime lightmap generation for in-editor preview.
@Tronyn, Good Was Wondering
#284 posted by Qmaster on 2018/03/10 02:00:28
+1 editor lighting preview.
|