Timestamps are in GMT/BST.
| 00:19:40 | | Watusimoto has joined |
| 00:23:24 | | Guest43629 Quit (Ping timeout: 246 seconds) |
| 01:15:53 | | Nothing_Much has joined |
| 01:45:19 | | Flynnn has joined |
| 01:47:23 | | Flynnn Quit (Client Quit) |
| 02:30:29 | | koda has joined |
| 03:11:46 | | Watusimoto Quit (Ping timeout: 256 seconds) |
| 05:13:49 | | koda Quit (Quit: koda) |
| 05:28:30 | | koda has joined |
| 06:07:05 | | koda Quit (Quit: koda) |
| 06:07:25 | | koda has joined |
| 06:26:29 | | LordDVG has joined |
| 08:13:57 | | LordDVG Quit (Remote host closed the connection) |
| 11:36:31 | | raptor has joined |
| 11:36:32 | | raptor Quit (Changing host) |
| 11:36:32 | | raptor has joined |
| 11:36:32 | | ChanServ sets mode +o |
| 11:36:37 | raptor | good morning! |
| 11:41:01 | | kaen_mbp has joined |
| 11:42:50 | | kaen_mbp Quit (Remote host closed the connection) |
| 11:48:53 | | kaen_mbp has joined |
| 11:50:19 | | kaen_mbp Quit (Remote host closed the connection) |
| 12:23:28 | | kaen_mbp has joined |
| 12:24:51 | | kaen_mbp Quit (Remote host closed the connection) |
| 12:30:13 | | Invisible has joined |
| 12:30:38 | | Invisible is now known as Guest59531 |
| 12:57:28 | | watusimoto has joined |
| 12:57:28 | | ChanServ sets mode +o |
| 12:57:44 | watusimoto | hello! |
| 13:02:39 | raptor | hello |
| 13:03:31 | raptor | i was looking at the symbol sizes of our 'bitfighter' executable - |
| 13:04:00 | raptor | _Z41__static_initialization_and_destruction_0ii symbol is around 250K |
| 13:04:22 | raptor | next in line is _ZL19OGLCONSOLE_FontData at about 50K |
| 13:04:37 | raptor | most everything is under 1K |
| 13:05:31 | raptor | so i think moving all the stuff from RenderUtils and OpenglUtils into RenderManager will reduce that global static footprint |
| 13:07:44 | raptor | granted 250K of memory for statics probably isn't hurting us |
| 13:09:32 | raptor | oh, actually there are several chunks - looks liek static initialization amounts to: 472786 |
| 13:09:44 | raptor | we're RAM hogs! |
| 13:12:12 | raptor | also, i came across the c++ FQA: http://yosefk.com/c++fqa |
| 13:12:34 | raptor | it's funny... |
| 13:39:40 | watusimoto | I think we could use 10x the resources and no one would notice on their modern computers |
| 13:46:47 | watusimoto | the fqa guy is almost as opnionated as I am |
| 13:47:06 | raptor | there's a lot of good data there |
| 13:47:20 | watusimoto | yes |
| 13:47:24 | watusimoto | it's a good document |
| 13:47:53 | raptor | i was lost trying to figure out why calling a pure virtual method from a classes contructor wouldn't work and found the answer there |
| 13:48:10 | watusimoto | it doesn't work because it's c++ |
| 13:48:16 | raptor | exactly! |
| 13:48:25 | watusimoto | and we wouldn't want the pretty little compiler to get too tired |
| 13:48:48 | watusimoto | don't work too hard, compiler-snuggins! |
| 13:49:03 | watusimoto | (that was supposed to be a mother-to-infant voice) |
| 13:49:08 | raptor | i sometimes wonder what the hobbies of people who maintain c++ compilers are... |
| 13:49:35 | watusimoto | they're all ex-bitfighter devs :-) |
| 13:49:40 | raptor | haha |
| 13:50:13 | raptor | maybe writing the compiler *is* their hobby |
| 13:51:47 | watusimoto | for some, surely it is. |
| 13:51:50 | | kaen_mbp has joined |
| 13:52:17 | watusimoto | I wonder what we staticaly init that is so big |
| 13:52:24 | watusimoto | that's actually more than I would have guessed |
| 13:52:46 | raptor | well, there will be about 100 gameobject render methods |
| 13:52:57 | raptor | another 50 renderutil/openglutil methods |
| 13:53:10 | watusimoto | ah, the 472k is with all that? |
| 13:53:14 | raptor | i think... but maybe it's TNL stuff? |
| 13:53:25 | raptor | i doubt that would make up 472k... maybe 10% |
| 13:53:34 | raptor | maybe not even taht |
| 13:53:34 | watusimoto | there's lots of stuff like help files |
| 13:53:35 | | kaen_mbp Quit (Remote host closed the connection) |
| 13:55:12 | raptor | question - are you OK with me getting rid of duplicate methods that use S32 vs F32? |
| 13:55:22 | raptor | maybe using a template instead... |
| 13:55:36 | raptor | everything would be F32 |
| 13:55:39 | watusimoto | sure yes |
| 13:55:45 | raptor | ok |
| 13:56:05 | watusimoto | there's a lot of duplication added to avoid having to cast in code |
| 13:56:27 | watusimoto | much of it I've wanted to move to templates but haven't seen it as a priority |
| 13:56:32 | raptor | also - it seems 1/3 of our methods use: const Color *color, and 2/3 use: const Color &color |
| 13:56:40 | watusimoto | yes |
| 13:56:46 | raptor | can we... standardize? |
| 13:56:57 | watusimoto | some of it is because we want to pass a null color in some cases |
| 13:57:03 | raptor | ah ok |
| 13:57:07 | raptor | that's what i was wondering |
| 13:57:12 | watusimoto | in others it is performance (you know what they say about premature optimization) |
| 13:57:14 | raptor | if NULL was used somewhere |
| 13:57:34 | watusimoto | so we can get a color pointer from a method, and pass it to abother without creating a new color object |
| 13:57:42 | raptor | i thought performance was identical in the two, just one forces the compiler to verify NULL isn't an option |
| 13:57:55 | watusimoto | yes, is some render methods NULL is passed |
| 13:58:08 | watusimoto | but those could perhaps be broken down into different sigs |
| 13:58:25 | watusimoto | consider this: |
| 13:58:46 | watusimoto | Color color =getColor(); render(color); |
| 13:58:47 | watusimoto | vs |
| 13:58:59 | watusimoto | Color *color = getCOlor(); render(color); |
| 13:59:12 | watusimoto | the first will create a new color object, no? |
| 13:59:44 | raptor | hmmm.... i think it depends if getColor returns a &reference? |
| 13:59:52 | watusimoto | I have had all sorts of misery created by returning refs, but maybe if I can find a way to make that work happily, that would be an answer |
| 14:00:02 | raptor | the pointer is definitely copied in the second case |
| 14:00:12 | watusimoto | yes, but the pointer is just an int |
| 14:00:20 | raptor | which is cheaper than the entire object |
| 14:00:24 | watusimoto | yes |
| 14:00:37 | watusimoto | which is 4 floats and some metadata |
| 14:00:44 | watusimoto | so not much, really |
| 14:01:09 | watusimoto | or maybe only 3 floats |
| 14:01:21 | raptor | this looks like good advice: http://www.cplusplus.com/articles/z6vU7k9E/ |
| 14:01:32 | raptor | read teh 6 scenarios at the bottom under 'to summarize' |
| 14:01:41 | watusimoto | I would totally like to standardize and clean up the inconstencies |
| 14:02:19 | raptor | when would a NULL color matter? |
| 14:04:00 | watusimoto | summary: that is all my practice but misses the essential issue |
| 14:04:16 | watusimoto | which is what to return from a getColor() method |
| 14:04:28 | raptor | Color &getColor(); |
| 14:04:29 | watusimoto | if you have the color, I do exactly what they suggest |
| 14:04:49 | watusimoto | the otehr problem with refs is this: |
| 14:05:00 | watusimoto | Color c = getCOlor(); # Returns ref |
| 14:05:13 | watusimoto | and Color &c = getCOlor() |
| 14:05:18 | watusimoto | behave differenly |
| 14:05:25 | watusimoto | the compiler lets you do either without comment |
| 14:05:36 | watusimoto | but the first copies color, the second gets a ref |
| 14:06:08 | watusimoto | with pointers, the compiler chokes if you do it wrong |
| 14:06:55 | watusimoto | I have tried to start returning refs where possible; maybe I should try some more. |
| 14:07:16 | raptor | hmmm |
| 14:07:28 | raptor | well, my whole goal is simplicity |
| 14:07:34 | watusimoto | I think the big problems were when I was doing it with strings |
| 14:07:39 | raptor | ugh strings |
| 14:07:45 | watusimoto | and (perhaps) the strings mutated or something |
| 14:08:06 | watusimoto | don't remember the details... jsut rememeber ripping out a whole bunch of refs becuase of bad !@#$% |
| 14:09:13 | watusimoto | but I share your concerns about consistency and want to clean it up |
| 14:09:33 | watusimoto | ideally, getColor() would return a &color; that seems the most modern |
| 14:12:26 | | Guest59531 Quit (Ping timeout: 244 seconds) |
| 14:16:10 | raptor | ok, i'll just work on moving render methods into a class |
| 14:16:39 | raptor | this means that instead of just doing: renderFancyBox() it will be: RenderManager::renderFancyBox() |
| 14:16:53 | raptor | maybe i can get away with a macro... |
| 14:24:00 | watusimoto | we could do a using RenderManager, no?\ |
| 14:24:11 | watusimoto | then just renderFancyBox() |
| 14:24:36 | watusimoto | no that wouldn't work |
| 14:24:46 | watusimoto | you're talking static methods, I'm talking namespaces |
| 14:25:04 | raptor | you mean subclass it? |
| 14:25:11 | watusimoto | no, forget it |
| 14:25:11 | raptor | that might work... |
| 14:28:40 | watusimoto | why does renderFancyBox need to go into a class? |
| 14:28:49 | watusimoto | as a static, you won't be able to subclass it |
| 14:29:00 | watusimoto | or rather, override it |
| 14:29:38 | watusimoto | if you moved them into a namespace instead, we could "using" the namespace, and omit the prefix |
| 14:29:48 | watusimoto | unless the prefix is attractive in itself... |
| 14:30:19 | raptor | oh yeah |
| 14:30:26 | raptor | duh - i forgot about that... |
| 14:30:52 | raptor | wow, that makes it so much simpler... i don't have to change that much code, then |
| 14:30:59 | raptor | thanks! |
| 15:14:33 | watusimoto | you're welcome :-) |
| 15:27:47 | | Watusimoto_ has joined |
| 16:08:53 | | LordDVG has joined |
| 16:14:21 | | koda Quit (Ping timeout: 252 seconds) |
| 17:27:50 | | koda has joined |
| 18:03:54 | | kaen_mbp has joined |
| 18:14:49 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |
| 18:29:05 | | Watusimoto_ has joined |
| 19:02:34 | | Watusimoto_ Quit (Ping timeout: 250 seconds) |
| 19:18:04 | | Darrel Quit (Read error: Connection reset by peer) |
| 19:18:42 | | Darrel has joined |
| 19:24:53 | | Watusimoto_ has joined |
| 19:48:25 | | LordDVG Quit (Remote host closed the connection) |
| 20:34:35 | | Invisible has joined |
| 20:34:59 | | Invisible is now known as Guest2894 |
| 20:38:07 | | Guest2894 Quit (Client Quit) |
| 21:03:11 | | raptor Quit (Remote host closed the connection) |
| 21:11:27 | | Watusimoto_ Quit (Ping timeout: 244 seconds) |
| 21:22:44 | | Watusimoto_ has joined |
| 21:29:55 | | raptor has joined |
| 21:29:55 | | ChanServ sets mode +o |
| 21:36:45 | | kaen_mbp Quit (Remote host closed the connection) |
| 21:51:35 | | watusimoto Quit (Quit: Leaving.) |
| 22:37:13 | | kaen_mbp has joined |
| 22:38:02 | | watusimoto has joined |
| 22:38:02 | | ChanServ sets mode +o |
| 22:41:56 | | kaen_mbp Quit (Ping timeout: 256 seconds) |
| 22:48:52 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |
| 23:01:47 | | koda Quit (Quit: koda) |
| 23:04:31 | | Watusimoto_ has joined |
| 23:40:02 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |