 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. 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? 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.
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 As for the jerky animations, I actually prefer that over the smoother ones but for model interpolation, i prefer it but not on the weapon models. the muzzle flashes look really wierd with it.
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? <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 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. 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 Still, FitzQuake 0.65 & 0.70 were both fine with this map glquake and previous fitzquake versions have the max surf extents set to 512, while winquake and fitzquake
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. 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. 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?
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.
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! 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. 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 ?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |