News | Forum | People | FAQ | Links | Search | Register | Log in
Forcing Linear Filtering In Some Quake Mods (AD Etc)
Several of old Sock mods are using bright pixels and low resolution on purpose, instead of the default pixels blurring when the player is close to the wall or of objects. I want to restore the default behavior. I know it's possible (Sock gave the trick on the forum, a long time ago), but I'm unable to find it back.

So how do we remove the bright pixelization in mods, like "ivory", "mstalk", "xendar" mods?

Also, how can we unpack pack files, on a Mac (OS X)?
 
gl_texturemode GL_NEAREST_MIPMAP_NEAREST 
Sorry 
GL_LINEAR_MIPMAP_LINEAR 
Also 
gl_texture_anisotropy 16 
How Do I Apply These Commands? 
Do I put these commands into the autoexec.cfg file?

Currently, I use this:

r_shadows 1
gl_polyblend 0
gl_flashblend 0
r_particledesc effectinfo 
Doesn't Work Yet... 
I used the following in my autoexec.cfg file:

r_shadows 1
gl_polyblend 0
gl_flashblend 0
r_particledesc effectinfo
gl_linear_mipmap_linear
gl_texture_anisotropy 16
map ivory

I also tried adding 1 after gl_linear_mipmap_linear. But the map is still rendered with huge sharp blocky pixels. 
Small Pak File To Add? 
If I remember well, I believe that Sock hardwired the blocky sharp pixels into his pak file on purpose in his old mods (I'm pretty sure of that). To make the pixels behaving in the default way (blurry rendering on close range), I think we need to add a small pak file that was published on this site, several years ago. I'm unable to find back that file.

Maybe I'm wrong and there's another way. 
 
gl_texturemode gl_linear_mipmap_linear 
Yep! Working Great Now. 
Thanks otp. 
It Doesn't Work For All Mods... 
Mods "In The Shadow" (from Sock) and "Rubicon 3" still have large blocky pixels. I don't understand what is going on here, since these mods have the same apparent structures as other mods (a single pak0.pak file).

The previous commands are working for some other mods from Sock (ivory, mstalk, Zendar). But why not for Shadow and Rubicon 3? 
In Those Mods 
try changing the value mid-game via the console

if that doesn't work, maybe the mod is spamming the command every frame? that wouldn't be without precedent. 
It's Working From The Console While In Game... 
Kinn, yes what you suggest is working. But then how can I make it permanent? 
Also 
read the manual

the shadows mod says "Impulse 247 - Toggle texture filtering on/off" in it's readme. 
I Don't Have This In The Read Me Of Shadow... 
maybe I have an older version. 
Version Updated But... 
Okay, I've updated the version of Shadow. Impulse 247 works, but only once in the console from mid game. It doesn't work permanently from the autoexec.cfg file. What gives? 
Rubicon 3? 
It's a pack for Rubicon 2. 
Rubicon3... 
Strange, the version I have is newer (2016) than the version on qquaddicted (2014):

https://www.quaddicted.com/reviews/rrp.html 
Honestly 
Best just go on discord and ping the modders for an answer. 
What About Sock's Shadow And Its Textures? 
impulse 247 works from the console, but not from the autoexec file nor from the config.cfg file neither. I wonder how to make it permanent. 
Preventing A Mod From Overriding A Setting 
I was going to say that if the mod is forcibly setting gl_texturemode via its progs.dat (which appears to be the case with In the Shadows), that you might be out of luck ... but then I thought of a cute trick to prevent mods doing this sort of thing. Barnak, try putting this in your autoexec.cfg file:

gl_texturemode GL_LINEAR_MIPMAP_LINEAR
alias gl_texturemode ""


(The second line ends with a space followed by two double-quote characters.) 
Wow! 
iw, this works perfectly, for both Shadow and Rubicon 3.

Yhis is black magic, man! 
 
More voodoo from iw! 
#19 
I love this. 
Hah! 
Nice - that could be used to cock with so many things. I love it.

Now, what could I alias "bf" to? 
#23 
This got my mind racing with all sorts of wonderfully horrible things which "bf" could be redefined to do! But alas, it seems it's not to be. "alias bf whatever" has no effect.

From consulting the engine source, it turns out that there are three levels of precedence for console commands:

(1) "function" commands, like "bf" or "echo" or "map";

(2) aliases defined by the user;

(3) cvars, like "gl_texturemode".

Function commands take precedence over aliases, and aliases take precedence over cvars. So we can use an alias to redefine "gl_texturemode", but not "bf". And the world is a sadder place to be as a result.

FWIW, what I wanted to do was:

alias bf "skill 3; changelevel e4m6"

I was already trying to think whehter it would still be possible to finish the game with this in effect. 
#24 
In vanilla Quake, aliases have the lowest precedence priority (they don't overwrite any internal cvars or commands). I used that to make config files that are compatible with both PC and Dreamcast ports (returning no "unknown command" messages).

Darkplaces inverted that, allowing aliases to overwrite anything. 
 
mankrip, for my comments about precedence in #24 I was looking at the vanilla Quake source code. I don't use DarkPlaces.

In Cmd_ExecuteString() in cmd.c, the first word of the command line is checked first against function commands, then aliases, then cvars. So it looks like aliases would override cvars even in vanilla Quake. They certainly do in QuakeSpasm 0.93.1, in which Cmd_ExecuteString() looks essentially unchanged. Unless I'm overlooking something? 
 
You're right, I just verified it.

I still remember it working in that other way, maybe it's a QuakeDC quirk. 
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.