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
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 ;) 
JPL 
That's poor mapping style. Giving the map a quick run-through in the most common engines is not too much to ask. 
Negke 
I installed DP once, a while ago, and for some dark reasons it crashes after some minutes... so I decided to stick to more than most common engine... FitzQuake is the reference here, so it is largely enough for me if my maps run properly on it...

And I don't think it is a poor mapping style: it is rather a poor testing style :P 
Had This Slowdown On Fitz Too (0.80) 
 
Agree With JPL 
DarkPlaces doesn't mix well with ATI. It's ATI's fault for a long history of shitty Opengl support, but that doesn't change the fact that when Dark Places crashes it REALLY crashes. I lost my firewall registration information the last time my computer crashed after installing the latest ATI drivers and running Dark Places and it was a big hassle to get everything back in order on that front, so I will never take that risk again. 
Common Engines 
Testing in common engines is one thing, but darkplaces compatibility shouldn't be expected. DP is from my experience just too far removed from a regular quake engine for people to negotiate around it. It's like where you have horses and donkeys: they can interbreed, but the offspring is sterile. Usually things fall into two categories, made only for DP, and made for other engines. If the latter work in DP, then great, but often it's too much work or sacrifice to achieve. 
 
@JPL:

Does the old DPs still crash for you, like DP1.02?

And your new map, is it going to be limit breaking (the Fitzquake 0.80 limit)? 
Negke 
Ironically, one of your Travail secret maps also had the same Framerate problems as Five Rivers Land ;) 
Yhe1 
I don't remember which version it was.... so I can't tell you. Also, I deleted DP from my HD, just playing with aguirRe's GLQuake, and FitzQuake..

Fortunately, it was not as dramatic as HeadThump mentionned: I didn't had to re-install everything on my computer... 
 
The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it. 
Donkeys And Horses 
Lemme give you my canonical bugbear. When regular engines report the size of a sprite "model" in the QC fields mins and max, they set them to the dimensions of the sprite in pixels, relative to the origin of the sprite. Since quake renders at 1 unit to 1 pixel, this is a very useful feature, and Quoth uses this information to create a solid bounding box around wire-mesh/grill entities.

Darkplaces sets these fields differently. It reports roughly sqrt(2) times the largest dimension in each coordinate, effectively giving a bounding box for the sprite at any rotation. I didn't actually know it did this until someone reported that the quoth basetest wasn't completable. As a result of the difference, the solid bounding box generated by each mesh is much larger, blocking off the hole next to the mesh through which you must climb.

The thing is, there isn't much that can be done about this particular difference in engines, besides throw out the "solid" feature or make it much more effort to use (by requiring mappers to manually enter the dimension of the sprite on the entities). So even if I had known ahead of time, I probably would have said it was something for DP to fix. Perhaps it's a bit different when it comes to making maps compatible, but that's my take on the matter. 
Preach: 
probably best to let mappers place clip brushes. That's how I did it back when I had sprite-based grates in rubicon2. I decided to stop using them because:

1. they don't take the ambient or dynamic lighting at all (I actually had 6 frames which were the same grate but different light levels.)

2. on almost all non-fitzquake engines, they have ugly pink edges. 
Yeah 
The solid box is optional, you can also use clipping brushes. It's whether you want to allow projectiles to pass through or not. It seemed a shame to require an extra entity to be the invisible hull if you want to block shots as well as players. As for the orange edges, people can usually see past them, if you go for rusty textures at least. 
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.