| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has joined #bzflag | 01:00 | |
| *** James_ <James_!~Gravygoat@92.119.18.152> has quit IRC (Ping timeout: 256 seconds) | 01:02 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 02:47 | |
| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 03:46 | |
| *** Quol <Quol!~Quol@bras-base-mtrlpq5405w-grc-21-174-92-213-54.dsl.bell.ca> has joined #bzflag | 05:09 | |
| *** L4m3r_ is now known as L4m3r | 05:10 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 05:57 | |
| *** Quol <Quol!~Quol@bras-base-mtrlpq5405w-grc-21-174-92-213-54.dsl.bell.ca> has quit IRC (Quit: Client closed) | 06:18 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b9875e.dyn.optonline.net> has quit IRC (Read error: Connection reset by peer) | 10:10 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 11:13 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:01 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 13:58 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 14:00 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 17:26 | |
| *** Quol <Quol!~Quol@bras-base-mtrlpq5405w-grc-21-174-92-213-54.dsl.bell.ca> has joined #bzflag | 17:43 | |
| *** Quol <Quol!~Quol@bras-base-mtrlpq5405w-grc-21-174-92-213-54.dsl.bell.ca> has quit IRC (Quit: Leaving) | 17:46 | |
| *** Quol <Quol!~Quol@bras-base-mtrlpq5405w-grc-21-174-92-213-54.dsl.bell.ca> has joined #bzflag | 17:47 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 18:48 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 19:32 | |
| *** dngor <dngor!abuse@104-136-128-018.biz.spectrum.com> has quit IRC (Quit: zort) | 20:06 | |
| macsforme | I'm somewhat more comfortable with the state of our master branch after reviewing blast007's categorization of commits | 22:03 |
|---|---|---|
| *** blast007[m] <blast007[m]!~blast007m@2001:470:69fc:105::7ec> has joined #bzflag | 22:03 | |
| *** bittin[m] <bittin[m]!~bittin-gu@2001:470:69fc:105::603> has joined #bzflag | 22:03 | |
| macsforme | I believe my existing concerns about unfinished projects related primarily to JeffM's shot manager/tracking project as well as his server-side player project | 22:04 |
| macsforme | it's not clear to me whether the new normal and specular map features actually do anything as far as rendering... I don't see any actual rendering calls, and I thought previously that you need per-pixel lighting (shaders) to do that, unless there's a GL extension | 22:07 |
| macsforme | the wavefront/.obj rendering support does appear to have at least some rendering support... it's not clear to me to what extent that is implemented (e.g., wavefront materials, etc.), and I'm not sure what we would use that for unless we expand our map file format (or we use it internally to draw non-map objects like trees, rocks, etc.) | 22:11 |
| macsforme | or perhaps it was intended to be used for drawing tanks down the road (at least the non-animated portions) | 22:19 |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 22:24 | |
| macsforme | as far as the Apple M1 issue (low framerate while driving inside a meshbox with OO), I just noticed these lines on the console as soon as the issue occurs: https://pastebin.com/EnYxKBxT | 22:57 |
| macsforme | the "SW" in "SW fragment processing" appears to refer to software rendering, which would explain the very low framerate | 22:58 |
| blast007 | ah | 23:00 |
| blast007 | that's a very useful output | 23:00 |
| blast007 | try commenting out the two glPolygonMode calls in EighthDimShellNode::ShellRenderNode::render() | 23:08 |
| blast007 | "In OpenGL 3.0 or above, core profile, only the combined front and back face enumerant is valid, offering a single mode enumerant GL_FRONT or GL_BACK results in an INVALID_OPERATION. Therefore the only valid call is glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);" http://www.krugerheavyindustries.com/pebble/2018/06/09/1528516320000.html | 23:09 |
| macsforme | after commenting out those two lines, it renders at full speed, although it draws textured/translucent faces instead of the lines like before | 23:11 |
| macsforme | if I change the first argument of the first call to GL_FRONT_AND_BACK, it also renders at full speed, no error message, and I don't see any visual difference | 23:25 |
| blast007 | oh, I hadn't noticed that one was GL_LINE and one was GL_FILL | 23:27 |
| macsforme | thinking through the logic, I don't see any harm in front faces being excluded... there shouldn't even be a difference unless it's a concave object where you could see an outside from the inside (meshes, maybe?)... I think the important thing is to enable the back faces | 23:37 |
| macsforme | front faces being s/excluded/included/ | 23:37 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!