Func_Msgboard: New Fitzquake

News | Forum | People | FAQ | Links | Register | Log in

|  | New Fitzquake

Posted by metlslime [66.135.131.132] on 2003/09/27 08:06:03
Fitzquake 0.75 is finally here. New in this version: rewritten bsp renderer, 2x overbright lighting, .lit support, new water animation, and a typical long list of bugfixes and optimizations. Download and more info on the Fitzquake homepage: http://www.celephais.net/fitzquake...

Wow
#1 posted by nitin [203.45.40.182] on 2003/09/27 08:57:44
this is worth getting simply for the new lighting rendering, nice work metl. Just wondering as I couldnt work it out, do you have to have the oberbright cvar set to 2 or 1 to get the emulated software lighting? I'm using 1 and it looks damn fine but just thought I'd ask anyway.
Also, is the edict limit raised in this and/or are you planning to? This'd be the enging of choice once model interpolation's in, guess I'm just used to smooth anims but nromal gl looks too jerky now.
Looks Great
#2 posted by aguirRe [62.127.45.249] on 2003/09/27 08:59:11
I've tried it briefly and so far I've only seen a strange phenomenon in an old map (junk.bsp) where there is a "reactor core" that should flash in red (texture +4_red).
In the previous versions it works as expected but in 0.75 it flashes between red and a checkerboard texture. Nothing major, but looks kinda weird ...
What gives?
Nice
#3 posted by Abyss [203.51.206.7] on 2003/09/27 09:30:39
Some nice stuff there. But I'm with nitin, the animations are too jerky without model interpolation. I use an older version of nglquake, and it is silky smooth, so much so that any other engine I try that doesn't have it, just seems far too jerky, and I just can't use it.
Screenshots?
#4 posted by rhY [68.111.217.166] on 2003/09/27 13:18:49
What no screenshots anywhere? i'll just use something else for now then.
rhY
More Bad News ...
#5 posted by aguirRe [62.127.45.56] on 2003/09/27 14:16:51
When loading up q1tm2_pushplay, I get the "Bad surface extents" error dialog although there are no missing textures at all. FitzQuake 0.65 & 0.70 works fine with that map.
I also noticed once that there was a distinct green glowing spot on one of the otherwise brownish rock walls in the beginning of "Moonlite Assault".
I haven't been able to repeat it though. I have no .lit files for that map so I don't understand where the coloured green light came from.
As for the jerky animations, I actually prefer that over the smoother ones ...
Haven't Tried It Out Yet,
#6 posted by necros [66.185.84.208] on 2003/09/27 16:49:16
but for model interpolation, i prefer it but not on the weapon models. the muzzle flashes look really wierd with it.
Aguire
#7 posted by pushplay [24.86.74.102] on 2003/09/27 16:58:13
It's been long since established that I shouldn't be in charge of compiling my maps.
Heh, Only This Time
#8 posted by aguirRe [62.127.47.23] on 2003/09/27 17:14:49
I actually believe it's not your fault ...
Ack! Bugs Already!
#9 posted by metlslime [66.135.131.132] on 2003/09/27 18:33:08
aquiRe:
The broken texture in junk.bsp is actually +0_red. Not sure why that frame isn't showing up, but i noticed that the problem doesn't occur on those security lasers, which use the same texture. Those are bmodels and the reactor is part of the world, so i'll have to find out why that matters.
Regarding "bad surface extents" in q1tm2_pushplay: i'd like to note that this error also occurs when you load the map in Winquake. Pushplay: which compiler did you use for that map?
As for the green spot on the wall, did you get a screenshot?
Followup:
#10 posted by metlslime [66.135.131.132] on 2003/09/27 18:39:57
<metlslime> do you have the original retarded set of command line options you didn't comprehend?
<pushplay> qbsp -transwater -verbose -oldaxis -oldtexpos -subdivide 270 q1tm2_pushplay.map q1tm2_pushplay.bsp
<metlslime> SUBDIVIDE 270!!!!
<pushplay> I know
<pushplay> I just did what I was told
Nitin:
#11 posted by metlslime [66.135.131.132] on 2003/09/27 19:09:27
gl_overbright {0,1}
This variable controls overbright lighting on the world polygons. (For lighting on models, use gl_overbright_models.) If 1, overbright will be enabled and lighting will resemble software Quake. If 0, overbright will be disabled and lighting will resemble GLQuake. Default 1.
NOOO
#12 posted by metlslime [66.135.131.132] on 2003/09/27 19:10:15
i suck at the internet.
So Pushplay Was Guilty
#13 posted by aguirRe [62.127.47.245] on 2003/09/27 21:58:48
anyway ...
No, I didn't make a screenshot of the strange green luminescence on the rock wall in "Moonlite".
I also just confirmed that the "Bad surface extents" in q1tm2_pushplay also happens with TyrQuake (WinQuake) and indeed it seems to be the same thing as what happened in the Coagula2 contest.
It's probably the subdivide thingy that causes the trouble. Don't know why though ... but better keep it at default 240.
Still, FitzQuake 0.65 & 0.70 were both fine with this map ...
Well...
#14 posted by metlslime [66.135.131.132] on 2003/09/27 22:14:02
glquake and previous fitzquake versions have the max surf extents set to 512, while winquake and fitzquake .75 set it at 256.
I don't fully understand the 256 limit either, but i figured that since compilers default to 240, and winquake can't take above 256, that i'd be safer with 256. Nobody would intentionally break winquake support by using a higher subdivide value, i thought.
So maybe i should revert or remove the surface extents check, in order to support broken maps like q1tm2_pushplay.
Rehashed
#15 posted by pushplay [24.86.74.102] on 2003/09/27 22:16:20
The easy solution would be for me to recompile my q1tm2. Too bad I'm not going to do that.
Cheers Metl
#16 posted by nitin [203.45.40.182] on 2003/09/28 03:36:01
what about the edict limit?
Nitin:
#17 posted by metlslime [66.135.131.132] on 2003/09/28 04:07:12
the current version does not have a bumped edict limit.
I hadn't actually planned on doing this in the future, but i'm not really opposed to it either.
Well
#18 posted by nitin [203.45.40.182] on 2003/09/28 04:16:27
it just makes some maps able to run like nesp09 that's all.
Subdivide
#19 posted by aguirRe [62.127.44.212] on 2003/09/28 06:01:03
Why not restore the previous capacity so the map can load in FitzQuake, but issue a warning so the mapper is informed of exceeding this capacity?
AguiRe:
#20 posted by metlslime [66.135.131.132] on 2003/09/28 06:40:36
well, i think i'll actually investigate whether there's a problem loading or running a map with polygons of ANY large size. Maybe the test doesn't make sense in a GLQuake-based engine.
...
#21 posted by starbuck [82.33.88.154] on 2003/09/28 12:45:08
i have to say, the overbright lighting adds a hell of a lot to the visuals, and gives the engine a real authentic software quake feel. What an excellent release!
I do find the lack of model interpolation a strong enough negative factor to stop me using Fitzquake as my default engine, however; add me to the list of people politely requesting the option in a future version :)
The only 'bug' i encountered was the shells box had a white line at its lower rim (as it touches the floor), quite noticable in some places. But all in all, gg!
Shells Box, White Line
#22 posted by Abyss [203.51.206.141] on 2003/09/28 16:14:08
Yes I noticed that as well.
Shells Box, White Line
#23 posted by metlslime [66.135.131.132] on 2003/09/28 18:55:19
The only 'bug' i encountered was the shells box had a white line at its lower rim (as it touches the floor), quite noticable in some places. But all in all, gg!
That is actually a bug in the texture on the model, and is visible in all gl engines. If you set gl_texturemode to one of the gl_nearest_* modes, it goes away. Actually, it ALMOST goes away, becuase you can still see individual white pixels now and then.
Anyway, maybe i should edit the texture and put the fixed model up for download. I've been meaning to do that; just never got around to it.
I Never Noticed That Before.......................
#24 posted by Abyss [203.51.206.141] on 2003/09/28 19:55:44
It doesn't appear on the shell box (20), but does on the shell box (40). I checked it out in the engine I use, nglquake, and it took me a while to find one, I thought you must have been smokin' some wild gear there for a while ;) Then I found one, and found that it only happens with the 40 box. Don't know why I never noticed it before, unless it is more pronounced in fitzquake for some reason ?
#25 posted by Vodka [195.242.17.67] on 2003/09/28 20:45:58
freezes computer on any map load
I Checked Tomazquake
#26 posted by starbuck [82.33.88.121] 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 [66.135.131.132] 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 [203.45.40.182] 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 [66.135.131.132] 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 [66.135.131.132] 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. [24.136.233.191] 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 [66.185.84.208] 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. [24.136.233.191] 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 [64.124.188.211] 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
#35 posted by NotoriousRay [209.163.110.135] on 2003/09/29 21:17:56
i light for gl, software can suck it
...
#36 posted by starbuck [82.33.88.121] 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 [213.65.179.30] on 2003/09/30 11:40:34
why light for the bad lighting model nyyyyyyargh
Starbuck
#38 posted by Vodka [195.242.18.202] 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 [82.33.88.121] on 2003/10/01 03:37:01
my brain can only cope with one at a time anyway ;)
Hmm
#40 posted by nonentity [195.38.74.8] 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 [195.38.74.8] on 2003/10/03 08:38:57
That should be GL (or gl possible)
GIQuake?
#42 posted by R.P.G. [24.136.233.191] on 2003/10/03 10:02:51
GIQuake: Counterstrike for Quake?
I Hate Standard Glquake.exe With A Burning Passion
#43 posted by cyBeAr [213.65.179.30] on 2003/10/03 13:03:26
because it looks blah
I Like Software Quake
#44 posted by PuLSaR [80.80.96.72] on 2003/10/03 16:31:23
cuz oldskool maps look even more oldskool in it :)
Another Vote For Software
#45 posted by glassman [81.128.212.98] 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 [217.70.16.165] 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 [64.124.188.211] 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 [213.65.179.30] on 2003/10/03 18:43:08
I use gl_texturemode gl_nearest_mipmap_nearest
Bah!
#49 posted by underworldfan [128.195.84.154] on 2003/10/03 18:47:10
GL > software.
Bah!
#50 posted by metlslime [64.124.188.211] on 2003/10/03 19:00:15
ugly rendering problems in glquake > ugly rendering problems in software quake.
Hmm...
#51 posted by metlslime [64.124.188.211] on 2003/10/03 19:14:28
maybe all of this disagreement is caused by people talking about two different things. When you say gl is better, are you saying that you like hardware rendering? Or are you saying that you think that glquake is a really swell implementation of quake? Becuase i agree that hardware rendering looks nice. I just think glquake is a shoddy hack job that breaks or worsens a bunch of quake features such as the lighting, water warp, underwater warp, fullbrights, sprite orientation, the sky projection, handling of odd-sized textures, etc.
.
#52 posted by necros [66.185.84.208] on 2003/10/03 19:14:38
i'm starting to really like fitzquake!
two things though:
is it possible to have the mipmaps only with distance, and not angle?
how do you change the maximum vertical angle of the camera back to the normal angle in quake? (when looking up and down)
Necros:
#53 posted by metlslime [64.124.188.211] on 2003/10/03 19:16:31
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.
regarding the looking up and down: yes. Read the manual about cl_minpitch and cl_maxpitch.
Metlslime:
#54 posted by Scampie [66.231.198.213] on 2003/10/03 19:48:14
is that like that old map called 'thefly'?
Scampie:
#55 posted by metlslime [64.124.188.211] on 2003/10/03 19:51:44
no no... it's that map from Markus Klar... you know, back in 1997? The Fly or something....
...
#56 posted by necros [66.185.84.208] on 2003/10/04 15:02:53
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.
well, ok, but it's impossible to stop it from mipmapping on the angle?
Necros:
#57 posted by metlslime [66.135.131.75] on 2003/10/04 19:00:41
you can stop it from mipmapping based on angle. Here's the step-by-step process:
1. turn off mipmapping.
Software In GL
#58 posted by glassman [81.128.212.98] on 2003/10/04 19:15:28
As Cybear said gl_texturemode gl_nearest_mipmap_nearest looks good & with r_particles 2 at 1600x1200x32 it looks pretty neat :)
The lighting is certainly better but doesn't really have all the characteristics of software. It looks like the same colours but brightened whereas software switches through that lurid palette.
Wow! Really?
#59 posted by necros [66.185.84.208] on 2003/10/04 20:57:13
sounds really easy! thanks!
<rolleyes>
#60 posted by Vodka [195.242.18.229] on 2003/10/05 00:47:19
gl_nearest_mipmap_nearest
is still mipmapping
gl_nearest is none
_mipmap_linear should be trilinear mipmapping, it looks pretty good, but might not work on some cards
go to drivers/tweakers and turn on anisotropic filtering in openGL (its slow on older cards tho)
or try to shift mipmap bias to like -2 ( it can be called textre lod, or mipmap lod)
software quake looks so special and ugly mostly cause it uses palette shift on the textures instead of lightmaps
Necros:
#61 posted by metlslime [66.135.131.75] on 2003/10/05 01:40:27
sorry, i thought you knew about gl_texturemode.
Lighting Stuff
#62 posted by Mr Fribbles [202.161.117.131] on 2003/10/05 22:48:13
I try to make the map look decent in both software and GL, but since the lighting models are so different, that can be difficult. I lean more towards tweaking it for software Quake though, since software has the superior lighting system.
In my own opinion/experience, its better to light levels for software (assuming you want it to look ok in both software and GL). Usually I find that if I tweak lighting to get it 'just right' in GL, its dark as fuck in software and I can't see enough to play properly. Whereas if I light it for software, its pretty decent in GL (although perhaps a little too bright or flat).
Standard GL lighting is so dodgy compared to software anyway, that it almost doesn't matter... you don't get the nice overbrighting and falloff that you do in software. Authords of engines like fuhquake/zquake (and Fitzquake now it seems!) seem to be making the lighting in GL a bit more 'software like' anyway, so I figure that eventually the levels will end up looking like they're supposed to once everyone is using GL engines with better lighting.
Texturemode
#63 posted by Mr Fribbles [202.161.117.131] on 2003/10/05 22:53:56
I did a bit of experimenting a while back with texturemodes and stuff for glquake... in the end I found that it looked the best overall (to me) when using gl_texturemode gl_linear along with antialiasing and/or anisotropic filtering.

Post A Reply:

Name: |
Title: |
Body: |

Website copyright © 2002-2011 John Fitzgibbons. All posts are copyright their respective authors.