Timestamps are in GMT/BST.
| 00:06:38 | | Watusimoto_ has joined |
| 00:14:23 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 00:27:08 | | Watusimoto_ has joined |
| 00:29:06 | Watusimoto_ | hi |
| 00:29:13 | raptor | jo |
| 00:29:17 | raptor | err... hi |
| 00:30:30 | Watusimoto_ | fingers in the home position, please |
| 00:31:04 | Watusimoto_ | so thanks for fixing the master -- now the motd changes on clients when updated. I could even test it! |
| 00:31:18 | raptor | oh good... and it was back-portable to 019 ok? |
| 00:31:55 | Watusimoto_ | it was master-only |
| 00:32:01 | Watusimoto_ | so back-porting was automatic |
| 00:32:14 | Watusimoto_ | just curious; why do you prefer ++it to it++? |
| 00:32:17 | raptor | wow, an issue was actually resolved! |
| 00:32:50 | raptor | oh... honestly, that was what all the examples just did... also, i think it saves a cpu cycle or two |
| 00:32:58 | raptor | but really, i like it++ for most things |
| 00:33:39 | raptor | also some of the examples on deleting-while-iterating actually depended on one or the other form, so I just left it because i didn't want to do much thinking :) |
| 00:33:46 | Watusimoto_ | I'm willing to bet almost anytning that x++ and ++x compile to exactly the same thing |
| 00:33:56 | raptor | they don't - i've seen it different |
| 00:34:05 | raptor | it++ uses a temporary, i think |
| 00:34:13 | Watusimoto_ | can't be! |
| 00:34:39 | Watusimoto_ | let's find out: http://stackoverflow.com/questions/1812990/incrementing-in-c-when-to-use-x-or-x |
| 00:34:40 | raptor | i bet advanced compilers switch the it++ to ++it |
| 00:35:06 | Watusimoto_ | the only cases I've seen ++x be useful is when the incrementing is abused; like this: |
| 00:35:11 | Watusimoto_ | y = (++x) |
| 00:35:22 | Watusimoto_ | which would give a different result from y = (x++) |
| 00:35:25 | raptor | ha |
| 00:35:35 | Watusimoto_ | but neither of which should _ever_ be used, IMO |
| 00:35:35 | raptor | i've seen almost always used more in older C code |
| 00:35:40 | raptor | the ++it |
| 00:36:35 | Watusimoto_ | and please note that in a for loop, on primatives, there is absolutely no difference. Many coding styles will recommend never using an increment operator where it could be misunderstood; i.e., x++ or ++x should only exist on its own line, never as y=x++. |
| 00:36:49 | Watusimoto_ | ^^ totally agree with that |
| 00:36:59 | raptor | yes, i agree, too |
| 00:37:06 | raptor | i hate having to do a double take on the code |
| 00:37:07 | Watusimoto_ | And if used on its own line, the generated code is almost sure to be the same. |
| 00:38:29 | raptor | here's one answer: https://stackoverflow.com/a/24904 |
| 00:39:35 | Watusimoto_ | hmmm.... >>> you got the iterator stuff exactly the wrong way round. ++i is faster, because it will not copy the object, i++ is slower, because it first creates a copy of the object, increments the iterator and then return the copied object (which is still in the same state) |
| 00:40:11 | raptor | so in class-operator scenarios it's slower, but i bet most c compilers on primitive types are equally efficient |
| 00:41:01 | Watusimoto_ | I never use iterators, (at least no explicitly), so my thinking on them may not be correct |
| 00:41:41 | raptor | java 1.4 code had iterators everywhere |
| 00:42:09 | Watusimoto_ | I've never felt comfortable with them |
| 00:42:10 | raptor | now java uses this syntax for loops, which i like much better: for(String s: someStringList) |
| 00:42:13 | Watusimoto_ | give me a for loop any day! |
| 00:42:20 | Watusimoto_ | I like it better too |
| 00:42:40 | Watusimoto_ | c# lets you do for(var s in someStringList) |
| 00:42:50 | Watusimoto_ | i.e. you can let the compiler figure out what type s is |
| 00:42:57 | raptor | yep, much nicer |
| 00:42:59 | raptor | oh, ha! |
| 00:43:11 | raptor | c# is pseudo-dynamically typed? |
| 00:43:22 | Watusimoto_ | handy when you are dealing with complex<nested<generic,types>> |
| 00:43:29 | raptor | that's like python... |
| 00:43:39 | raptor | haha |
| 00:43:43 | Watusimoto_ | it's completely statically typed |
| 00:43:54 | Watusimoto_ | var only works when the compiler can figure out the type from the statement |
| 00:43:59 | raptor | ah ok |
| 00:44:03 | Watusimoto_ | it reduces pedantry |
| 00:44:07 | raptor | yeah |
| 00:44:17 | Watusimoto_ | no more: List<int> x = new List<int>() |
| 00:44:24 | Watusimoto_ | rather, var x = new List<int>() |
| 00:44:32 | raptor | java, at least up to java 1.7, always throws warnings when you don't specify the types |
| 00:44:48 | Watusimoto_ | but you cannot do: var x; |
| 00:44:52 | raptor | drives me nuts when porting older code |
| 00:44:58 | Watusimoto_ | yes |
| 00:45:07 | Watusimoto_ | if the compiler can do the work, it should do the work |
| 00:45:09 | raptor | true |
| 00:45:20 | raptor | i think c# has surpassed java in many ways |
| 00:45:25 | Watusimoto_ | yes |
| 00:45:47 | Watusimoto_ | and it's (now) about the same level of open-sourcedness |
| 00:45:49 | raptor | and now that they've open sourced the VM... maybe we'll be a c# shop in the near future! |
| 00:45:53 | Watusimoto_ | yes |
| 00:45:54 | raptor | yes |
| 00:45:57 | Watusimoto_ | yes |
| 00:45:59 | raptor | haha |
| 00:46:14 | Watusimoto_ | neither seems truly opensource |
| 00:46:19 | Watusimoto_ | only somewhat so |
| 00:47:21 | raptor | yeah, it's true - java spec has been open source for a while, but not the oracle/sun JVM |
| 00:47:30 | raptor | which is the fastest |
| 00:47:55 | raptor | oracle has done a good job at slowly killing java's potential, i think |
| 00:48:15 | raptor | and google has done a good job at building it (with android) |
| 00:48:24 | raptor | back in a bit... |
| 01:33:30 | raptor | not sure if you've seen this: https://www.youtube.com/watch?v=8F9jXYOH2c0 |
| 01:39:57 | Watusimoto_ | man, this latest checkin was a waste of time! |
| 01:40:02 | | BFLogBot_ Commit: b2444475d5 | Author: watusimoto | Message: Whitespace |
| 01:40:04 | | BFLogBot_ Commit: f1a226eb50 | Author: watusimoto | Message: False start |
| 01:40:05 | | BFLogBot_ Commit: 7ca9641a9f | Author: watusimoto | Message: Variable name |
| 01:40:07 | | BFLogBot_ Commit: f330cb1513 | Author: watusimoto | Message: Switch motd from const char to string |
| 01:40:08 | | BFLogBot_ Commit: f2abccec84 | Author: watusimoto | Message: Make changing MOTD appear smoother on client (020 only, could be backported) |
| 01:40:10 | | BFLogBot_ Commit: 2dc697c013 | Author: watusimoto | Message: Merge |
| 01:40:18 | Watusimoto_ | but it satisifies my inner Felix Unger (and now you know the reference!) |
| 01:40:23 | raptor | haha |
| 01:40:27 | raptor | i'll take a look.. |
| 01:41:11 | Watusimoto_ | You'll have to compile 020 with a modified version.h to fake it being 019d -- otherwise you don't get the current motd, and that's the only one that dynamically updates |
| 01:41:29 | raptor | was the smoothness really in question? |
| 01:42:24 | Watusimoto_ | not really |
| 01:42:41 | Watusimoto_ | in 019d, the position resets when a new motd arrives |
| 01:42:56 | raptor | ahhh |
| 01:42:59 | Watusimoto_ | in practice, this is a very rare event, but it shows up a lot when testing it :-) |
| 01:43:05 | raptor | ha! |
| 01:43:21 | Watusimoto_ | now it just swaps out the old, and the overall position doesn't change |
| 01:43:29 | Watusimoto_ | so it is pretty subtle |
| 01:43:56 | raptor | oh, if you didn't see... your Felix Unger commit had some muphrey's law aspect to it (take a close look): https://code.google.com/p/bitfighter/source/detail?r=ea54f970b3b0cdb4ab90ad3bb1f3c996d81fde2a |
| 01:44:05 | raptor | :) |
| 01:47:40 | Watusimoto_ | great soccer |
| 01:48:53 | Watusimoto_ | oh, great. |
| 01:50:01 | | BFLogBot_ Commit: 5343c377fb | Author: watusimoto | Message: @#$%^& |
| 01:50:16 | Watusimoto_ | You probably know what that is without even looking :-) |
| 01:50:31 | raptor | haha |
| 01:59:56 | raptor | I have 90% of an Opus implementation that I started before thanksgiving... trying to get the willpower to finish it |
| 02:16:18 | raptor | sleepy... good night! |
| 02:16:23 | Watusimoto_ | night! |
| 02:16:28 | | raptor Quit () |
| 03:57:19 | | BFLogBot_ Commit: 02e6cf105d | Author: watusimoto | Message: Replace color with name |
| 03:57:21 | | BFLogBot_ Commit: e8d082616a | Author: watusimoto | Message: Share code more |
| 05:11:04 | | Watusimoto_ Quit (Ping timeout: 245 seconds) |
| 08:13:13 | | Darrel Quit (Read error: Connection reset by peer) |
| 08:13:55 | | Darrel has joined |
| 08:20:27 | | Darrel Quit (Ping timeout: 256 seconds) |
| 08:20:34 | | Darrel has joined |
| 08:31:06 | | Darrel Quit (Ping timeout: 264 seconds) |
| 08:45:13 | | koda has joined |
| 09:00:26 | | Darrel has joined |
| 09:52:17 | | koda Quit (Quit: koda) |
| 09:52:36 | | koda has joined |
| 10:32:49 | | Watusimoto_ has joined |
| 10:34:20 | | CrazyLinuxNerd Quit (Quit: Going.. Going.. Gone) |
| 10:39:23 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 10:44:57 | | CrazyLinuxNerd has joined |
| 11:16:39 | | raptor has joined |
| 11:16:39 | | ChanServ sets mode +o |
| 11:16:45 | raptor | good day! |
| 11:40:10 | raptor | HelpItemManager.cpp is broke with the GuageRenderer changes last night: it uses some previously public members of EnergyGaugeRenderer |
| 11:40:22 | raptor | not sure how to fix yet... |
| 12:23:17 | | koda Quit (Quit: koda) |
| 12:23:42 | | koda has joined |
| 13:00:19 | watusimoto | hello |
| 13:00:30 | watusimoto | I'll fix helpItemRenderer |
| 13:00:34 | watusimoto | since I broke it |
| 13:00:58 | watusimoto | I moved on to a long-term project to get ready for porting to gles2 |
| 13:01:20 | watusimoto | I did a bunch of mindless work, then wanted to look something up |
| 13:01:23 | watusimoto | and found this: |
| 13:01:24 | watusimoto | https://github.com/p3/regal |
| 13:01:32 | watusimoto | this might be a good short-term solution |
| 13:12:16 | raptor | I've already loked at regal - it's overkill, unless we can pull out what we need |
| 13:12:26 | raptor | also, kaen has rebased his shader work on 020 branch |
| 13:13:53 | raptor | there's a diff of it somewhere; i'll get it after my next meeting |
| 13:23:11 | | kaen_mbp has joined |
| 13:34:52 | watusimoto | my biggest worry is not the shaders, but rather all the pushMatrix/popMatrix stuff; I started to rewrite that to do the management ourselves, but I was thinking regal might save us the trouble. |
| 13:51:48 | | kaen_mbp Quit (Ping timeout: 256 seconds) |
| 14:01:20 | raptor | the problem I had with regal, when researching it, was that it added something like 8MB of library size |
| 14:01:38 | raptor | but admittedly, i did not looking into specific build options to reduce that |
| 14:10:32 | | kaen_mbp has joined |
| 14:20:25 | | kaen_mbp_ has joined |
| 14:22:01 | | kaen_mbp Quit (Ping timeout: 250 seconds) |
| 15:20:30 | | kaen_mbp has joined |
| 15:21:49 | | kaen_mbp_ Quit (Ping timeout: 250 seconds) |
| 15:28:03 | | koda Quit (Ping timeout: 244 seconds) |
| 15:36:08 | | LordDVG has joined |
| 15:50:00 | watusimoto | I'll bet we could delete 90% of regal and still get what we need |
| 16:41:55 | | Nothing_Much Quit (Ping timeout: 264 seconds) |
| 16:46:58 | | CrazyLinuxNerd Quit (Quit: Going.. Going.. Gone) |
| 16:47:16 | | CrazyLinuxNerd has joined |
| 17:07:22 | | Nothing_Much has joined |
| 17:28:29 | | LordDVG Quit (Remote host closed the connection) |
| 17:58:34 | | koda has joined |
| 18:06:57 | | Darrel Quit (Read error: Connection reset by peer) |
| 18:07:13 | | Darrel has joined |
| 19:26:00 | | koda Quit (Read error: Connection reset by peer) |
| 19:26:06 | | kodabb has joined |
| 20:30:49 | | raptor Quit (Disconnected by services) |
| 20:31:09 | | raptor has joined |
| 20:31:09 | | ChanServ sets mode +o |
| 21:39:37 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 22:12:10 | | kodabb Quit (Quit: kodabb) |
| 22:16:19 | | watusimoto Quit (Quit: Leaving.) |
| 23:01:40 | | watusimoto has joined |
| 23:01:40 | | ChanServ sets mode +o |
| 23:20:10 | raptor | we'd have to link against regal instead of the normal opengl libraries... at least, that's what it says it usage is |
| 23:20:22 | raptor | and we'd have to do nothing different in our code |
| 23:22:27 | raptor | looks like oglconsole may not work with it.. |
| 23:28:55 | | Nothing_Much has joined |
| 23:30:59 | raptor | regal's build system seems to compile in lots of dependencies, statically |
| 23:34:45 | raptor | oh wow, just the GL/Regal.h header is 2.5MB large |
| 23:43:59 | raptor | ah ha - this may be more what we want instead of regal: https://github.com/lunixbochs/glshim |
| 23:51:36 | | Flynnn has joined |
| 23:59:10 | raptor | i think glshim looks quite good - the openpandora guys developed it and have been running linux opengl games with it on their platform |