Speed Ideas

[Moose or Chuck]

Here's what each command gave (with it's setting and description). I will also give a base for comparison. All of this was done on an E-125 @ 180MHz. These are also seperate scores, not combined gradually. Each setting was set alone. Tests performed on MIPS build 0.0041:<br>Base marks (E-125 @ 180MHz, all defaults except for binds):<br>2.587165<br><br>r_drawflat - "1" removes all textures from the map:<br>2.721473 ( +.134308 )<br><br>r_drawentities - "0" removes all entites, such as doors, enemies, torches, from the map:<br>5.606234 ( +3.019069 )<br><br>r_drawviewmodel - "0" removes the player's weapon from the screen:<br>2.626073 ( +.038908 )<br><br>r_maxsurfs and r_maxedges don't work. I decided not to post the benchmarks from these commands as they currently do nothing. These commands are NEEDED for PocketQuake, they would increase FPS GREATLY. Read below:<br><br>OHHH!! I know why r_maxsurfs and r_maxedges don't work. They are WinQuake commands! And WinQuake commands don't work. Dan East, can you go about fixing this? These to variables are MANDATORY for PocketQuake, as the defaults are way too large. If the edges go above 400 then the game is unplayable, and when surfaces jump above 200, you'll have a hard time. Please fix these commands in your next build.Last modification: Moose Master - 02/25/01 at 17:32:38

[Moose or Chuck]

Fuchal, that's basically what r_maxsurfs and r_maxedges does. But they currently don't work. If you want to run PocketQuake at a continual 10-15FPS you should set these to 100 and 300 or lower. Read my above message if you haven't already. Dan needs to put these commands in, as they are for WinQuake and don't work in this version of PocketQuake.

[Fuchal]

Ah, cool.<br><br>Yes, those are mandatory.

[Dan East]

Okay, Quake has hardcoded minimum edges of 2400 and surfaces of 800, so you can't set below that. I modified it for far lower minimums so your var settings will work. Decreasing edges to 600 and surfaces to 100 increased fps by 13% using the new benchmark technique, and by 20% using the old TIMEREFRESH technique. The latter benchmark benefited more because of the size of the starting room, thus a great deal of surfaces are not rendered. Personally I wouldn't decrease those values any further or else too many walls will be lost. Quake does seem to be smart enough to render the closer, more important surfaces while dropping the distant ones, so this improvement is useful. I definitely prefer these types of mods as they can be adjusted by the user. I can't help you with the MIPS version; Carpediem will have to make the following mod to his already modified sources and rebuild:<br><br>r_shared.h:<br>change:<br>#define NUMSTACKEDGES            2400<br>#define      MINEDGES                  NUMSTACKEDGES<br>#define NUMSTACKSURFACES      800<br>#define MINSURFACES                  NUMSTACKSURFACES<br>#define      MAXSPANS                  3000<br><br>to:<br>#define NUMSTACKEDGES            2400<br>#define      MINEDGES                  25<br>#define NUMSTACKSURFACES      800<br>#define MINSURFACES                  100<br>#define      MAXSPANS                  3000<br><br>I leave the NUMSTACKEDGES and NUMSTACKSURFACES macros alone so when the surfaces and edges values are default they are still allocated off the stack.<br><br>Dan East

[Sparky009]

hmm... what about killing the dyn lighting loops for explosions and lava balls, etc... we definitely don't need those... and for torches etc, would it be possible to set a constant based upon an average of the varying light degrees? Anything to knock out those loops if possible. Particle effects, too... possible to disable those?

[randall]

Lighting effects are always important; if I want crappy lighting I can always play PocketDoom. If it comes down to this, I would prefer to have a toggle to modify these speed enhancers. That way, each user can decide just how low (or high) an FPS they can tolerate.<br><br>

[randall]

Oh yeah, and if I recall correctly, those lighting effects are compiled with the map and are not generated dynamically (spontaneous/on-the-fly). This includes torch light, flickering lights, glowing lava, etc. So they shouldn't affect the FPS much. Fire balls may fall into this category, since they are not dynamically generated.<br><br>Dynamic lighting, such as that from a players rocket launcher is different. It can't be pre-rendered.

[Phantom]

