Speed Ideas

[Dan East]

Randall, to my knowledge your comments regarding performance have been very accurate. <br><br>If you're referring to networking, then Pocket Quake will work with Quake running on any other platform, as long as it supports TCP/IP.<br><br>Quake's variables are case-sensitive (unlike commands). The current key mapping routines have several deficits, including the inability to enter lowercase letters. Thus it is not possible to set Quake vars via the console at this time. You can however set variables in the autoexec.cfg file:<br>fov "45"<br>This gives you a good close-up of the bad guys, but doesn't seem to help performance.<br><br>Dan East

[Dr. Phat]

So, taking out flames would take all the light out?  And I thought it was floating point math that killed FPS, not pixels.  Is it both?

[Moose or Chuck]

Taking out the flames would not take out the lights.<br>FPM will speed things up greatly, but blitting each pixel onto the screen does slow things down. There's no way around that though. And the screen is so small that there aren't many pixels on there anyway.<br>Last modification: Moose Master - 02/27/01 at 14:30:35

[Robotbeat]

Taking out flames at this disscussion board really improves communications among programmers to make PocketQuake faster! <br>BTW, 999, good job putting out flames before they get too big at this forum, unlike brighthand.

[randall]

The flames are nothing more than a decoration. Removing them will produce only an incremental increase in FPS.<br><br>I keep saying this- the real FPS killer is the number Polys. Pixels have nothing to do with it: there are a FIXED number of pixels that are drawn in every frame. The routines and algorithms that figure out the placments, distortion and visibility of each surface are what slow the engine down. The more polys, the more the routines are called, the more math involved, the slower the rendering.<br><br>THOSE routines should be looked at and optimised first and foremost. I believe Dan is working on that avenue.<br><br>I know for a fact that more polys are drawn than necessary. Polys that we cannot possibly see, but QVIS decided to include them "just in case".<br><br>note: QVIS is one of the three map compilers for Quake-based engines. It helps the engine determine which surfaces the player "sees".<br><br>On the tiny screen of a pocket PC, there are also polys that are  drawn that are less than 1 pixel. LESS THAN 1 PIXEL! Yes, that is a wasted routine call. What we see on the screen is only a tiny amount of what the engine actually draws. Try using "r_speeds 1" and you will see the number of polys and epolys the engine is drawing in real-time.<br><br>We know Polys work in this manner- walk up to a wall and watch the FPS skyrocket. Staring straight at a wall close-up generates an easy 15 FPS. Because it is drawing only a couple Polys. Back up and the FOV (field of view) increases the number of polys the player "sees", and the FPS drops to 2.1. <br><br>Yeah, this message was long a boring. Sorry 'bout that, but I keep seeing things on this board about "pixels", "light" and "sound"- all of which don't do diddly compared to the algorithm that manipulates the polys.<br><br>

[randall]

Ah, I didn't realize fov was a variable and case sensitive. I figured it was a command. Wow, I'll have to try a bunch of other "variables" now.<br><br>I just wanted to see what "fov 80" would produce.<br>

[Moose or Chuck]

That's why I'm telling Dan he needs to get those r_maxsurfs and r_maxedges working again, which he has informed us is complete. But since no one seems to be working on the Casio build, and since Dan's latest source isn't uploaded, even I can't compile it with these new settings.<br>I purchased a programming book today, maybe it will help me understand the language more so I can really contribute, but until then and until CARPEDIEM gets out of his dank depression, no one is really there to head up the MIPS department.

[randall]

Dan, I figured the two should connect regardless of platform. I think only version matching is required- which I wasn't sure was happening. I tried connecting to WinQuake 1.0 (1.09) through TCP/IP, and it won't acknowledge a server exists. I switched the PocketPC to act as server and it still didn't work. Both versions are using the same demo PAK file.<br><br>I have TCP/IP working- I can browse the internet through the USB connection. Maybe I'll mess with it a little more.

[Dan East]

I've played it between my PC and an iPaq using ethernet. If a version mismatch occurs Quake will advise you. By default TCP/IP connectivity is not established over a USB / Serial Activesync connection, so I'd say that is why you can't get it to work. There's a thread in this forum entitled "network with pc?", in which a link was posted with instructions on how to configure your PocketPC to establish TCP/IP over USB:<br>http://www.tekguru.demon.co.uk/EM500/usbtonet.htm <br><br>Dan East

[randall]

yeah, I have used that method to connect to my desktop computer for quite some time. It supports synching as well as connectivity to the internet through a proxy.<br><br>I see if assigning a static IP to my PocketPC does anything.

[randall]

