| 01:24.46 | *** join/#bzflag sam (foobar@poulet.zoy.org) |
| 12:24.12 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:04.46 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 19:35.51 | macsforme | tupone: reference https://github.com/BZFlag-Dev/bzflag/pull/232#issuecomment-570888308, what about the case where a VBO is uploaded once and used repeatedly? specifically, how is the VBO bound for drawing on subsequent draw calls? |
| 20:37.54 | tupone | macsforme: I will write a case for that in the comment |
| 20:46.34 | BZNotify | bzflag: 03atupone commented on pull request #232 "Vertex buffers object handling" (06https://git.io/Jeh3u): > I simply fail to see why this method of VBO memory management is ... |
| 20:52.15 | tupone | the glTranslatef(0, 0, base) and the push/pop matrix could be removed if we use a callback on BZDBCache::flagPoleSize |
| 21:02.35 | blast007 | what if we just remove flagPoleSize as a configurable option? :) |
| 21:03.41 | blast007 | I'm of the opinion that we went a bit crazy with the level of customization via BZDB. |
| 21:04.39 | tupone | Yeah, we could do it :) |
| 21:11.06 | BZNotify | bzflag: 03atupone commented on pull request #232 "Vertex buffers object handling" (06https://git.io/Jeh3u): > I simply fail to see why this method of VBO memory management is ... |
| 21:56.50 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:54.32 | *** join/#bzflag SpazzyMcGee (~textual@2.29.201.21) |
| 23:59.21 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 23:59.22 | *** mode/#bzflag [+v spldart] by ChanServ |