Thanks for the feedback. I welcome the comments as this is my first ever map release. I will make some changes and repost. I have more, but they are similar and the feedback will help them as well. Thanks again.

Still haven't fixed the water (yet). Figured the lighting was a bigger deal. Let me know if it is better or worse please.

better?

So I will just optimise the cover (background geometry) so that it uses less triangles and maybe replace the glass with something passable at a distance. Better safe than sorry.

I get anywhere from 70-110 (not the quickest system with 9800gt 1gb card and 3gb of system ram running on linux) depending on how many cubes are visible. 30 is passable for fluid movement, 60 is a good cap to be safe, and 70 is plenty as long as nothing is jerky, but the question is does the frame-rate effect player movement speed?

I Wonder if Sauer has the same problem as Quake2 with regard to framerate and gameplay. Someone with a faster frame-rate would actually appear to move through the world at a quicker speed when viewed from the slower pc (lower framerate) and as a result the player with the higher frame-rate could skip across the map in what seemed like a couple of hops and shoot you in the face before you could get a shot off. Modern games fix this partially by capping the frame-rate which goes along way toward fixing the problem. If it is not capped in Sauer this could be a problem I think, depending on how the network code is written.

If I recall correctly, gamespeed in quake was relative to your clockrate. At startup, it would check, and go by what it saw. When I run quake 2, at startup my CPU clock will be at 802Mhz, and once the game is running my CPU will dynamically clock itself ( to 3.7Ghz ) and the game runes crazily fast.

I do not think Sauerbraten has any issues like that. Gameplay online is no different if I have 1000 FPS or 200.

for those with shity computers it does ^.^

Yep and I believe frame-rate is directly linked to clock speed unless there is a sleep or something to halt the game loop after all processing is done and wait for the correct time to start the next loop iteration (lots of ways to do this but they all boil down to the same basic concept which is scale loop iterations to real time).

simplistic pseudo code example:

begin game loop {
Render
Process Input
Execute Logic (Physics, network, scripting, etc...)
Wait (amount based on elapsed real world time)
} loop

I forgot to state the actual point of my ramblings...

The real point here is that in Q2 and games designed similarly, without this wait function, can cause slower computers, which have to spend more time rendering really complex levels, to actually iterate through less loops over the same amount of real world time as compared to a faster computer... hence the faster computer processes more game loops in the same amount of time and the faster computer allows its player to do more in the same amount of real world time.

Anyway it is not common knowledge but a complex level could exacerbate this issue if it exists which is why I asked.

but if

begin game loop {
Render
Process Input
Execute Logic (Physics, network, scripting, etc...)
Wait (amount based on elapsed real world time) // this comes late then frame rate suffers
} loop

basically everything above .... TROLL

chasester

The wait time is variable and has to scale based on how much time it takes to complete all of the processing in one iteration of the loop. You cannot know that if you do it before the end. If you do it first you may wait too long... only after all the processing is done can you calculate the wait time left to make up the difference so that you don't hurt the frame rate.

The wait time is scaled based on the number of clock cycles per second... calculate how many clock cycles have passed after you complete all the steps in the game loop and you know roughly how many to wait to make up the difference so that you can make the game loop execute in a a set number of seconds. Set the threshold at a manageable number like 80 and your going to be at a constant speed until you go above the 12.5 milliseconds per game loop it takes, at least, to render 80 fps and then you skip the wait part of the loop so as not to slow down the frame rate. At that point though you drop below the 80 frames per second because your game loop is back to running as fast as the computer will allow until your video card stops choking and you get below the 12.5 millisecond threshold again...

If the geometry is not that complicated and/or you have a super video card then you wont have this problem because the render time will never go above the threshold... until programmers figure out a way to overtax the new hardware and then you are back to square one and the whole thing starts over again... hence new video cards every so many years to keep up with ever increasing amounts of detailed rendering the games are pumping out...

example

pc a takes 12.5 ms to render a frame (80 fps)
pc b takes 10 ms to render a frame (100 fps)

without the wait time pc b allows the player to move roughly 1.25 times faster than the player on pc a.
add the wait time (capped at 80fps) and the movement speed is the same (given the slower computer does not get bogged down and can keep up the 80 fps... if not he is screwed and needs a faster computer). Not perfect but like I said goes a long way toward fixing the problem.

Don't worry, this works as it should since Cube1. Yes, how often a game update happens depends on how fast computing and rendering of each frame is. BUT everything in the game (like how far you move per frame, how often you can shoot etc.) also depends on the time spent on the last frame, neutralizing the effect.

So, let's say if you have an FPS of 30, you move 2 cubes per frame, and if you have an FPS of 120, you move 1/2 cube per frame (this is just an example).

Thanks for the info... Sorry to all as I was not trying to be pretentious.

Did you use an command in game to get triangle count or export to obj or something like that?

http://sauerbraten.org/docs/editref.html#the_hud

broken link???
Cube Server down???

chasester

Hmm... interesting... I do see "gl" in my hud which might be what I need, but I'm not sure... Definately no "tri" label though unless I am missing a setting somewhere.... I am running this thing on linux though...

Note:
I am using a downloaded version and not the one packaged for my linux distro... Think I downloaded justice edition but don't remember.

Pretty sure it's "wtr" ("world triangles", probably). Not sure what the percentages mean. Try the source if you're curious.

wtr is [worldtris]/1024 which I assume [worldtris] is the actual triangle count. This map shows 167k constant... the percentage fluctuates and probably has something to do with culling and what is in view is my guess but I don't know, or care at the moment.

According to that this map should have 171,008 triangles. I wrote out an obj model of the map and grep'd the lines containing "f " (which should get me triangles in this case) and got 171,208. Probably some error in the grep count but it is close enough.

So yep I think you are correct.

the wtr count does have a measure on the complexity though. You might make a 500K wtr map with simple geometry, and it will be lagless (pressumably). be that map small and complicated, it will lag greatly.

If you have any other nodes you want me to pass ownership back to you, let me know. The (not verified) bit on your old posts however will remain, but at least it will look like nothing ever happened. :P