Some people complains that searching for replacement textures through all the possible paths from all the different standards takes a lot of time under Windows.

And then I remembered that when I started expanding the number of savegame slots to 100 saves in the Dreamcast version of Makaqu, it also resulted in massive slowdown when scanning for saves. The VMU interface is freakingly slow. But there was a solution.

When you search for a specific file, the operational system will read each file entry from the specified location, until the desired file is found. This is fine when you just want to load a single file, but it's idiotic when you're actually going to load many files from the same location.

The solution, in the Dreamcast case, was to scan each and every file entry from the location only once, in an unordered fashion (the physical order in the filesystem), while checking every one for compatible savegames. The logic is simple: If the file you want is physically the last file in a filesystem location, the OS will scan all file entries from that location anyway. Subsequent searches for other files from the same location would make the OS scan the same non-matching files multiple times, resulting in lots of redundant work.

I bet a similar solution would work under Windows. Linux probably caches file entries in the RAM automatically to prevent redundant scanning of physical storage devices. 

You can enumerate paths one time only at startup then only search the paths that actually exist when loading textures. Sort a PAK file directory and binary-search it. Use the native API which has faster calls for determining if a file exists rather than putting everything through stdio.

The point is, you can be a little intelligent about how you approach problems and it doesn't require creating hugely complex code. 

It's better to do the path enumeration at the beginning of map loading, in case the user alt-tabs to add more assets without closing the engine.

I often add more external textures and reload the map in-game when mapping. 

Yeah, that would work better. 

...TB including a GL-filter mode as default so when we're watching streams of people making otherwise awesome looking maps, we don't have to have them ruined by shitty square pixels everywhere when the mapper is zooming around in and out of brushes.

Also I want to see the return of Baker once his hangover finishes. 

Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer. 

Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment. 

TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D ) 

[10:23] Kinn: @Shambler - are you sure that your blurry vision quake mode doesn't just make the surfaces of the world just appear all smooth and sterile and devoid of life?
[10:25] Shambler: i don't have blurry vision quake mode, i have smooth vision quake mode
[10:25] Shambler: and generally to avoid "sterility and devoidness of life" in any imaging situation, my first thought isn't "add lots of little squares like a mosaic"
[10:25] Shambler: unless, of course, i wanted a mosaic
[10:25] Shambler: which i don't 

 

Texture filtering in Quake was a mistake. 

Your conception was a mistake. Your mom told me as much. 

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. 

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. 

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. 

Good filtering is much more important with high resolution images than it is with low res stuff (where it just makes them blurry). 

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. 

Ok, since metl mentioned it, the sparkly pixel movement phenomena is temporal aliasing. I want temporal antialiasing in Quake. 

 

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. 

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. 

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. 

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. 

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. 

Centerprint with constant cheesey rhymes