News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake 0.85 Released At Last!
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.

Go! http://www.celephais.net/fitzquake

(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.)
First | Previous | Next | Last
Yhe1: 
in the console, type "max_edicts 2000" or similar. (default is 1024.) 
Metlslime: 
What's the technical solution used for "gl_flashblend 0" effects? Firing rockets with that setting is a real fps killer on my hardcore intel integrated graphics :( (apart from that FQ runs very well) 
Bear: 
the app keeps local copies of all lightmaps; when dynamic lights touch a surface, the dynamic light is added to the static light levels and the new data is uploaded to the texture using glTexSubImage2D.

Does fitzquake 0.85 actually run slower than earlier fitzquakes, or any other glquake ports with the same setting? 
Seems To Be For Fitzquake >065 
vanilla Glquake also runs fine so I guess it has to be related to some of the changes you've made.

I'm mostly interested in figuring out the limits of the graphics card (GMA4500mhd) to avoid running into problems with projects of my own. It seems the intel drivers are lagging far behind in OpenGL support compared to DirectX and so far the lesson seems to be to stay away from OpenGL if you want to be safe :| 
Hmmm.... 
well, adding colored light capability in 0.75 probably increased the total amount of upload data somewhat (3 bytes per sample instead of 1) but if you also have the problem in 0.70 i'm not sure what it could be. 
Intel 
Fitzquake 0.80 had graphics problems on my Intel G945 card, but not 0.85. Aguirre's nehquake works fine also. 
Yhe1: 
there are a couple of intel-specific fixes in the latest build, for example the "loading" icon isn't drawn because intel doesn't like rendering to the front buffer. Plus, some sort of alt-tab fix. Glad it all works! 
Hmm That's Pretty Weird 
If nothing related was changed between those versions. 
Bear: 
well, in my 0.70 changelist it does say "dynamic lighting has been moderately sped up." So maybe I actually did something to make it slower, instead, at least on some cards. 
Hmm Yeah 
and not just slower but awfully slow in this case.. one nice thing I learned by testing all the different fitzquakes was that generally FPS has been improved a lot and in 0.85 and seems to be in the 100-200+ range as long as there's no dynamic lighting but fire a rocket and it can drop as far as into the single digit realm. 
 
One thing that has bothered me for a while is that While playing Quake with Fitzquake/Aquirre Quake is that you sometimes get lower framrates when there a lot of of light flickering/torches, such as at the beginning of Nightjourney and Five Rivers Land, or Event Horizon. I know that r_flatlightstyles can be used to fix this, but then the flicker lights are gone also. However, If I use an Old version of Darkplaces, such as DPnehahra, DP1.05, or DP1.02, I can get good framerates as well as keep the dynamic light. Does anyone know why DP can do this and Fitzquake/Aguirre Quake cannot? 
Yhe1: 
i'm not really sure; in general, fitzquake and aguirre quake are much closer to the original glquake in terms of lighting code, and darkplaces is much more modified. As to why old darkplaces does it well and new darkplaces doesn't, that i also don't know.

How does glquake itself compare? And what about older versions of fitzquake? 
Metlslime 
To be honest with you, I never noticed such frame rate drop down with my maps (i.e Five Rivers Land / Event Horizon), whatever the engine I used in between aguirRe's GLQuake, and your engine...
Maybe it depends also of the CPU speed ... though.. 
 
Metlslime:

I used to think that it was the flickering lights itself lead to the framerate drop, but then like I said, old DPs do not have this problem.

For the record, the Old DP did not have problems generating the Doors to Ricky's map either.

I don't have the original GLquake, but Fitzquake 0.80 also had the framerate drop, as did Agirre nehquake and nehwarp

JPL:

I believe the framerate problems were reflected in the FRL and the EH threads by multiple people. I used the old DP to run your maps because I think that dynamic lights adds to the atomsphere of a base map. Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP. 
5river 
I did notice it even on a fast computer. Try to add
-nomtex to the command line, that helped. 
Intel GMA (integrated Media) 
http://en.wikipedia.org/wiki/Intel_GMA

The problems bear and yhe are having with Intel GMA cards are not related to the "computer" or the "cpu".

These Intel GMA cards are default 3d accelerator ("onboard intergrated video card") on all machines with a Intel processor (even Intel Mac Minis).

If you have an Intel processor and didn't buy a graphics card, this is what you have (2001 and later). This is most computers .. well not most .. the overwhelming majority.

Their performance is "fair", about 120-250 frames per second with standard GLQuake with the default settings (gl_flashblend 1, etc.).

It is very nice that metlslime added in the "Intel display adapter fixes" to make it so a lot more people can use FitzQuake.

But keep in mind, the performance of these is on the lower end of the spectrum.

If aguirRe's GLQuake has the framerate drop too -- consider that the lighting in that engine is original GLQuake (no lit support, etc.) and original GLQuake is 1997.

The Intel GMA series is nice in the sense that virtually all computers can be expected to be able to play games, but it is still on the low end of graphics performance.

They have OpenGL 1.2 compatibility with some drivers having portions of the OpenGL 1.3/1.4 specification.

/Note: in old DarkPlaces there are some comments by LordHavoc stating "major lighting speedup" in the dynamic lights section. 
Intel Opengl Compat 
The higher end GMA:s (including mine) have OpenGL 2.0 support with the latest drivers and if intel felt like implementing more than that it should be possible considering what the card supports in DirectX. 
On Intel Topic Pherhaps But Not Really FQ 
Found this Direct3D quake port which seems to run really great: http://sourceforge.net/projects/direct3dquake/ 
Bear 
Give MH's new engine a try, it's DirectX 9 or 10 and definitely better than that old one: http://forums.inside3d.com/viewtopic.php?t=1306 
Spirit: 
Well maybe you should have checked the link because "that old one" seems to be the same one you suggest! 
Yhe1: 
It sounds like all glquake ports will give you the same problem, with the exception of engines that specifically improved things.

I'll check out darkplaces again and see what I can learn from it.

Can you tell me if the version of darkplaces that runs fast also supports .lit files? 
 
Yes, the old DPs also supports lit files 
DP Version 
I downloaded several DP sources to identify the first version with the dynamic lighting speedup, DarkPlaces 0.72 appears to be the first occurrence.

http://icculus.org/twilight/darkplaces/files/2000/darkplacesengine72.zip

The important changes appear to be in gl_rsurf.c and r_light.c (R_DynamicLightPoint, R_DynamicLightPointNoMask, RecursiveLightPoint, ...) 
Dear Bear 
oops, I thought you linked to http://dxquake.sourceforge.net/ 
#64 
Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP.

Yhe1: Unfortunately, I do not test my maps with DarkPlace. I am using metlslime FitzQuake (0.85 now) as reference engine, and I think it is largely enough... So I cannot ensure that you will not face issues with old DP version... sorry for this ;) 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.