Dudes,<br><br>Some notes:<br>- Quake DOES use 'HSR' (wich stands for hidden surface removal); Quake is using a 'PVS' for that. That's a data set that complements the BSP tree (wich is used for free perfect sorting, by the way), the PVS indicates wich polygons are potentially visible from any given position in 3D space. This technique is, apart from extremely heavy precalculations, virtually 'free' at run-time.<br>- Scanline interleaving is a good idea, but at 4 fps, it might look VERY bad. The idea is to render odd lines only at odd frame numbers, and even lines only at even frame numbers. This will result in stripes, of course, but at decent frame rates, it can look very good. We will keep this in mind when we reach 10fps overall; this technique will almost double that to 18fps or so.<br><br>FYI, I have been focussing on the lowest drawing code (the span renderers), because Dan reported an extremely strong link between the number of pixels on screen and the speed of the game. We get pretty good frame rates now when looking at walls (wich means it was a good idea to start there:), but complex scenes are still way too slow. So I intend to focus on the edge buffer this time; that's a structure that is used to prevent 'overdraw'. It's mainly floating point, but I think it's doable to change that. <br><br>- Jacco.

[Moose or Chuck]

Sparky, carpediem already took out all the particles (or was it Jacco. Ya, it was Jacco).<br><br>Dan East: Do you have universally compileable code yet? Because I would love to make those changes myself. I heard that Carpediem did, but I don't like his most recent optimizations.<br><br>randall: all lighting effects are rendered during gameplay. It doesn't matter if someone put it an info_light entity somewhere in the map, it can still be turned off. The engine is what renders the lights, not the map itself. And if it were pre-rendered by the map there would be NO speed difference, only a difference in the size of the map itself, and then the quake engine would just be a 3D file viewer.

[Dr. Phat]

Is there a way to selectively choose what to take out.  It's not neccessary to have Flames on the torches.  Maybe just a fixed flame, not a 3D one, like a BMP or something.  Sure, from certain angles: unviewable, but from others it would be fine.  And the sky can definately go.  Maybe just make a ceiling?  Also, does easy level go faster because of the absolute lack of monsters?

[Moose or Chuck]

Mike. Yes, the easy level would go slightly faster, I guess. But no you cannot remove just flames. I think it would be a good idea if Dan could add an option two (2) to the "r_drawentities" console command that would put certain sprites in the places of flames, enemies, etc. But then it wouldn't be quake. Maybe just flames, and keep enemies the way they are.

[randall]

I'm not here to argue. But a misconception could turn this project the wrong way.<br><br>Light entities are compiled and pre-rendered with QRAD, one of the three main map compilers. This information determines the cast shadows, whether a light luminates a surface, and how light bounces about the room. Any map makers can verify that light can bounce throughout an entire map and seep through the tiniest of cracks.<br><br>Basically it is a light map to tell the engine HOW to render a light and the effects it has on the environment. Without it, the engine would be painfully slow- which is evidenced when a rocket is fired. Anyone who has been in a high poly rocket arena knows the game lags during a large firefight. Rocket lumination is dynamic, not pre-rendered with QRAD.<br><br>Sure the engine renders the light, but the grunt-work was done during compiling of the map. I may be wrong, and it certainly won't be the first time. But try using "r_fullbright 1", and tell me if you notice a significant difference (other than the utter ugliness). The trade-off is just not worth it to pick up an extra 0.1 fps.<br>

[randall]

Removing the skybox shouldn't affect FPS either. It isn't comprised of Polys and doesn't affect the poly count. Polycount (brushes and entities) is what really kills FPS.<br><br>On that note, a minor rise in FPS could be achieved through the field of view (FOV). I haven't been able to get the FOV console command to work ("FOV 90" is the default) but "zoom_in" is similar to "FOV 10". At this extremely narrow FOV the fps skyrocketed, but the game is impossible to play while looking through a telescopic lens. Something like "FOV 80" may be a little better.<br><br>Has FOV been disabled?<br><br>I tried messing with things like "d_mipscale 4" which reduces the quality of the mip textures. All it produced was a low grade texture and a 0.1 fps increase. Nothing to whoop and holler about.<br><br>Will we ever be able to play custom maps? Large rooms have always plagued games like Quake- maybe we are expecting too much from maps that were compiled for much faster processors. Some rooms are so large that the grunts I am firing at are no larger than 1 pixel. Close the gap, gain FPS AND you will be able to SEE the target.<br><br>I am assuming PocketQuake is based on the WinQuake (1.09) source. Are these two so different that they will never be compatible to play against each other?

[Moose or Chuck]

Randall, lol. I thought you were talking about a different thing, i think. But yes, QRAD and everything... <br>I believe I was thinking of things like the flying lava, but oh well.

[Sparky009]

the lava glow, yes, is prerendered, but I don't believe lava balls are...<br><br>I was thinking of torches flickering, but since those are heavily prerendered (I thought there still might be some artifacts left in the engine where it was calculating it), I guess that doesn't matter... still, turning off dynamic lighting should help a bit on speed, but yeah, I agree, it should be a toggle.