Timestamps are in GMT/BST.
| 00:00:20 | | Flynnn has joined |
| 00:17:35 | | Invisible has joined |
| 00:17:59 | | Invisible is now known as Guest51464 |
| 00:44:56 | | Watusimoto has joined |
| 01:02:16 | | Guest51464 Quit (Ping timeout: 264 seconds) |
| 03:03:07 | | Watusimoto Quit (Ping timeout: 256 seconds) |
| 03:10:56 | | YoshiSmb has joined |
| 03:10:58 | YoshiSmb | evening! |
| 05:29:08 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 05:32:42 | | Flynnn has joined |
| 05:36:35 | | YoshiSmb Quit (Ping timeout: 246 seconds) |
| 09:13:56 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 10:18:07 | | Watusimoto has joined |
| 10:35:12 | | raptor has joined |
| 10:35:12 | | ChanServ sets mode +o |
| 10:36:04 | | raptor Quit (Client Quit) |
| 12:09:20 | | Watusimoto Quit (Ping timeout: 244 seconds) |
| 12:14:59 | | Watusimoto has joined |
| 12:17:33 | | Invisible has joined |
| 12:17:57 | | Invisible is now known as Guest73846 |
| 13:04:20 | | Watusimoto Quit (Ping timeout: 255 seconds) |
| 14:23:24 | | Watusimoto has joined |
| 15:11:41 | | Guest73846 Quit (Ping timeout: 255 seconds) |
| 16:41:03 | | Watusimoto Quit (Ping timeout: 246 seconds) |
| 16:58:32 | | Watusimoto has joined |
| 17:12:25 | | fordcars has joined |
| 17:34:11 | | Darrel Quit (Read error: Connection reset by peer) |
| 17:34:30 | | Darrel has joined |
| 18:27:20 | | Flynnn has joined |
| 18:33:26 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 18:47:39 | | Watusimoto has joined |
| 19:10:00 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 19:12:26 | | fordcars Quit (Ping timeout: 246 seconds) |
| 19:44:38 | | raptor has joined |
| 19:44:38 | | ChanServ sets mode +o |
| 19:44:43 | raptor | good day |
| 19:46:42 | raptor | Watusimoto: how did you get that feedback about clip2tri? |
| 19:46:55 | raptor | i'm surprised it didn't come to me... |
| 19:48:17 | | Flynnn has joined |
| 19:50:15 | raptor | also, i have a question regarding this rendering refactor - |
| 19:50:43 | raptor | I'm attempting to avoid including the OpenGL headers in any class except for the new RenderManager class. |
| 19:51:21 | raptor | The consequence is that calls that use GL defines in other classes don't work; like: mGL->renderVertexArray(vertices, 3, GL_LINE_STRIP); |
| 19:51:32 | raptor | the GL_LINE_STRIP is then undefined |
| 19:52:46 | raptor | the reason for fully abstracting is so that we can always catch rendering API issues |
| 19:53:18 | raptor | so i'm considering even abstracting the GL_LINE_STRIP/GL_LINE_LOOP, etc., values, as well |
| 19:53:36 | Watusimoto | howdy |
| 19:53:37 | raptor | but... is this too crazy? Am I going overboard? Is there a better solution? |
| 19:54:00 | Watusimoto | i was just sitting down to do my taxes! |
| 19:54:03 | Watusimoto | hooray! |
| 19:54:20 | Watusimoto | the clip2tri came to devs@bf.org, which I think directs to me |
| 19:54:39 | raptor | TAXES! |
| 19:54:48 | Watusimoto | it's the most fun you can have in late march |
| 19:55:07 | raptor | haha |
| 19:55:27 | Watusimoto | regarding your rendermgr class |
| 19:55:31 | Watusimoto | ... |
| 19:55:59 | Watusimoto | I'm not sure how you would meaningfuly abstract gl_line_x |
| 19:56:05 | raptor | yeah.. |
| 19:56:13 | Watusimoto | but you could create our own version that calls gl_line_x |
| 19:56:20 | Watusimoto | like render_line_strip |
| 19:56:24 | Watusimoto | or something |
| 19:56:24 | raptor | not without unneeded complexity... |
| 19:56:36 | Watusimoto | and just make that a passthrough that is implemented in rendermanager |
| 19:56:47 | Watusimoto | and if we need to make it fancier later, we can |
| 19:56:58 | Watusimoto | but for the moment, that seems to achieve your goal with a minimum of work |
| 19:57:10 | raptor | hmmm... maybe an enum {} with values that exactly match the GL values? |
| 19:57:35 | Watusimoto | oh, for the constants? yes, i think that would make sense |
| 19:57:53 | raptor | with GLES2 we get to reimplement the matrix stack! |
| 19:58:01 | Watusimoto | yeah, I known |
| 19:58:03 | Watusimoto | know |
| 19:58:09 | Watusimoto | it won't be too bad though |
| 19:58:49 | raptor | I have one last major refactor - that is to catch all the other gl* calls into RenderManager |
| 19:59:18 | raptor | and i'm sure i thoroughly broke tests/dedicated build |
| 19:59:23 | raptor | but the client compiles! |
| 19:59:38 | Watusimoto | ok; I have done nothing on bf since I left; I may do a little tonight, but nothing that will interfere with your work |
| 20:00:02 | Watusimoto | the tests might be ok... very few have anything to do with rendering |
| 20:00:39 | raptor | well... i touched a *lot* of classes |
| 20:01:34 | raptor | also, abstracting fontstash and oglconsole will be a challenge - i'm not too familiar with texture-based GL code |
| 20:01:42 | raptor | i may just leave those be for now |
| 20:03:43 | Watusimoto | well, definitely don't touch oglconsole |
| 20:04:15 | raptor | the original author of fontstash rewrote it to allow for graphics abstractions: https://github.com/memononen/fontstash |
| 20:04:34 | raptor | ^^ that's not the version we use, we use this: https://github.com/akrinke/Font-Stash/ |
| 20:04:59 | raptor | ours was originally more popular than the original because of the extra features, like multiple stashes, etc. |
| 20:06:14 | Watusimoto | is a "stash" a single font/size combo? |
| 20:06:41 | raptor | i think so, yes |
| 20:09:19 | raptor | but a new size it generated when going fullscreen or resizing the window |
| 20:09:44 | raptor | actually, now i'm not sure - it may try to stash the new stuff into the same stash object |
| 20:09:51 | raptor | until it fills up |
| 20:13:48 | Watusimoto | yeah, that sounds like it imight be right |
| 20:18:06 | Watusimoto | but if that's the case, what's the attraction of mulitple stashes? |
| 20:19:13 | raptor | a single stash must fit within the max texture size of the graphics card |
| 20:22:08 | | Invisible has joined |
| 20:22:32 | | Invisible is now known as Guest62476 |
| 20:34:03 | raptor | so, since we have more than 1 font, at potentially many sizes, i'd expect to fill the stash up... but maybe not? |
| 20:37:55 | Watusimoto | I see... so you can't just make it bigger; you need to create a new one... and switch them in and out as needed? |
| 20:38:19 | Watusimoto | I think for our needs, one is probably enough as we don't go too crazy with fonts |
| 20:38:21 | raptor | yes, texture size is requested from graphics layer before anything is added to it |
| 20:39:57 | raptor | looks like we use a 512x512 stash |
| 20:40:17 | raptor | which i think will end up being too small for everyletter of the 2+ fonts, and possibly different sizes |
| 20:47:02 | raptor | so we can do a 1024x1024 - but i'm not sure what generation of graphics cards woudl support that... |
| 21:03:19 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 21:09:56 | | Flynnn has joined |
| 21:58:18 | | Guest62476 Quit (Ping timeout: 256 seconds) |
| 22:03:39 | | Watusimoto Quit (Ping timeout: 265 seconds) |
| 22:22:38 | | raptor Quit () |
| 22:32:31 | | fordcars has joined |
| 22:59:25 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 23:05:15 | | Watusimoto has joined |
| 23:06:21 | | Invisible has joined |
| 23:06:45 | | Invisible is now known as Guest6461 |
| 23:31:05 | | Guest6461 Quit (Ping timeout: 256 seconds) |