Timestamps are in GMT/BST.
| 04:40:02 | | koda has joined |
| 05:15:34 | | sheepluva Quit (Ping timeout: 260 seconds) |
| 05:17:21 | | sheepluva has joined |
| 05:26:50 | | Nothing_Much has joined |
| 08:33:58 | | Nothing_Much Quit (Remote host closed the connection) |
| 12:42:26 | | watusimoto has joined |
| 12:42:26 | | ChanServ sets mode +o |
| 13:06:44 | | Nothing_Much has joined |
| 13:31:15 | | koda Quit (Quit: koda) |
| 14:46:44 | | Nothing_Much Quit (Quit: Leaving) |
| 14:58:52 | | koda has joined |
| 15:04:09 | | koda Quit (Ping timeout: 244 seconds) |
| 15:04:34 | | koda has joined |
| 15:10:57 | | kodabb has joined |
| 15:11:28 | | koda Quit (Ping timeout: 252 seconds) |
| 15:11:29 | | kodabb is now known as koda |
| 15:16:05 | | koda Quit (Ping timeout: 250 seconds) |
| 15:17:03 | | koda has joined |
| 15:24:08 | | koda Quit (Ping timeout: 246 seconds) |
| 16:46:24 | | raptor has joined |
| 16:46:25 | | ChanServ sets mode +o |
| 16:47:23 | raptor | good day! |
| 16:55:59 | watusimoto | hey there |
| 16:56:17 | raptor | hi |
| 16:56:49 | watusimoto | I hadn't considered sound as the cause |
| 16:56:54 | watusimoto | I was thinking logo rendering |
| 16:57:01 | watusimoto | but that didn't really make sense |
| 16:57:22 | raptor | yeah, the callgrind graph is really odd... |
| 16:59:48 | raptor | see here: https://i.imgur.com/A0PgocI.png |
| 17:00:24 | raptor | res1_inverse() is also part of libvorbis |
| 17:23:30 | watusimoto | The mysterious 1ca25 call... |
| 17:23:47 | watusimoto | but really, it looks like lots of stuff |
| 17:24:05 | raptor | i suspect that is opengl |
| 17:24:47 | watusimoto | that would make sense. |
| 17:24:52 | watusimoto | logo rendering is expensive |
| 17:24:59 | watusimoto | as is all the roman text |
| 17:25:50 | raptor | yeah - i read up on something called VBOs or vertex buffer objects that could be used to make them cheap |
| 17:26:05 | watusimoto | what are those? |
| 17:26:14 | watusimoto | render to a buffer, then memcpy that? |
| 17:26:18 | raptor | you basically use opengl to upload the vertex data to the graphics card, which caches it |
| 17:26:25 | watusimoto | I see |
| 17:26:41 | raptor | doesn't help with software opengl, of course, but i suspect few people use that nowadays |
| 17:27:03 | raptor | it basically offloads from CPU to the GPU |
| 17:27:06 | watusimoto | on the other hand, is it really a problem that we need to solve... unless we could do it systemically |
| 17:28:03 | watusimoto | I should take a look and make sure we're not rebuilding the vertex array every tick |
| 17:28:07 | raptor | i'm not so sure it is |
| 17:28:19 | raptor | we're not, at least not for the logo |
| 17:28:25 | watusimoto | I wrote that early on, before I really knew what I was doing... ok |
| 17:28:31 | watusimoto | obviously I knew what I was doing |
| 17:28:38 | watusimoto | in that case |
| 17:28:41 | raptor | i refactored it relatively recently with the GLES conversion (within a year or so) |
| 17:28:49 | raptor | it was all static const data |
| 17:28:54 | watusimoto | obviously you knew what you were doing then |
| 17:29:02 | raptor | then opengl was just used to tranlate/scale it |
| 17:29:09 | watusimoto | or at least someone stumbled onto the right decision at some point! |
| 17:29:47 | raptor | ok, he gave a new callgrind report... let me look |
| 17:29:49 | watusimoto | we probably render it with our "render this list of vertices" method, which is as fast as you can get |
| 17:32:01 | raptor | i really hate this graph, but: https://i.imgur.com/UF0Lx0p.png |
| 17:32:16 | raptor | looks like most of what is left is GLES related |
| 17:33:13 | raptor | i bet it's because GLES 1 is an abstraction layer to GLES 2 on the platform |
| 17:33:19 | raptor | if that is the case, there isn't much we can do |
| 17:36:48 | watusimoto | yes, a lot of gles in that horruible graph |
| 17:37:43 | watusimoto | the shame of it all is that most of what is happening is just redrawing the same thing over and over |
| 17:38:30 | raptor | that why i think VBO is a possible solution |
| 17:38:45 | watusimoto | how important is gles1 for us? |
| 17:38:57 | watusimoto | as in is it something we even need to worry about? |
| 17:39:01 | raptor | well, it's what we use |
| 17:39:12 | raptor | so we use OpenGL 1.x |
| 17:39:25 | raptor | I reduced it to a subset of that: GLES 1.x |
| 17:39:34 | watusimoto | I feel so stupid when you explain this :-) |
| 17:39:43 | raptor | all it does is make us more compatible with devices like this guys odroid (and RPi) |
| 17:40:06 | raptor | in the process of conversion we did can some performance |
| 17:40:19 | raptor | I started that abstraction layer for all GL calls a few months ago |
| 17:40:38 | raptor | so we could also rewrite all the methods as GLES 2 and open up even more devices |
| 17:40:47 | watusimoto | right yes, ok |
| 17:40:52 | raptor | GLES 1.x also let's us run on all android devices |
| 17:40:59 | raptor | and most iOS... |
| 17:41:14 | watusimoto | so we really need both gles1 and 2, hence the abstraction layer |
| 17:41:49 | raptor | but GLES 2 is already the past and present and certain things implement it directly in hardware |
| 17:42:06 | raptor | and then abstract it for GLES 1 compatibility... like the odroid |
| 17:42:44 | raptor | wait - maybe GLES 1.x is being dropped on devices now |
| 17:42:49 | raptor | only GLES 2+ |
| 17:52:45 | watusimoto | do you think we need to finish the abstration layer before trying the llvm javascript compilation? |
| 17:53:27 | raptor | oh yeah... i had forgotten |
| 17:53:36 | raptor | emscripten is GLES2-only now |
| 17:54:22 | raptor | this is because WebGL, the browser-based version of OpenGL is based on GLES 2 |
| 17:55:09 | watusimoto | Ok; I thought I had read somewhere that gles1 was now supported, mostly |
| 17:55:17 | raptor | where? |
| 17:55:23 | raptor | i mean, with what? emscripten? |
| 17:55:45 | watusimoto | oh, I don't know... it was months ago. yes, llvm/emscripten |
| 17:56:59 | watusimoto | http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html |
| 17:57:22 | watusimoto | http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html#opengl-support-legacy-and-mobile |
| 17:57:38 | raptor | oh ho! |
| 17:57:46 | watusimoto | I think that's what I saw |
| 17:57:51 | watusimoto | so partial support |
| 17:57:53 | raptor | well... maybe we can go further than I thought right now! |
| 17:58:06 | watusimoto | This mode adds significant emulation overhead. |
| 17:58:19 | watusimoto | but, just seeing if it works at all would be awesome |
| 17:59:08 | watusimoto | at some point in the near future, I want you to help me understand what actually needs to be done to get the gles2 support fully working, and I can start chipping away at it |
| 18:00:04 | raptor | well, the abstraction layer is already done in our code |
| 18:01:11 | raptor | now the equivalent GLES 2 calls need to be coded. This will include shaders and our own makeshift stack for some stack operations... unless we want to rewrite every drawing method everywhere have both GLES 1 and 2 |
| 18:03:27 | watusimoto | so by stack operasions you mean the gltranslate - glscale - gltranslate type sequences that need to be condensed into a single transform |
| 18:04:04 | raptor | yes, most especially: glPushMatrix() and glPopMatrix(); |
| 18:04:12 | watusimoto | for the shaders, I'd probably need to see one or two built out so I could better understand what needed to happen |
| 18:04:27 | watusimoto | ok, so one task is to get rid of glPush and glPop |
| 18:04:43 | raptor | or emulate them ourselves in GLES2 |
| 18:04:45 | watusimoto | that I can do |
| 18:05:08 | watusimoto | well, we'd just keep track of the operations and do the computations ourselves |
| 18:05:10 | raptor | i had decided on emulation because i think it would have been simpler and much less work than rewriting *everything* |
| 18:05:13 | watusimoto | it's not hard |
| 18:05:47 | watusimoto | I think all the glpush/glpop have already been transformed into bfpush/pop, so the work is pretty focused |
| 18:05:55 | watusimoto | if I recall correctly |
| 18:06:14 | raptor | all GL calls are already abstracted into the RenderManager class |
| 18:06:23 | watusimoto | yes, ok |
| 18:06:27 | raptor | so you only have to write the GLES2 methods in that class |
| 18:06:54 | raptor | this suggests writing our own stack is preferable, too: https://stackoverflow.com/questions/2918232/opengl-es-2-0-and-glpushmatrix-glpopmatrix |
| 18:07:10 | watusimoto | handling those operations is easy enough |
| 18:07:26 | watusimoto | I worked it out once, and concluded it was an evening's worth of work |
| 18:07:32 | raptor | ah ok |
| 18:07:40 | raptor | i haven't really done any research on that front, yet |
| 18:07:54 | raptor | i do know that glColor must be done by a fragment shader |
| 18:08:28 | watusimoto | it's the shader stuff that has me somewhat bewildered |
| 18:08:41 | watusimoto | I know we want/need to do it, but I really have no idea how |
| 18:13:39 | raptor | I have a diff of kaen's shader work somewhere |
| 18:14:04 | raptor | he got it to work, but i think his code was a lot more complex than it needed to be |
| 18:14:09 | watusimoto | I created a new issues tag for gles2 specific issues |
| 18:16:35 | raptor | ok... by 'eliminate', do you mean to implement it our abstraction layer, or remove all the calls everywhere? |
| 18:19:31 | | Darriel has joined |
| 18:19:34 | | Darrel Quit (Disconnected by services) |
| 18:19:38 | | Darriel is now known as Darrel |
| 18:27:36 | watusimoto | I mean redirect the calls to our on stack implemenation |
| 18:28:09 | watusimoto | and then create that implementation, of course |
| 18:28:22 | watusimoto | I know you have done some of this work already |
| 18:28:31 | watusimoto | I need to look and see how much |
| 18:28:53 | watusimoto | but that is a failry clear, discrete task that I watned to get into the system so I can work on it |
| 19:13:54 | raptor | the work I've done: *every* GL call in the bitfighter code is abstracted into the RenderManager class, ready to be implmeented in GLES 2 |
| 19:23:17 | watusimoto | ok, so the push/pop stuff should just be a matter of implementing a new stack so the calls to glpush/pop can be removed. I presume there are only a few left in the RM class |
| 19:32:48 | raptor | I made the RM have three classes: a parent GL class that has pure virtual functions; and two child classe, GLES1/GLES2 that implement them. The GLES1 class is what we use. To enable the GLES2 class, you have to compile with a flag: BF_USE_GLES2 |
| 19:54:47 | raptor | but i'm sure that compiling with that flag will basically break everything else in the game |
| 19:55:31 | raptor | of course, maybe we should just just have one class with the defines in each method... that may make it easier to debug |
| 20:01:25 | raptor | actually, watusimoto, maybe that is better - should I convert the RenderManager class to use the preprocessor defines within each method instead? That way it'll be easier to debug with a fully functional game |
| 21:11:12 | watusimoto | raptor: Yes, I think might be clearer, even though #ifdefs are generally frowned on. Then you can see the two codesets side-by-side |
| 21:15:54 | raptor | ok, will do now! |
| 21:18:07 | raptor | I think ifdefs should not be frowned upon |
| 21:33:53 | raptor | ok done! your next pull will have the changes |
| 21:36:58 | watusimoto | I love ifdefs! |
| 21:37:04 | watusimoto | out of here, see you later! |
| 21:37:24 | | watusimoto Quit (Read error: Connection reset by peer) |
| 21:45:11 | | raptor Quit () |
