Timestamps are in GMT/BST.
| 00:01:43 | raptor | hmmm |
| 00:06:26 | raptor | i think all the linux sites should have a single submission api... |
| 00:07:23 | Watusimoto | came across this |
| 00:07:24 | Watusimoto | https://bitbucket.org/alexames/luawrapper/src |
| 00:08:00 | Watusimoto | like lunar, but solves the inheritance problem I started out this most recent odessy thinking about |
| 00:08:03 | Watusimoto | good night |
| 00:08:08 | raptor | good ngiht |
| 00:09:09 | raptor | looks simple.. |
| 00:13:19 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 03:11:24 | raptor | i just saved a level file and it had a line like this in it: LineItem 0 -1008442647 -0.2 -1.3 -0.3 -1.5 -0.1 -1.7 0.1 -1.7 0.3 -1.5 0.2 -1.3 |
| 03:11:33 | raptor | that second number looks really wrong |
| 03:20:08 | | koda Quit (Quit: koda) |
| 03:50:47 | raptor | hey sam686, look what i did: http://sam686.maxhushahn.com/upload/11111screenshot_0.png |
| 03:50:53 | raptor | does it look OK? |
| 03:52:46 | sam686 | ok, looks different... i guess that is ok |
| 03:57:26 | raptor | for a bot shape... |
| 04:30:37 | | Zoomber has joined |
| 04:30:37 | | ChanServ sets mode +v Zoomber |
| 04:30:58 | Zoomber | hi |
| 04:31:13 | Zoomber | raptor: it took me about 10 tries with the same password to get me into the forums :o |
| 04:31:30 | Zoomber | thats why i havent posted anything in a while |
| 04:40:57 | raptor | hi Zoomber |
| 04:41:03 | raptor | do you need the pw reset? |
| 04:42:04 | Zoomber | i got in tonight, strangley |
| 04:42:19 | Zoomber | not sure what did it, but it worked now |
| 04:43:13 | raptor | ok |
| 04:43:29 | Zoomber | cloaker spies? a meh/no for me |
| 04:43:36 | raptor | yeah... |
| 04:43:38 | Zoomber | it seems way too overpowered |
| 04:45:08 | raptor | people want complication |
| 04:45:15 | raptor | not sure if that fits the game very well |
| 04:52:08 | raptor | Zoomber: what do you think of this ship shape?: http://sam686.maxhushahn.com/upload/11111screenshot_0.png |
| 04:52:43 | Zoomber | what is that exactly suppsed to be? |
| 04:52:47 | Zoomber | a whole new ship design? |
| 04:52:54 | raptor | a klingon bird-of-prey |
| 04:52:54 | Zoomber | or like, an activated module? |
| 04:53:06 | raptor | for an extra bot shape |
| 04:53:18 | Zoomber | eh, i could probably get used to it |
| 04:53:21 | Zoomber | but only if its for bots |
| 04:53:26 | raptor | yeah... |
| 04:53:35 | raptor | it's really weird as a player... |
| 04:53:37 | Zoomber | actually |
| 04:54:03 | Zoomber | if we use it, we can put it in the s_bot file, as having the "turret" weapon |
| 04:54:16 | Zoomber | so, this bot essentially shoots weaker, but the bullets take no energy when it shields |
| 04:55:12 | Zoomber | by the way, it seems like bases would look better if the outline is defined in aa white border, not a blue border hexagon |
| 04:55:42 | raptor | it isn't a white outline? |
| 04:55:45 | raptor | looks so to me... |
| 04:55:55 | raptor | oh |
| 04:55:56 | raptor | bases |
| 04:56:01 | Zoomber | yes |
| 04:56:04 | raptor | sorry, i misunderstood |
| 04:56:18 | raptor | yes they were like that in 016 |
| 04:56:23 | Zoomber | yeah |
| 04:56:25 | raptor | not sure why the change... |
| 04:56:29 | Zoomber | doesn |
| 04:56:31 | Zoomber | oops |
| 04:56:35 | Zoomber | doesn't seem to make that much sense |
| 04:58:34 | raptor | here: http://sam686.maxhushahn.com/upload/111111screenshot_1.png |
| 04:58:37 | raptor | look better?? |
| 04:58:53 | Zoomber | on the right track |
| 04:58:59 | Zoomber | maybe it just needs to be a toned-down white |
| 04:59:02 | Zoomber | or a greyish |
| 05:02:17 | raptor | this: http://sam686.maxhushahn.com/upload/11111screenshot_2.png |
| 05:02:49 | raptor | same grey level as the inner circle |
| 05:03:10 | Zoomber | thats better |
| 05:03:25 | Zoomber | so, turrets can shoot through the bases now? |
| 05:03:33 | raptor | nope |
| 05:03:43 | Zoomber | ah ok, so just a wierd map thing |
| 05:03:53 | raptor | yeah - one of sam686's generated ones |
| 05:17:03 | raptor | sam686: what do you think of Core with grey outer shell?: http://sam686.maxhushahn.com/upload/11111screenshot_2.png |
| 05:23:49 | sam686 | looks ok, easier to see then blue.. |
| 05:27:34 | raptor | i'm going to bed, good night |
| 05:27:46 | | raptor Quit () |
| 06:02:23 | | Zoomber Quit (Quit: Zoomber) |
| 07:40:17 | | Watusimoto has joined |
| 08:01:23 | | Watusimoto Quit (Remote host closed the connection) |
| 08:01:49 | | Watusimoto has joined |
| 08:01:51 | Watusimoto | Good morning all -- I made an important discovery! |
| 08:03:32 | Watusimoto | By simply gutting doFindItems(), having it always return nil, I was able to run up to 100 bots on Mad Cow no problem. |
| 08:03:38 | Watusimoto | Of course, they didn't work very well |
| 08:03:51 | Watusimoto | but that tells me that this one function may be our bottleneck |
| 08:04:20 | Watusimoto | and, perhaps, specifically the creation (and subsequent destruction) of the table that holds the search results |
| 08:05:06 | Watusimoto | so maybe all we need is a more efficieint way of returning results; perhaps by reusing a table in the same manner as fillVector |
| 08:05:14 | Watusimoto | or something |
| 08:05:44 | Watusimoto | Anyway, food for thought |
| 08:05:59 | | sam686 Quit (Ping timeout: 245 seconds) |
| 08:27:38 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 09:06:00 | | Watusimoto has joined |
| 10:07:44 | Watusimoto | ok, tried using the fillVector method as an experiment |
| 10:07:47 | Watusimoto | dramatic improvement |
| 10:13:09 | Watusimoto | or at least some improvement |
| 10:18:08 | Watusimoto | big difference |
| 10:18:28 | Watusimoto | I can run with 100 bots at 40 fps if the bots are not on screen |
| 10:18:37 | Watusimoto | running mad cow with /addbots 100 |
| 10:32:52 | Watusimoto | though there is a problem with something because the bots don't do their wayfinding correctly |
| 11:44:00 | Watusimoto | ok, fixed the navigation issue, situation is less good than it was, but may still reduce memory thrashing |
| 11:44:16 | Watusimoto | I need to clean up some things, and I can commit for further testing |
| 12:03:46 | | Watusimoto_ has joined |
| 12:05:59 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 12:20:14 | | watusimoto has joined |
| 12:20:15 | | ChanServ sets mode +o watusimoto |
| 13:08:25 | | Watusimoto__ has joined |
| 13:08:31 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |
| 13:12:38 | | Watusimoto__ Quit (Ping timeout: 240 seconds) |
| 13:13:18 | | koda has joined |
| 13:15:28 | | watusimoto Quit (Ping timeout: 245 seconds) |
| 13:23:56 | | Watusimoto has joined |
| 13:26:58 | Watusimoto | The modifications you need to make the bots work my new way are here: |
| 13:26:59 | Watusimoto | http://pastie.org/3755544 |
| 13:27:05 | Watusimoto | I'm still not ready to check in |
| 13:27:30 | Watusimoto | you can pass a dummy string for methodName for testing purposes |
| 13:27:54 | Watusimoto | there may also be some new bot stuff in the C++, not sure |
| 13:28:14 | Watusimoto | also eliminates some dynamic_cast action |
| 14:19:22 | Watusimoto | http://lua-users.org/wiki/OptimisingGarbageCollection |
| 14:27:01 | | raptor has joined |
| 14:27:01 | | ChanServ sets mode +o raptor |
| 14:27:24 | raptor | good morning! |
| 14:27:55 | Watusimoto | hi |
| 14:28:01 | raptor | reading logs... |
| 14:29:15 | raptor | looking at pastie... |
| 14:29:15 | Watusimoto | lots to read |
| 14:29:50 | raptor | so you create the table in the script just once? |
| 14:30:00 | raptor | _fillTable = {} |
| 14:30:40 | Watusimoto | yes, but I hate this design |
| 14:31:06 | raptor | hmm... |
| 14:31:14 | raptor | seems kind of roundabout |
| 14:31:27 | raptor | forcing the user to create the table |
| 14:31:29 | Watusimoto | no different than fillVector |
| 14:31:32 | raptor | in the script |
| 14:31:42 | Watusimoto | I created a wrapper so they don't have to |
| 14:31:54 | raptor | ah, helper function, i see it |
| 14:33:21 | Watusimoto | still don't like it |
| 14:33:27 | raptor | what don't you like about it specifically? |
| 14:35:38 | Watusimoto | ugly... I'll be back in a little bit |
| 14:35:42 | raptor | k |
| 14:40:22 | | Watusimoto Quit (Ping timeout: 265 seconds) |
| 15:00:25 | | koda Quit (Quit: koda) |
| 15:03:03 | | koda has joined |
| 15:03:39 | | koda Quit (Client Quit) |
| 15:09:09 | | LordDVG has joined |
| 15:29:44 | | Watusimoto has joined |
| 15:36:32 | | LordDVG Quit (Remote host closed the connection) |
| 15:37:00 | | LordDVG has joined |
| 15:37:15 | raptor | Watusimoto: i had some people say that Core exterior should still be grey/white: http://sam686.maxhushahn.com/upload/11111screenshot_2.png |
| 15:37:28 | raptor | because when other colors, it's hard to see sometimes... |
| 15:37:34 | raptor | what do you think? |
| 15:38:28 | Watusimoto | ok |
| 15:38:31 | Watusimoto | sure |
| 15:39:02 | raptor | but other than that - i've gotten overwhelming positive feedback on the new Core |
| 15:39:55 | Watusimoto | excellent |
| 15:40:08 | Watusimoto | I'm glad some of my ideas are liked! |
| 15:46:38 | raptor | should I keep the panel debris color?: http://sam686.maxhushahn.com/upload/1111screenshot_6.png |
| 15:48:50 | Watusimoto | good question |
| 15:48:55 | Watusimoto | half white, have red? |
| 15:49:05 | raptor | ok |
| 15:49:17 | Watusimoto | just a guess |
| 15:49:35 | Watusimoto | so my robot patch relies on using ... in the function |
| 15:49:45 | Watusimoto | according to http://lua-users.org/wiki/OptimisingGarbageCollection, that triggers a table creation |
| 15:49:57 | Watusimoto | which the whole enterprise was designed to avoid |
| 15:50:07 | raptor | ugh |
| 15:52:43 | raptor | here is half/half for debris: http://sam686.maxhushahn.com/upload/111screenshot_7.png |
| 15:53:10 | raptor | looks better i think |
| 16:00:43 | Watusimoto | great |
| 16:08:09 | | BFLogBot - Commit ff2eaf6edff6 | Author: buckyballreaction | Log: Make Core panels be whitish again to be easier to see |
| 16:10:22 | Watusimoto | we could move some "standard" functions to the c++ side... like findClosestEnemy |
| 16:10:51 | raptor | that would be good |
| 16:16:55 | Watusimoto | the problem is we could come up with a large number of these functions, I imagine |
| 16:17:27 | raptor | oh yes, i'm sure... |
| 16:19:19 | Watusimoto | and when we have functions like this: |
| 16:19:28 | Watusimoto | local enemies = findItems(RobotType, TurretType, ShipType, AsteroidType, ForceFieldProjectorType, SpyBugType, CoreType) |
| 16:19:41 | Watusimoto | that essentially runs find 7 times |
| 16:19:54 | raptor | what? |
| 16:19:57 | Watusimoto | that was the benefit of the old flag system |
| 16:20:33 | Watusimoto | while(lua_isnumber(L, -1)) |
| 16:20:42 | Watusimoto | gridDB->findObjects(number, fillVector); |
| 16:20:48 | raptor | ah |
| 16:21:07 | raptor | i bet we could come up with a function that builds out a TestFunc for all those types on the fly |
| 16:21:13 | raptor | then a find would be only done once |
| 16:21:19 | Watusimoto | that's an interesting idea |
| 16:23:08 | Watusimoto | that would help a bit |
| 16:24:23 | Watusimoto | though not sure how to do that right off, unless we used some static gimickery |
| 16:25:48 | Watusimoto | prob something like: |
| 16:25:55 | raptor | i have an idea... |
| 16:26:27 | Watusimoto | testFunction.reset(); testFunction.add(typeNum1); testFn.add(typeNum2); |
| 16:26:31 | Watusimoto | yes |
| 16:26:34 | raptor | nah... |
| 16:26:35 | raptor | simpler |
| 16:27:00 | raptor | bool hasItem(Vector<U8> itemArray) |
| 16:27:07 | raptor | then a simple for loop inside |
| 16:27:31 | Watusimoto | we can't pass itemArry to the test function |
| 16:27:44 | Watusimoto | unless we had a second test function signature |
| 16:28:00 | raptor | doh |
| 16:28:03 | raptor | that's right... |
| 16:28:13 | Watusimoto | then I suppose we could pass itemAry to the findFunction, which could pass that off to the test function |
| 16:28:15 | Watusimoto | that would work |
| 16:28:25 | Watusimoto | that might be best |
| 16:28:55 | raptor | yeah |
| 16:30:21 | Watusimoto | we have 3 different finds that use testFunctions |
| 16:30:59 | raptor | i see two in gameObject |
| 16:31:09 | raptor | findObject and findObjectLOS |
| 16:31:12 | Watusimoto | we'd need to replicate |
| 16:31:13 | Watusimoto | void GridDatabase::findObjects(TestFunc testFunc, Vector<DatabaseObject *> &fillVector) |
| 16:31:29 | Watusimoto | and void GridDatabase::findObjects(TestFunc testFunc, Vector<DatabaseObject *> &fillVector, const Rect &extents) |
| 16:32:42 | Watusimoto | at least for this use |
| 16:33:06 | Watusimoto | I guess we wouldn't need to pass the testFunc at all, just the vector of types, and use a dedicated testFunc |
| 16:41:31 | raptor | i bet we could use preprocessor magic to dynamically build a TestFunc |
| 16:46:27 | raptor | that's what TNL does |
| 16:50:53 | Watusimoto | I wrote one that looks like this: |
| 16:51:11 | Watusimoto | bool GridDatabase::testTypes(const Vector<U8> &types, U8 objectType) const |
| 16:51:11 | Watusimoto | { |
| 16:51:11 | Watusimoto | for(S32 i = 0; i < types.size(); i++) |
| 16:51:11 | Watusimoto | if(types[i] == objectType) |
| 16:51:11 | Watusimoto | return true; |
| 16:51:11 | Watusimoto | return false; |
| 16:51:14 | Watusimoto | } |
| 16:52:10 | raptor | looks good |
| 16:52:19 | Watusimoto | can't get much simpler |
| 17:16:45 | raptor | Maybe I should start a new class: ShipShapes |
| 17:20:06 | Watusimoto | ok |
| 17:21:16 | raptor | I'm wondering if I can put all ship shapes into similar pieces: outerHull, innerHull, healthbarSize, flameports, etc... |
| 17:27:22 | Watusimoto | Maybe? |
| 17:27:38 | raptor | or i can just clutter up gameObjectRender more... |
| 17:31:58 | Watusimoto | testing |
| 17:32:03 | Watusimoto | render is already pretty cluttered |
| 17:32:11 | Watusimoto | anything you can do to clarify it will be good |
| 17:32:25 | Watusimoto | I'm not sure you can make it worse |
| 17:34:29 | raptor | hehe |
| 18:00:19 | Watusimoto | well... no discernable difference |
| 18:00:39 | Watusimoto | though my tests aer not very discerning |
| 18:00:55 | raptor | what are you testign? |
| 18:01:26 | Watusimoto | combinging multiple passes at finding items in the db into one |
| 18:01:43 | Watusimoto | probably because ships generally only search one database bucket |
| 18:01:53 | Watusimoto | so it's really not that inefficient to start with |
| 18:02:08 | raptor | make sense |
| 18:02:53 | Watusimoto | so I added complexity, not sure if I saved anything |
| 18:05:03 | Watusimoto | maybe I should revert... |
| 18:05:11 | Watusimoto | well, I'll think about it over dinner |
| 18:05:16 | Watusimoto | later |
| 18:05:16 | raptor | yum |
| 18:05:19 | raptor | and I, lunch |
| 18:05:21 | raptor | later |
| 18:10:25 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 18:57:23 | | Watusimoto has joined |
| 19:15:42 | raptor | good that norton took our request seriously |
| 19:20:48 | Watusimoto | we'll see |
| 19:23:11 | raptor | i guess that's true... |
| 19:25:58 | Watusimoto | well, so what should I do? |
| 19:26:09 | Watusimoto | I have my bot mods that I'm unsure about |
| 19:26:24 | raptor | well, we need performance |
| 19:26:26 | Watusimoto | I want you and/or sam to try them and see if you can discern any performance improvements |
| 19:26:33 | Watusimoto | if so, then great |
| 19:26:38 | raptor | ok |
| 19:26:48 | Watusimoto | if not, I'd rather revert because the old way was much simpler |
| 19:26:52 | Watusimoto | at least to my mind |
| 19:27:13 | Watusimoto | Can we revert a specific past checkin? |
| 19:27:25 | raptor | sure - hg can create a reverse diff |
| 19:27:31 | raptor | and then you just apply it |
| 19:27:43 | Watusimoto | ok, then I'll gather up all my scripting fixes and check it in all at once |
| 19:28:35 | raptor | are you saying that there still doesn't seem to be a difference compared to before you started all the LUA stuff? |
| 19:29:24 | Watusimoto | I can't really tell, as I don't have a good way to measure |
| 19:29:39 | Watusimoto | I've been looking at FPS with 100 bots on MadCow |
| 19:29:57 | Watusimoto | but that's a poor measure, in part because it jumps around a lot, depending on what's on screen |
| 19:30:08 | raptor | i can do some simple profiling |
| 19:30:12 | Watusimoto | let me try checking that again, trying to keep all bots off screen |
| 19:30:32 | raptor | how about running a dedicated, then hooking into it with another client? |
| 19:30:43 | Watusimoto | how would I measure then? |
| 19:30:50 | Watusimoto | fps is my only gauge |
| 19:31:10 | raptor | maybe put a logprint in the dedicated? |
| 19:31:51 | Watusimoto | maybe |
| 19:32:10 | Watusimoto | I wonder if running in the debugger slows things in release mode |
| 19:32:26 | raptor | it sure does |
| 19:32:31 | Watusimoto | in release mode? |
| 19:32:37 | raptor | anything in the debugger slows down |
| 19:32:37 | Watusimoto | in debug mode, yes |
| 19:32:46 | Watusimoto | well, I'll try running the exe |
| 19:33:01 | Watusimoto | outside of vc++ |
| 19:33:07 | Watusimoto | best possible case |
| 19:41:41 | Watusimoto | hard to say |
| 19:41:43 | raptor | ok, i profiled a dedicated server 10 secs with 100 bots on mad cow |
| 19:41:46 | Watusimoto | probably not worse performance |
| 19:44:01 | raptor | well, can you make a bundle I could import? (If you don't want to push) |
| 19:44:05 | raptor | hg bundle |
| 19:44:15 | raptor | a 'changegroup' |
| 19:45:52 | Watusimoto | here comes |
| 19:45:58 | Watusimoto | oops |
| 19:46:00 | Watusimoto | pushed |
| 19:46:20 | Watusimoto | you'll need the new lua scripts and the new s_bot |
| 19:46:29 | Watusimoto | to take full advantage |
| 19:46:30 | raptor | those are committed though? |
| 19:46:33 | Watusimoto | yes |
| 19:46:36 | raptor | in the resource dir |
| 19:46:37 | raptor | ok |
| 19:46:38 | Watusimoto | in the resources |
| 19:46:40 | Watusimoto | yes |
| 19:47:09 | Watusimoto | there is still lots to cleanup |
| 19:47:21 | Watusimoto | then I need to decide if we move that new Lua binder I showed you |
| 19:47:32 | Watusimoto | I hope it will be an easy transition from Lunar |
| 19:47:41 | raptor | did you make any changes to TNL? |
| 19:47:48 | Watusimoto | no |
| 19:47:51 | Watusimoto | don't think so |
| 19:47:54 | Watusimoto | to Rect |
| 19:48:01 | Watusimoto | but that's not TNL |
| 19:48:11 | raptor | ok |
| 19:48:24 | raptor | dedicated comiled... |
| 19:48:56 | raptor | client compiled.. |
| 19:49:03 | | BFLogBot - Commit 6d570a6c5b71 | Author: watusim...@bitfighter.org | Log: IntRect class |
| 19:49:05 | | BFLogBot - Commit a5b48f78280a | Author: watusim...@bitfighter.org | Log: Comment |
| 19:49:06 | | BFLogBot - Commit 6818d68229a7 | Author: watusim...@bitfighter.org | Log: Make IntRect members public |
| 19:49:08 | | BFLogBot - Commit 0d44d2ae9814 | Author: watusim...@bitfighter.org | Log: Reduce code duplication |
| 19:49:09 | | BFLogBot - Commit dc5b5b9f9b80 | Author: watusim...@bitfighter.org | Log: Add lunar to project |
| 19:49:11 | | BFLogBot - Commit 07639af112e0 | Author: watusim...@bitfighter.org | Log: Fix compile issue |
| 19:49:12 | | BFLogBot - Commit 8df6fc46b87f | Author: watusim...@bitfighter.org | Log: Fix warning |
| 19:49:14 | | BFLogBot - Commit a217b41693f9 | Author: watusim...@bitfighter.org | Log: Fix warning |
| 19:49:15 | | BFLogBot - Commit 34463e95d370 | Author: watusim...@bitfighter.org | Log: Scripts all share a single Lua instance |
| 19:49:17 | | BFLogBot - Commit 998f2cacf1cf | Author: watusim...@bitfighter.org | Log: Merge |
| 19:53:21 | | sam686 has joined |
| 19:53:22 | | ChanServ sets mode +v sam686 |
| 19:54:39 | raptor | well, sam686's levelgen doesn't work anymore... |
| 19:55:37 | Watusimoto | levelgens are probably all broken |
| 19:55:52 | Watusimoto | that's not a surprise, nor is it alarming |
| 19:56:01 | Watusimoto | it will be fixed |
| 19:56:17 | raptor | i have lots of profiled data, looks better |
| 19:56:18 | Watusimoto | focusing on bot performance and understanding how to improve the lua code |
| 19:56:23 | raptor | i will try the fps test, too... |
| 19:56:23 | Watusimoto | yes? |
| 19:56:30 | Watusimoto | performance or memory? |
| 19:59:49 | raptor | ok, well the FPS test says performance is worse... |
| 20:00:12 | raptor | it was ~10 fps with new code, ~13 with old |
| 20:03:55 | Watusimoto | ugh |
| 20:04:31 | raptor | but |
| 20:04:35 | raptor | i don't think it is a good metric |
| 20:04:43 | raptor | i just separated teh server and client |
| 20:04:52 | raptor | ran at 100 fps on the client |
| 20:05:02 | raptor | server was a separate process |
| 20:06:13 | Watusimoto | oh I see |
| 20:06:34 | raptor | ok, here is a ton of profile data: http://sam686.maxhushahn.com/upload/profiles.7z |
| 20:06:38 | Watusimoto | wait, how did you get 10 and 13? |
| 20:06:46 | Watusimoto | client in seperaet process? |
| 20:06:53 | raptor | the .out files are teh raw profiles |
| 20:06:55 | raptor | yes |
| 20:07:57 | Watusimoto | how can we guage performance? average the detlaTs on serverGame idle loop? |
| 20:08:14 | raptor | well... i have good raw profile data |
| 20:08:20 | raptor | i just need to know how to read it... |
| 20:09:03 | Watusimoto | looking now |
| 20:09:23 | Watusimoto | there are really 2 things we care about: cycles per second on server, and server memory usage |
| 20:09:54 | Watusimoto | base is 017a? |
| 20:10:00 | Watusimoto | new is my latest? |
| 20:10:01 | raptor | no |
| 20:10:09 | raptor | latest commit of mine before the merge |
| 20:10:17 | Watusimoto | is base |
| 20:10:23 | raptor | correct |
| 20:12:49 | Watusimoto | what program did you profile with? |
| 20:12:55 | raptor | gprof |
| 20:13:02 | raptor | maybe i should do callgrind, too... |
| 20:14:17 | Watusimoto | http://kprof.sourceforge.net/ |
| 20:14:57 | raptor | i ran a summary ananlysis... it's taking forever |
| 20:15:51 | raptor | i'll do callgrind... maybe gprof is lesser known.. |
| 20:16:22 | Watusimoto | I'm looking through the raw files, and well... there's a lot of info there |
| 20:17:24 | Watusimoto | finished the first 200 lines... only 126799 to go |
| 20:21:19 | raptor | ok, getting callgrind data... |
| 20:22:32 | Watusimoto | could you really have racked up 36M calls to getObjectTypeNumber in the time you were running? |
| 20:23:42 | raptor | i sat in a corner of madcow for 20 seconds, 10 seconds of which had 100 bots |
| 20:24:34 | raptor | ok, almost have callgrind data... |
| 20:27:05 | Watusimoto | what do you make of this line? |
| 20:27:06 | Watusimoto | 1.82 1.77 0.07 39258242 0.00 0.00 std::vector<Zap::DatabaseObject*, std::allocator<Zap::DatabaseObject*> >::size() const |
| 20:27:21 | Watusimoto | headers are |
| 20:27:22 | Watusimoto | % cumulative self self total |
| 20:27:22 | Watusimoto | time seconds seconds calls ms/call ms/call name |
| 20:27:28 | raptor | 39M calls to size() |
| 20:27:29 | raptor | ? |
| 20:27:35 | Watusimoto | ah, to size |
| 20:27:36 | Watusimoto | good |
| 20:27:44 | Watusimoto | thinking that was constructor for a second |
| 20:27:46 | Watusimoto | rats |
| 20:27:56 | Watusimoto | probably can't get rid of those calls |
| 20:28:16 | | koda has joined |
| 20:28:29 | Watusimoto | findObjects still seems to be our heavy spender |
| 20:28:37 | Watusimoto | probably because bots call it so often |
| 20:28:50 | Watusimoto | possible savings from caching |
| 20:28:52 | raptor | raw callgrind data: http://sam686.maxhushahn.com/upload/callgrind.7z |
| 20:28:57 | raptor | you'll need a view for sure |
| 20:29:00 | raptor | viewer |
| 20:29:18 | Watusimoto | or perhaps from running bots every 2nd frame when things get slow |
| 20:30:51 | Watusimoto | how did memory look for you btwn base and new? |
| 20:32:10 | raptor | retesting... |
| 20:32:22 | raptor | base: 64.7 MB |
| 20:34:43 | raptor | new: ~26 |
| 20:34:48 | raptor | but there is a memory leak |
| 20:35:06 | raptor | wait... |
| 20:35:09 | raptor | maybe it stabilized |
| 20:35:30 | raptor | new: 29.4 MB |
| 20:35:51 | raptor | it stabilized... just took a little longer... |
| 20:36:26 | Watusimoto | well, that's something |
| 20:36:34 | Watusimoto | much better results than I was showing |
| 20:36:52 | raptor | well, i was doing dedicated_server only |
| 20:37:03 | Watusimoto | but still... 50% reduction |
| 20:37:11 | Watusimoto | more what we were expecting |
| 20:37:37 | Watusimoto | probably a lot of why 100 bots is slow is because there are so many interactions |
| 20:37:46 | Watusimoto | so many bullets, so many things that are not bot specific |
| 20:38:08 | raptor | those callgrind dumps should tell us a lot more... but i can't seem to find a viewer for windows unless you install KDE |
| 20:38:37 | raptor | http://sourceforge.net/projects/precompiledbin/files/kcachegrind.zip/download |
| 20:38:46 | raptor | ^^ there is windows precompiled kcachegrind |
| 20:38:59 | Watusimoto | have it |
| 20:39:05 | raptor | ohg ood |
| 20:42:41 | raptor | wow, the sha256 function sure takes a lot... |
| 20:44:19 | | LordDVG Quit (Quit: Leaving) |
| 20:45:22 | raptor | neat! |
| 20:45:32 | raptor | you can see which dynamic casts are taking up the most |
| 20:45:39 | raptor | with the callgrind data |
| 20:45:44 | raptor | in kcachegrind |
| 20:47:12 | Watusimoto | where? |
| 20:47:47 | raptor | sort by 'Self' on teh left nav |
| 20:48:01 | raptor | then select one of the most expensive 'cycle..' |
| 20:48:12 | raptor | like 'cycle 6' |
| 20:48:19 | Watusimoto | isturrettargettype is our 2nd most called fn??!? |
| 20:48:37 | raptor | then click the 'Call Graph' in the bottom tab of the viewer |
| 20:48:42 | raptor | what |
| 20:49:01 | Watusimoto | crash! |
| 20:51:09 | Watusimoto | sort by called column |
| 20:51:18 | raptor | on new or base? |
| 20:52:20 | raptor | our most expensive dynamic_casts: http://sam686.maxhushahn.com/upload/11snapshot10.png |
| 20:52:35 | raptor | oops, that was in 'base |
| 20:53:27 | Watusimoto | we do do this a lot: dynamic_cast<GameType*>(theObject) |
| 20:53:46 | Watusimoto | if we made databaseObject instantiable, we could make those into static_casts |
| 20:55:56 | raptor | our most expensive dynamic_casts (in 'new'): http://sam686.maxhushahn.com/upload/11snapshot11.png |
| 20:58:03 | Watusimoto | do you read this as 25% of the time we're caluclating sha values?? |
| 20:58:14 | raptor | hehe, yep |
| 20:58:18 | raptor | well... cpu time |
| 20:58:34 | Watusimoto | Most of those dynamic casts are database_objects |
| 21:00:19 | raptor | if you look at cycle 6 |
| 21:00:37 | raptor | which is the most expensive next to sha methods |
| 21:07:40 | Watusimoto | we could use c-style casts where we are sure of the type |
| 21:08:02 | raptor | doesn't that try a succession of casts? |
| 21:08:40 | raptor | neat page: http://trac.caspring.org/wiki/LuaPerformance |
| 21:11:58 | Watusimoto | I thought it just did it, regardless of anything |
| 21:12:04 | Watusimoto | letting you shoot yourself in the foot |
| 21:13:51 | raptor | i thought they try successively less restricitve casts until it finds one that works |
| 21:18:18 | Watusimoto | interesting |
| 21:19:03 | Watusimoto | http://cboard.cprogramming.com/faq-board/86924-faq-difference-between-c-cplusplus-style-casting.html |
| 21:21:32 | Watusimoto | maybe we can do the assert with dynamic_cast, then c-cast for speed |
| 21:29:47 | raptor | "every cast is a potential design problem" |
| 21:29:54 | raptor | makes me feel good |
| 21:34:39 | raptor | i have a thought |
| 21:34:54 | raptor | what about actually reducing the bot object finds? |
| 21:35:21 | raptor | like have each bot do a main objective that can only be changed every 1/2 second |
| 21:35:39 | raptor | so it isn't always checking for bullets everywhere... |
| 21:41:40 | Watusimoto | yes |
| 21:42:04 | Watusimoto | or just runnng the bot script every 2nd cycle |
| 21:42:23 | raptor | or even have a sleep? |
| 21:42:36 | raptor | no faster than 30 fps because humans aren't much faster |
| 21:42:51 | Watusimoto | yes, that would probably work |
| 21:42:59 | Watusimoto | and it's really easy |
| 21:43:14 | Watusimoto | just call ontick less frequently |
| 21:43:29 | Watusimoto | and don't reset the bot's move when we don't call ontick |
| 21:43:46 | Watusimoto | so it just continues forth on those missed cycles |
| 21:43:56 | Watusimoto | it would be very easy to test |
| 21:44:48 | Watusimoto | so do you think the bots are on the right track? |
| 21:44:56 | Watusimoto | i.e. move forward with new implementation? |
| 21:46:18 | raptor | yes |
| 21:46:20 | raptor | i do |
| 21:46:35 | raptor | i saw a noticeable decrease in function calls |
| 21:46:45 | raptor | but still can't reliably judge performance |
| 21:46:56 | raptor | but sam686's levelgen was broken... :) |
| 21:47:04 | Watusimoto | I know |
| 21:51:10 | raptor | so i was talking AI with the naev folks - they have a timer implemented with all their AI that doesn't execute the next task until it is zero |
| 21:51:24 | raptor | and adjust the timer according to the task the AI does |
| 21:51:41 | raptor | the call it a 'control tick' |
| 21:52:18 | raptor | and will only change the task on that timer |
| 21:52:57 | raptor | ok - i gotta go for a couple hours |
| 21:53:00 | raptor | be back later |
| 21:53:21 | | raptor Quit () |
| 23:46:04 | | raptor has joined |
| 23:46:05 | | ChanServ sets mode +o raptor |
| 23:46:25 | raptor | ok |
| 23:46:29 | raptor | so i've been thinking |
| 23:47:51 | raptor | should we have a default control tick of like 66 ms |
| 23:48:02 | raptor | and then a way to increase/decrease it with a function? |
| 23:48:41 | raptor | because it may be that the majority of our performance problems are just because we're dealing with a scripting language |
| 23:51:19 | | koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee) |
