what's a reasonable number for r_speeds now?

[Whirlingdervish]

I was wondering what you guys think is a reasonable number for a top-end on r_speeds in a q2 map that is intended for regular FFA DM.

I know that more people have higher end computers these days that are capable of rendering a lot more polys..

In a map I'm working on they vary from under 100 to slightly less than 4000.

I know exactly why the areas that run up to around 4000 show so many polys and I can still block some large amounts of visible brushes, but I kinda like how it looks as-is, and I'd rather not have to.

I was wondering if anyone thinks this is low enough to be playable..

[grieve[Q2C]]

this theme has often been discussed within the Q2 scene by Musashi and others.

4000 is hopelessly too high. it is not just for the rendering, it is Q2's dated netcode which can not handle this amount of details very well.

this means : you will get ridiculous lag when playing such a map online which spoils the fun for pretty much everyone.

the uppermost limit which has been called is something like 1600.
personally I think this is still too much, and you best aim for a maximum of 1000 visible polys for every area, with the option to allow slightly more if really unavoidable.

vis-blocking is no gimmick or luxury in Q2, it is essential.
consider using doors with areaportals if it is not possible in another way, and try to construct doorways in a manner which blocks the view of the engine into the next area.

yeah - donut doorways ;D

simplified and in own words:
set doorways between the areas which make you run around at least three corners, most of the time the engine will only look around two of them when it is precaching areas so it does not see the next big area behind this doorway.

[grieve[Q2C]]

[Paril]

Aslong as the map moves smoothly, r_speeds is like the command ID never implemented.

-Paril

[Yun]

For optimal speeds, try to keep them hovering around 800. All of my "official" maps (the yundm series) follow this rule.

[Mart[1001]]

I've run a DM server for more than five years now and, while my maps are not very pretty...I've always concentrated on net play for obvious reasons. Although 'a players' system is so much more powerful than it was five years ago, we're still talking about a very old game as someone else in this thread mentioned. And so, although 'a players' cpu and connection will help...don't let this influence your r_speeds as 'a player' has now come to expect a certain quality from his game...and so to push r_speeds and result in 'more lag', will only convince a player that 'this map is crap'. The secret is, don't go over 1000, but more importantly, don't average anywhere near that. You could get away with 1000 r_speeds, but only in a small space that would then be connected by smaller area's of around 300 r_speeds max. If 'a player' is surrounded by r_speeds of 1000, his screen may become shakey just momentarily. But the moment another player enters the same area, the stress on his system will double. Both these clients have to talk to the server to explain that they're looking at each other while drawing polygons at their limit. Also, this brings me onto the entity count. Because large open area's attract all of the action, Mappers tend to fill in with lots of entities(ammo/armour etc)...which combined with the maximum r_speeds produced...will cause every bugger to suddenly miss each other and shout 'lagg'...quake2 has to account for every bullet, loaded or unloaded, in that area.
Wow...I've gone on too long lads....remember, 'a perfect map, is only an area_portal away'.

[SkiesOfBordom]

any chance of explaing how to place area portals?
all my maps are higly detailed. even one room is over 1000 sometimes.

[grieve[Q2C]]

there are some tutorials about that on gamedesing.net

www.gamedesign.net/node/24#func_areaportal

www.gamedesign.net/node/42