Timestamps are in GMT/BST.
| 01:33:13 | | BFLogBot Comment on issue #149 | User: eykamp | Comment: This was done long ago, no? ... | https://github.com/bitfighter/bitfighter/issues/149#issuecomment-168134908 |
| 01:33:13 | | BFLogBot Issue #149 closed by eykamp | Title: Move editor key bindings to the INI file | https://github.com/bitfighter/bitfighter/issues/149 |
| 01:34:17 | | watusimoto has joined |
| 01:34:17 | | ChanServ sets mode +o |
| 01:55:24 | | DiannaAgron Quit (Quit: Leaving) |
| 03:03:31 | | amgine123 Quit (Ping timeout: 252 seconds) |
| 03:16:25 | fordcars | Night! |
| 03:16:27 | | fordcars Quit (Quit: Page closed) |
| 03:18:49 | | BFLogBot Repo: bitfighter | Commit: f8cb3e9594 | Author: eykamp | Message: Comments |
| 03:18:50 | | BFLogBot Repo: bitfighter | Commit: 43a4b5e32b | Author: eykamp | Message: Comment |
| 03:18:52 | | BFLogBot Repo: bitfighter | Commit: 96db75c480 | Author: eykamp | Message: Comments, reorder functions for clarity |
| 03:18:53 | | BFLogBot Repo: bitfighter | Commit: 4b3d3370e4 | Author: eykamp | Message: Combine blocks for clarity |
| 03:18:55 | | BFLogBot Repo: bitfighter | Commit: 5961a9de32 | Author: eykamp | Message: Move complexity out of macros and into a function |
| 03:18:56 | | BFLogBot Repo: bitfighter | Commit: 0dde023817 | Author: eykamp | Message: Remove unneeded else statements |
| 03:18:58 | | BFLogBot Repo: bitfighter | Commit: ba05699a07 | Author: eykamp | Message: Whitespace |
| 03:18:59 | | BFLogBot Repo: bitfighter | Commit: 9b461d9870 | Author: eykamp | Message: Input code enhancements Add new input codes (these are the only keys that can be mapped for use in-game, so adding more gives users more flexibility), use logic rather than brute force (with the new keycodes, this is probably faster and is definitely more maintainable) and add tests (to make sure the new code actually works as expected) |
| 03:19:01 | | BFLogBot Repo: bitfighter | Commit: 30f7b3e057 | Author: eykamp | Message: Fix test that broke with SDL upgrade |
| 03:19:02 | | BFLogBot Repo: bitfighter | Commit: c3d1758112 | Author: eykamp | Message: Fix warning in test |
| 03:35:30 | | Flynnn has joined |
| 04:33:22 | | watusimoto Quit (Quit: Leaving.) |
| 05:01:57 | | Flynnn Quit (Quit: Auf Wiedersehen!) |
| 05:02:18 | | Flynnn has joined |
| 05:02:45 | | Flynnn Quit (Client Quit) |
| 06:03:16 | | -mist- [Festive new year global notice] As we start to see the New Year in in more populated timezones, festive wallops and globals appear on the horizon. Join the new-year fun in #freenode-newyears. Or don't. I'm not the police. |
| 06:03:51 | | Nothing_Much Quit (Remote host closed the connection) |
| 09:18:32 | | DiannaAgron has joined |
| 11:03:04 | | Flynnn has joined |
| 11:06:20 | | Flynnn Quit (Client Quit) |
| 11:14:22 | | Flynnn has joined |
| 11:19:05 | | Flynnn Quit (Ping timeout: 250 seconds) |
| 11:55:22 | | Flynnn has joined |
| 12:45:59 | | BFLogBot Repo: bitfighter | Commit: 19cb51e227 | Author: raptor | Message: Explicitly set CMake sub-projects to compile as static libs. This helps with Linux build systems |
| 13:07:55 | | BFLogBot Comment on issue #533 | User: raptor | Comment: Found some likely useful info on how to do this: http://stackoverflow.com/questions/13647108/matrix-stacks-in-opengl-de ... | https://github.com/bitfighter/bitfighter/issues/533#issuecomment-168230887 |
| 13:30:58 | | watusimoto has joined |
| 13:30:58 | | ChanServ sets mode +o |
| 14:32:12 | | Nothing_Much has joined |
| 15:46:07 | | Flynnn Quit (Quit: Auf Wiedersehen!) |
| 15:48:44 | | raptor has joined |
| 15:48:44 | | ChanServ sets mode +o |
| 15:50:11 | raptor | good day! |
| 16:13:16 | | Flynnn has joined |
| 16:40:47 | raptor | watusimoto: I've been thinking about dropping the sqlite dependency... it's been 2 (3?) years and no-one that I know has used it for local stat saving |
| 16:41:00 | raptor | or maybe disabling it by default... |
| 16:53:01 | | Flynnn Quit (Quit: Auf Wiedersehen!) |
| 16:55:54 | raptor | the founder of debian just passed away: http://arstechnica.com/information-technology/2015/12/ian-murdock-father-of-debian-dead-at-42/ |
| 17:07:48 | Nothing_Much | yup |
| 17:20:43 | watusimoto | raptor: I'm going to use sqllite for storing level attributes |
| 17:21:19 | watusimoto | I want to start storing some metadata about levels, such as their size, which is expensive to compute (which is why levels currently load so slowly when hosting now) |
| 17:21:19 | raptor | oh? |
| 17:21:22 | raptor | how so |
| 17:21:29 | watusimoto | and maybe even zone geometry |
| 17:21:40 | watusimoto | so it need not be recomputed if the level hasn't changed |
| 17:21:59 | raptor | so for stats purposes? |
| 17:22:10 | watusimoto | in 19x, we loaded just the first 4k of a level, to extract header info |
| 17:22:40 | watusimoto | currently, in 020, we're loading each level in its entirety, and computing zones for it... some levels (subway, for example) load very slowly |
| 17:22:49 | watusimoto | my solution is to cache the results |
| 17:23:23 | raptor | sam686 made a cache like that, once, for 015, i think |
| 17:23:33 | watusimoto | though I'm not sure how to handle dynamic levels |
| 17:23:42 | raptor | are you wanting to cache the zones? |
| 17:23:46 | watusimoto | probably skip preprocessing them altogether |
| 17:23:54 | raptor | because that is exactly what sam686 did |
| 17:23:57 | watusimoto | not sure... I've thought about it |
| 17:24:06 | watusimoto | what did he do? |
| 17:24:46 | watusimoto | I definitely want to cache the level "size" (i.e. its playable area), and zones are the only way I can think of to compute that |
| 17:24:53 | watusimoto | compute the zones, sum the area... viola! |
| 17:24:55 | raptor | before we did recast/triangle/etc., he would build up bot zones using his square/rectangle method he came up with and would cache the result in custom files alongside the level files |
| 17:25:04 | watusimoto | ah, I see |
| 17:25:15 | watusimoto | if we cache them, I'd do it in mysql |
| 17:25:19 | watusimoto | sorry |
| 17:25:20 | watusimoto | sqllite |
| 17:25:24 | watusimoto | sqlite |
| 17:25:44 | watusimoto | for most levels, it wouldn't make much difference |
| 17:26:03 | watusimoto | for a few, it would (i.e. subway, which has tons of curves, and takes about 2 seconds to load) |
| 17:26:15 | raptor | ah... |
| 17:26:21 | raptor | now that |
| 17:26:31 | raptor | is a different issue in my mind |
| 17:26:50 | watusimoto | which? |
| 17:27:04 | raptor | the curve problem |
| 17:27:21 | watusimoto | yes, it's a different issue, but impacts zone generation |
| 17:27:34 | raptor | kaen and i had long discussions on rresolving the issues with the advent of curves |
| 17:27:39 | watusimoto | perhaps we can generalize curves before zone generation |
| 17:27:45 | watusimoto | to reduce point count |
| 17:27:48 | raptor | oh yes |
| 17:27:58 | watusimoto | but that is itself a difficult problem, I thin |
| 17:28:00 | watusimoto | k |
| 17:28:15 | raptor | the 'best' solution was to implement bezier curves that could be rasterized when needed independently on client or server |
| 17:28:29 | watusimoto | ah yes, that |
| 17:28:32 | raptor | this would also reduce network load in level transfer |
| 17:28:42 | watusimoto | I don't love curves at all, but we seem to be stuck with them |
| 17:28:50 | watusimoto | so might as well make them efficienter |
| 17:28:57 | raptor | haha |
| 17:29:36 | raptor | i don't quite remember everything we came up with, but we had the idea of rasterizing them in a less curvy manner for zone generation |
| 17:29:52 | | Flynnn has joined |
| 17:29:59 | raptor | so user display would be finer curves, but botzone on the server would be coarser |
| 17:30:14 | watusimoto | there are standard algorithms for generalizing lines, maybe we can find one that's fast and good enough |
| 17:31:04 | watusimoto | but, even if that problem gets solved, I think it would make sense to cache metadata on the server, to make hosting faster |
| 17:31:35 | watusimoto | we can rip through the levels, check their md5 hash, check the database, and if we have the data on file, don't process anything |
| 17:31:45 | watusimoto | that would make loading much faster |
| 17:31:57 | watusimoto | I think |
| 17:32:15 | watusimoto | even if we still compute zone geometry at play-time |
| 17:32:49 | watusimoto | maybe we could achieve the same goal without sqlite... just store the data in a flat file which gets read into memory at runtime |
| 17:33:33 | watusimoto | it probably wouldn't be too huge... 1000 levels * (name + author + size + date + hash + ...) |
| 17:33:52 | raptor | yeah, that would be good i think - less complex than using sqlite, maybe |
| 17:34:22 | watusimoto | would removing sqlite really help... anything? |
| 17:34:30 | raptor | yeah, i think the cache would really help servers with 100s of files |
| 17:34:48 | raptor | it woudl reduce binary size and dependency needs |
| 17:34:51 | watusimoto | it's a pretty standard dependency |
| 17:35:04 | watusimoto | and the binary is already pretty small |
| 17:35:07 | raptor | and we compile it statically |
| 17:35:37 | raptor | yeah, i suppose not much - sometimes the housekeeping side of me kicks in... |
| 17:35:56 | watusimoto | I hear you... removing dependencies is good |
| 17:36:27 | watusimoto | simplifying is good |
| 17:36:48 | watusimoto | on the other hand, if we remove it, we'll need to reimplement similar functionatliy to store the metadata |
| 17:37:18 | watusimoto | that means creating a new file/format, parsing it, writing to it, storing all that in memory, which will increase the footprint on small servers |
| 17:37:20 | raptor | but we still need to do that with sqlite - come up with a schema, etc. |
| 17:37:26 | watusimoto | true |
| 17:37:34 | watusimoto | but it's just a simple table |
| 17:37:50 | raptor | ah |
| 17:37:57 | raptor | no multidimensions? |
| 17:38:03 | watusimoto | what dimensions? |
| 17:38:12 | raptor | then that's my answer |
| 17:38:28 | watusimoto | levelname, author, hash, size, hasEngineer, isDungeon,... |
| 17:38:47 | watusimoto | so you're thinking the structure is simple enough to not use a database |
| 17:39:46 | raptor | first thing comes to mind is an INI with: 0123abcdef=name|blah|blah2|hasEngineer |
| 17:39:57 | watusimoto | https://stackoverflow.com/questions/19946298/what-is-the-advantage-of-using-sqlite-rather-than-file |
| 17:40:12 | raptor | but we'd need ot use some delimiting string that wouldn't get used, or some byte |
| 17:40:26 | watusimoto | or just use || to quote a | |
| 17:41:20 | raptor | that's too many good advantages... |
| 17:41:46 | raptor | yeah, i suppose advanced things like filtering on hasEngineer could then be implemented |
| 17:42:07 | watusimoto | More android related reasons: https://stackoverflow.com/questions/6347285/android-dictionary-file-which-is-faster-database-or-reading-file-directly/6348138#6348138 |
| 17:42:32 | watusimoto | though our servers are theoretically memory limited |
| 17:42:54 | watusimoto | vps resources that are most likely constrained are cpu and memory |
| 17:43:11 | raptor | ok ok, you win... my case against sqlite rests. it has too much potential, still :] |
| 17:43:35 | watusimoto | let's re-evaluate after I make a first pass at the metadata cacheing |
| 17:43:48 | watusimoto | I agree the existing uses are not overly compelling |
| 17:44:39 | watusimoto | See the 17 point answer... it offers some support for files |
| 17:44:40 | watusimoto | https://stackoverflow.com/questions/2356851/database-vs-flat-files |
| 17:46:04 | watusimoto | I keep thinking we should store entire levels in a database |
| 17:46:11 | watusimoto | perhaps pre-parsed |
| 17:46:23 | watusimoto | though I can't really justify it on any rational basis |
| 17:46:36 | raptor | what did you determine would be a good level identifier? filesize+name+date? |
| 17:47:00 | watusimoto | I was going to use MD5, but what you suggested would be good enough |
| 17:47:05 | raptor | i wonder how long it would take to md5 1000 levels |
| 17:47:25 | watusimoto | that's a fair question |
| 17:47:37 | watusimoto | one which I will (perhaps) answer :-) |
| 17:47:58 | raptor | the other issue that i remember being brought up is what happens to two identical levels that have different line endings because of copy/pasting from pleiades |
| 17:48:00 | watusimoto | if the md5 is not super fast, I'll fall back to filesize/date |
| 17:48:12 | raptor | md5 is pretty quick |
| 17:48:32 | watusimoto | yes, and the files are small... my concern is reading all the files |
| 17:48:36 | raptor | and if only needed to do once - i bet it's negligible. tomcrypt has other hash functions that are even faster, i bet |
| 17:48:53 | watusimoto | I'm not worried about collisions |
| 17:49:35 | watusimoto | look at the table here: |
| 17:49:35 | watusimoto | https://code.google.com/p/xxhash/ |
| 17:50:16 | raptor | oh wow |
| 17:50:21 | raptor | and sitll high quality |
| 17:50:24 | watusimoto | But no C++ impl |
| 17:50:47 | raptor | that's ok... it's C |
| 17:50:56 | raptor | https://github.com/Cyan4973/xxHash |
| 17:51:01 | watusimoto | oh yes.. I was looking at the list of other implementations |
| 17:52:15 | watusimoto | so we're really limited by file i/o |
| 17:52:23 | watusimoto | well, i, at least |
| 18:02:22 | watusimoto | http://www.boost.org/doc/libs/1_50_0/libs/geometry/doc/html/geometry/reference/algorithms/simplify/simplify_3.html |
| 18:02:43 | watusimoto | since we love boost :-) |
| 18:04:23 | watusimoto | maybe angus wrote something similar :-) |
| 18:05:48 | | Nothing_Much Quit (Remote host closed the connection) |
| 18:25:29 | watusimoto | he didn't |
| 19:13:53 | raptor | what is that boost::simplify supposed to do? |
| 19:14:26 | raptor | ohhh.... kaen wrote that already with a lua editor plugin |
| 20:09:06 | watusimoto | yes, but we want something fast! |
| 20:12:01 | raptor | also boost::simplify is already included in our repo... |
| 20:34:55 | watusimoto | well that's helpful! it looks super easy to use |
| 20:35:42 | watusimoto | we probably just need to pass the points through it when we're loading a wall, and save a simplified copy that we can use for the zone gen |
| 21:23:56 | raptor | so are we serious about bezier curve implementation? We'd probably have to make a new game object: BezierBarrier or something |
| 21:28:20 | watusimoto | well, I'm not serious about doing it myself... it would be a lot of work, especially in the editor. But I am not seriously opposed :-) |
| 21:28:32 | watusimoto | And yes, it would probably take a new wall type |
| 21:29:13 | watusimoto | The current state of affairs is bearable |
| 21:38:25 | | Flynnn Quit (Quit: Auf Wiedersehen!) |
| 21:48:36 | | watusimoto Quit (Read error: Connection reset by peer) |
| 22:02:16 | | Flynnn has joined |
| 23:20:40 | | raptor Quit () |