nope, assigning a static ip doesn't work. Ethernet may be the only way to connect to a Quake server. Has anyone tested this online?<br><br>For anyone who is trying to squeeze every last bit of performance out of PocketQuake, try the FOV settings. I assigned an alias in the autoexec(use all lowercase just to be safe):<br><br>alias fov90 "fov 90"<br>alias fov70 "fov 70"<br><br>Typing fov70 at the console will change this variable (or fov90 to revert back to default). Here is what happens on my E-125 @ 150mHz-<br><br>timedemo- 0.5 fps increase<br>fov 90: 3.7 fps<br>fov 70: 4.2 fps<br><br>timerefresh- 0.47 fps increase<br>fov 90: 1.78 fps<br>fov 70: 2.25 fps<br><br>Since this variable only narrows the field of view (FOV) there is no loss in detail, lighting or effects. The only noticeable difference is that less of the players weapoon is drawn- but it is still visible.<br><br>Reducing the FOV beyond 70 may be intolerable, since it is essentially "zooming" in. This doesn't affect the "screen size" whatsoever.<br><br>A minimal increment, but an increment none-the-less.      <br><br><br>

[killzat - mark]

This is what I loose, I find it gains me 1FPS in totality and yet no real quality is lost. You may think one or two of these commands are aren't needed, but for some reason they do work so don't argue and just use it:<br><br>echo "999.cfg"<br>echo "pocketmatrix.com/pocketquake"<br>r_waterwarp "0"<br>crosshair "1" <br>viewsize "100.000000"<br>sensitivity "6.000000"<br>fov "70"<br>cl_bob "0"<br>cl_bobup "0"<br>d_mipcap "0"<br>d_mipscale "0"<br>loadas8bit "1"<br>r_drawviewmodel "1"<br>r_maxedges "1000"<br>r_maxsurfs "500"<br>vid_nopageflip "1"<br>vid_mode "1"<br><br>(Last one not enabled in current build).<br><br>If you're planning on using Landscape more then the mipcap/scale should = 1, doesn't loose much quality but you do see more of an improvement in landscape with it. Hope this helps some of you, I tested each setting and this is the best I could find.

[killzat - mark]

Oh yes and in landscape you should set a viewsize of 80 or 70, I find that's perfect for it, makes it nice and playable with the above changes. I love my iPAQ =) and I also love Dan, but not in that way hehe.<br><br>One thing I noticed was that the stylus m-look tends to center itself every now and then, usually when firing. <br><br>Would it also be possible to swap the attack button with the Jump one. This makes it easy to use in landscape with a 80/70 viewsize and also stops your finger conflicting with other buttons. <br><br>I normally have to use the D-Pad 'center' button to fire (diffecult to hold and fire like that) because the V-Pad seems designed for mini-hands =).

[999]

LOL!<br><br>Mark, as if by irony, we both have the nearly the exact same autoexec.cfg file <br><br>I've got a little more extreme settings when it comes to texture degradation, in the hopes of a .2 fps increase to add to the plate.<br><br>

[randall]

If anyone is interested in what Marks configuration does (* denotes commands that potentially increase/decrease FPS):<br><br>---------------<br>r_waterwarp - toggles wave effect (while underwater only) on/off<br><br>crosshair - toggles aiming crosshair on/off<br><br>*viewsize - size of the visible window<br><br>sensitivity - sets mouse sensitivity (mlook)<br><br>*fov - limits field of view by zooming in/out, 90 is default, 70 is comfortable.<br><br>*cl_bob - amount the weapon bobs up and down. 0.0 to 1.0 (0.2 is default)<br><br>*cl_bobup - amount player bobs up and down. 0.0 to 1.0 (0.5 is default). "1.0" is no bobbing.<br> <br>*d_mipcap - forces use of non-detailed mip textures. degrades visual quality. 1=on 0=off<br><br>*d_mipscale - detail level of mip textures. 0 to 4 (1 is default) setting to 4 degrades visual quality significantly on MIPS.<br><br>loadas8bit - toggles 8bit sound on/off.<br><br>*r_drawviewmodel - toggles the drawing of the player weapon on/off <br><br>*r_maxedges - sets the maximum number of edges to draw.<br><br>*r_maxsurfs - sets the maximum number of brush polys to draw.<br><br>vid_nopageflip - disable VESA page flipping<br><br>vid_mode - sets display to use a specified mode. PocketQuake currently supports two modes, portrait (default) and landscape. landscape does not work on MIPS.<br><br>----------------<br>I haven't verified if all these commands actually "do" anything. I can't imagine vid_pageflip works, since PocketPCs don't use VESA for video operations.<br><br>Careful with maxsurfs and maxedges- setting these too low will result it entire walls and textures not being drawn.<br>