I Checked Tomazquake
#26 posted by starbuck on 2003/09/29 04:41:07
and i couldnt find any (is it a gl engine?), ive got screenshots of the same shells box in both engines too
Starbuck:
#27 posted by metlslime on 2003/09/29 05:11:17
I just checked and it is present in GLQuake, and Darkplaces, but not tomazquake. Tomazquake is a gl engine, so i'm going to check the source to see what cheap hack he employed to eliminate that problem.
Question About Software Lighting
#28 posted by nitin on 2003/09/29 05:25:46
do you mapper people light maps with software or gl in mind? Just interested to know.
Followup:
#29 posted by metlslime on 2003/09/29 06:22:09
i looked in the TQ source, and he does indeed have a special hack where he replaces that row of white pixels with a row of more sensible green pixels. I wonder if this would be better or worse than a "fixed assets pack," from a user standpoint.
Speedy:
#30 posted by metlslime on 2003/09/29 06:24:40
that sucks. Can you tell me which OS, video card, etc? Not that i have a clue how to fix it when windows locks up, becuase i don't know (even in theoretical terms) what causes it.
Nitin
#31 posted by R.P.G. on 2003/09/29 12:01:20
I light maps primarily for GL, but I also try to make sure software is good or at least playable.
Nitin,
#32 posted by necros on 2003/09/29 17:47:15
I light only for GL. i can't be arsed to light for software. i hate lighting enough as it is.
TBH
#33 posted by R.P.G. on 2003/09/29 18:08:54
The way I lit could.bsp was to light the first 1/3 of the map and check it in both GL and software. After that, I just copied the light ents from that section into the rest of the map and then only tested the lighting in GL. In fact, I even forgot to test the final map in software until metlslime mentioned the square spotlights (which I couldn't be bothered to fix).
Pro Tip:
#34 posted by metlslime on 2003/09/29 18:36:18
if you bind a key to "toggle gl_overbright" in fitzquake, you can run around the map seeing both winquake and glquake lighting at the touch of a button!
Hrm
i light for gl, software can suck it
...
#36 posted by starbuck on 2003/09/30 06:55:38
if you light for software, its more likely to look washed out in GL, but if you light for GL it usually has nice contrast in software i find. Binding a key to "toggle gl_overbright" in Fitzquake as metl suggested would be a good way of testing it out though...
Lighting For Gl = Blah
#37 posted by cyBeAr on 2003/09/30 11:40:34
why light for the bad lighting model nyyyyyyargh
Starbuck
#38 posted by Vodka on 2003/10/01 00:40:17
"if you light for software, its more likely to look washed out in GL, but if you light for GL it usually has nice contrast in software.."
true
Glad You Agree
#39 posted by starbuck on 2003/10/01 03:37:01
my brain can only cope with one at a time anyway ;)
Hmm
#40 posted by nonentity on 2003/10/03 08:38:08
I light for Gl because I hate software quake with a burning passion
Hmm
#41 posted by nonentity on 2003/10/03 08:38:57
That should be GL (or gl possible)
GIQuake?
#42 posted by R.P.G. on 2003/10/03 10:02:51
GIQuake: Counterstrike for Quake?
I Hate Standard Glquake.exe With A Burning Passion
#43 posted by cyBeAr on 2003/10/03 13:03:26
because it looks blah
I Like Software Quake
#44 posted by PuLSaR on 2003/10/03 16:31:23
cuz oldskool maps look even more oldskool in it :)
Another Vote For Software
#45 posted by glassman on 2003/10/03 18:00:08
The wild lighting & the gritty pixels. A GL engine that could replicate both & play at 1600x1200 would be great. Is the pixel blurring an inherent part of GL or could it be toggled out?
Glassman
#46 posted by Vondur on 2003/10/03 18:14:00
Sure you can play as if in software mode
Go to console and type:
gl_texturemode
usually, it's bilinear filtering so it'll print this:
gl_texturemode gl_linear_mipmap_linear
if you want to play in softwarelike mode type the following:
gl_texturemode gl_nearest
that's it, enjoy your square pixels :)
Glassman:
#47 posted by metlslime on 2003/10/03 18:38:38
as far as i know, you can't perfectly replicate software quake in opengl, because they do mipmapping differently -- quake did it based on distance only, and 3d hardware does it based on distance AND angle to the camera --which is why a wall or floor at a sharp angle to the camera has such a blurry texture on it.
But you can get rid of the linear filtering of pixels by using a gl_nearest_* texturemode. And with anisotropic filtering, i think gl_nearest itself might look pretty good even though it lacks mipmapping.
Pro Tip: if you want square particles like in software mode, set r_particles to 2 in fitzquake.
Fitzquake Is Good Glquake
#48 posted by cyBeAr on 2003/10/03 18:43:08
I use gl_texturemode gl_nearest_mipmap_nearest
Bah!
GL > software.
Bah!
#50 posted by metlslime on 2003/10/03 19:00:15
ugly rendering problems in glquake > ugly rendering problems in software quake.
|