| 00:17.36 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ayrzqtxnckggwsqd) | 
| 00:17.36 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02https://git.io/vxo5L | 
| 00:17.36 | BZnotify | 13bzflag/062.4 14899992b 15Vladimir Jimenez: Update ChangeLog with changes since 2.4.12 | 
| 00:17.36 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ayrzqtxnckggwsqd) | 
| 01:36.14 | macsforme | what kind of system/OS/GPU was the 4% increase demonstrated on? | 
| 01:38.17 | macsforme | I wonder if it also depends on what is being displayed, e.g. lots of flags | 
| 01:39.10 | blast007 | I was using my Decks server, in observer, with /roampos 0 | 
| 01:39.49 | blast007 | only place I saw a performance increase (thus far) was Intel HD 2500 on Linux | 
| 01:40.14 | blast007 | need to hook up my system with a radeon tomorrow | 
| 01:40.26 | blast007 | I should try my laptop too | 
| 05:57.27 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) | 
| 07:17.25 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) | 
| 07:33.23 | tupone | i did measuring time not frame rate. and from 17 msec went to 16. but i am not so sure | 
| 07:34.50 | *** join/#bzflag gustavo (uid290782@gateway/web/irccloud.com/x-iyuisxuyzklwuxdm) | 
| 09:58.42 | blast007 | no performance difference (on Decks) with a Intel GMA 4500MHD on Debian (both were getting 85FPS) | 
| 10:00.01 | *** join/#bzflag catay (~smertens@valyria.catay.be) | 
| 10:30.24 | tupone | however both client array and list are deprecated on latest openGL. i would like to go in that direction. maybe i will remove my jitter | 
| 10:31.40 | blast007 | "latest" being what?  talking about 4.6? | 
| 10:33.18 | blast007 | do you have vsync turned on by chance?  16-17ms is about 60FPS | 
| 10:35.48 | blast007 | lowest FPS I can hit at 1920x1200 resolution (with Intel HD 2500) is 70 FPS, and that's on a mesh-heavy map (Rats Nest) | 
| 10:50.33 | tupone | vsync turned on | 
| 10:54.10 | tupone | latest is i think any where fixed pipeline is removed. non in compatibility mode | 
| 10:54.46 | blast007 | so turn vsync off... otherwise you're just going to be limited to 60FPS | 
| 10:55.33 | tupone | i knew that y and t measure two different things. | 
| 10:55.48 | tupone | i need to check | 
| 10:58.17 | blast007 | 1000ms / framerate = average frametime  vs  1000ms / average frametime = framerate | 
| 11:42.51 | tupone | ok. then i need to change that here. i wanted to know the cpu time to elaborate a scene | 
| 12:42.05 | macsforme | that method of benchmarking seems very specific to your own GPU and driver | 
| 12:44.58 | blast007 | macsforme: I wouldn't even call it a benchmark since he had vsync enabled and was hitting the limit before and after the changes | 
| 12:47.11 | macsforme | does the frame time include the buffer swap and vsync delay? | 
| 12:48.09 | macsforme | I get a 1-2ms frame time with vsync enabled on the quick test I just did | 
| 12:48.38 | blast007 | I get 16-17ms with vsync enabled on linux | 
| 12:49.21 | blast007 | 4-5ms with vsync off (and around 160FPS) | 
| 12:51.17 | macsforme | huh, so maybe another implementation-specific issue (so yes, you're right, not really a benchmark at all) | 
| 13:35.45 | blast007 | with an AMD card on linux, with vsync on (still trying to figure out how to disable) it does show 4-5ms even though it's running at 60FPS | 
| 13:37.52 | blast007 | or maybe it's 3-4ms | 
| 13:38.13 | blast007 | and oddly, I can get the FPS to drop to 47, but it's still showing a 3-4ms frame draw time | 
| 13:55.16 | blast007 | okay, managed to disable vsync on that system.. FPS drops from 75 with the old code to 67 with the new code (though both are saying 5ms frame draw time.. so I don't know how that works) | 
| 13:56.49 | blast007 | so everywhere except Linux+Intel, I'm seeing a 5 to 10% performance hit with the new GL1.5 code. | 
| 14:03.50 | blast007 | (and I don't have a Windows+Intel system to test with) | 
| 14:08.04 | macsforme | odd... I wonder what is contributing to the slowdown | 
| 15:02.29 | blast007 | got a few hundred packages to update on my Debian+nVidia system, and then I'll test there too | 
| 15:15.55 | blast007 | oh, I guess it was over 1600 packages... | 
| 16:57.30 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-fyssxxtduoqyfqhu) | 
| 17:30.11 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) | 
| 17:50.37 | tupone | the change is dropping list and using vbo. so it seems that compiling list is better then using vbo | 
| 17:51.48 | tupone | but is not the path to go opengl 3 or gles | 
| 17:51.54 | macsforme | or possibly switching between the two methods is more expensive than using one or the other exclusively | 
| 17:55.24 | tupone | the flag code and the mesh code is different. flag did not use by default list. but vbo are created and deleted each frame. | 
| 17:58.03 | tupone | maybe measuring only one of the two can give hints. | 
| 17:58.53 | tupone | i cannot do now cause i am away from home | 
| 18:18.41 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) | 
| 18:18.58 | macsforme | if it's re-creating the VBOs every frame then I don't think the GL_STATIC_DRAW usage hint is correct... should probably be GL_STREAM_DRAW | 
| 18:20.40 | macsforme | you're also using the GL_STATIC_READ usage hint for the MeshFragSceneNode... that doesn't seem correct to me either | 
| 18:22.19 | macsforme | so perhaps with better usage hints there would be improved performance | 
| 18:34.35 | blast007 | hmm, can't seem to get my nVidia driver to be stable on Debian.  Super flaky just in Gnome, and when I try to run the game it just crashes Xorg back to the login screen. | 
| 18:47.36 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) | 
| 19:52.28 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) | 
| 22:57.02 | macsforme | I tried changing the two buffer hints to GL_STREAM_DRAW and that didn't reduce the mild performance reduction on my machine | 
| 23:45.58 | *** join/#bzflag Notify (~notify@104.225.5.10) |