| 00:20.36 | blast007 | "Major BZFlag 2.6 features: * New logo that says 2.6.0 * Changed source code formatting * HATS!" |
| 00:22.32 | apeman | shut up and take my money |
| 00:23.12 | Delusional | Hats?!?!?!?!? |
| 00:23.25 | Delusional | HATS! |
| 01:16.18 | *** join/#bzflag khonkhortisan (~kyle@c-50-132-81-139.hsd1.wa.comcast.net) |
| 02:49.54 | *** join/#bzflag JeffM__ (~JeffM@cpe-23-241-222-73.socal.res.rr.com) |
| 03:25.53 | apeman | if you run 10 clients is there a disproportionate contention/overhead compared to running 1 or 2? |
| 03:30.26 | JeffM__ | it'll make a pair of sockets per client |
| 03:31.21 | apeman | is that bad? |
| 03:31.25 | JeffM__ | and as you end up with more clients then you have cores, the system will be able to give them less cycles |
| 03:31.30 | JeffM__ | it's not bad, it's nessisary |
| 03:32.42 | apeman | im running 10 clients, the fact that theres a sleep(0.2) in the playing loop doesnt stop them from overall taking all the CPU |
| 03:33.09 | JeffM__ | .0 milliseconds? |
| 03:33.13 | JeffM__ | .2 I mean |
| 03:33.19 | apeman | when i run 1 client its 0% CPU most of the time, occasionally 25% (task manager granularity..) |
| 03:33.31 | apeman | TimeKeeper::sleep(0.2f); |
| 03:33.43 | JeffM__ | ahh it must take it in seconds |
| 03:33.53 | JeffM__ | .2 is a long time for a sleep |
| 03:33.58 | JeffM__ | that gives you a max of 5 fps |
| 03:34.10 | apeman | yes, i was seeing if it made any difference on CPU consumption |
| 03:34.31 | JeffM__ | you'd have to see what each one is doing |
| 03:34.40 | JeffM__ | what kind of CPU do you have? and how much ram? |
| 03:35.27 | apeman | i5, 4GB but about 2GB is used by other stuff |
| 03:35.39 | JeffM__ | you should be fine to do that many processes then |
| 03:36.38 | apeman | i also replaced almost all the gl calls with {} |
| 03:37.26 | JeffM__ | you can probalby just not call some of the high level drawing stuff to |
| 03:37.36 | JeffM__ | so it doen't iterate the world and try to draw stuff |
| 03:38.05 | apeman | Sleepy says a lot of time is spent in BZDBCache::ReadOnly<float>::operator float |
| 03:38.18 | JeffM__ | yeah we do that a lot |
| 03:38.27 | JeffM__ | that's the bzdb evals |
| 03:38.41 | JeffM__ | a lot of the drwing code evals that |
| 03:38.52 | JeffM__ | thats why you should probably not call things like the world drawing sub |
| 03:38.55 | JeffM__ | or the player drawing sub |
| 03:40.42 | apeman | it reckons almost all the time in one of the threads is spent in Player::updateJumpJets(float dt) |
| 03:41.01 | apeman | which just does BZDB.eval(StateDatabase::BZDB_WINGSJUMPVELOCITY); and BZDBCache::gravity |
| 03:41.02 | JeffM__ | that doesn't seem right |
| 03:41.07 | JeffM__ | you are stuck in a loop |
| 03:41.14 | JeffM__ | you don't even need to call that stuff |
| 03:45.06 | apeman | well the bots are playing, and they do look like low FPS |
| 03:47.00 | apeman | i profiled 2 more times. One of the threads is sleeping most of the time; it consumes very little CPU consistently |
| 03:47.21 | apeman | another one has a more sensible looking profile |
| 03:48.07 | apeman | BZDBCache::update takes 59% of the time, TrackMarks::update takes 20% |
| 03:48.32 | JeffM__ | maybe they are fighting over the conrig |
| 03:48.34 | JeffM__ | config |
| 03:49.49 | apeman | which config? The data folder or the config file? |
| 03:49.57 | JeffM__ | ether |
| 03:50.10 | JeffM__ | but the bzdb stuff is tied to the config file |
| 03:51.37 | apeman | i could try having a separate datafolder and config file for each of them |
| 03:52.09 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:52.20 | JeffM__ | you are in unknown terriotory now :) |
| 03:52.33 | JeffM__ | it was never designed to do what you are doing |
| 04:10.17 | apeman | my experiment does not show a significant result in the difference in CPU consumption |
| 04:11.29 | apeman | just in case, does it make a difference that im running the client in cygwin? |
| 04:30.29 | JeffM__ | oh god |
| 04:30.48 | JeffM__ | you are way out there |
| 04:51.29 | apeman | i didnt compile it in cygwin, just running the .exe in cygwin cos batch syntax looks scary |
| 04:55.57 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 05:45.49 | BulletCatcher | Anyone who is motivated to do development (even if it just whitespace) should feel free to do so on the bzflag-import-3 repo. |
| 05:46.49 | BulletCatcher | Just be sure to choose the branch (v2_4_x or v2_6_x) wisely, because it is efficient and trivial to merge changes from 2.4 onto 2.6 but not the reverse. |
| 05:47.58 | JeffM__ | what is the master branch? |
| 05:48.35 | JeffM__ | well the thing called "master" |
| 05:48.36 | BulletCatcher | The master branch basically just has a README that says to use one of the other branches. |
| 05:48.41 | JeffM__ | oh |
| 05:48.42 | JeffM__ | eww |
| 05:52.29 | BulletCatcher | Past experience shows that we often have 2 open branches (current release and future incompatible), and this naming convention keeps us from having to change "trunk" or "master" from one to the other. |
| 05:53.16 | JeffM__ | sure |
| 05:53.23 | JeffM__ | I understand why, it's just eww |
| 05:56.23 | BulletCatcher | We could simply have no "master" branch at all, but this should be less confusing to people who are familiar with that Git convention. |
| 05:57.09 | JeffM__ | or name the breaking one "Development", but we'll see how it goes |
| 05:59.37 | BulletCatcher | Git is perfectly happy to have two names for the same branch, but it might be challenging to keep both names at the tip. |
| 05:59.59 | JeffM__ | well I'd not give the dev one a numbered name |
| 06:00.11 | JeffM__ | since as we saw with 3.0, the code may not be released as the number we wanted |
| 06:01.09 | JeffM__ | but your method is fine as any other |
| 06:01.38 | JeffM__ | the name of the branch should not get in the way of any work that may hapen |
| 06:02.10 | BulletCatcher | I would hope not. :-) |
| 06:02.48 | BulletCatcher | We could call the development branch v2_5_x, which matches the actual version number in the code, and then start a new v2_6_x branch from it only if we really release 2.6. |
| 06:03.38 | JeffM__ | that would be more in line with what I am used to |
| 06:03.46 | JeffM__ | but it matters not |
| 06:03.56 | JeffM__ | tis just my opinon and that should have little weight |
| 06:19.05 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 07:14.45 | *** join/#bzflag meeba (~lamer@c-75-71-23-204.hsd1.co.comcast.net) |
| 07:26.21 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 08:12.53 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 08:52.40 | *** join/#bzflag infobot (~infobot@rikers.org) |
| 08:52.40 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/d306gE |
| 08:52.40 | *** mode/#bzflag [+o infobot] by ChanServ |
| 08:53.47 | *** join/#bzflag infobot (~infobot@rikers.org) |
| 08:53.47 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/d306gE |
| 08:53.48 | *** mode/#bzflag [+o infobot] by ChanServ |
| 09:01.20 | *** join/#bzflag infobot (~infobot@rikers.org) |
| 09:01.20 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/d306gE |
| 09:01.21 | *** mode/#bzflag [+o infobot] by ChanServ |
| 14:12.51 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:36.33 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 15:29.12 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 15:29.12 | *** mode/#bzflag [+v joevano] by ChanServ |
| 16:24.15 | BulletCatcher | allejo, the new parsing ignores just a host name, as in "bzflag localhost" |
| 16:31.44 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 16:31.44 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 17:03.28 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 17:49.53 | *** join/#bzflag JeffM_ (~JeffM@107.209.61.105) |
| 18:40.16 | allejo | Ohhh... didn't realize that was an option also |
| 18:40.21 | allejo | on it |
| 18:48.52 | allejo | errr http://www.dslreports.com/forum/r28168664-Getting-qSyntax-error-Unterminated-quoted-stringq-on |
| 18:49.04 | allejo | this issue still exists |
| 18:51.50 | allejo | apparently it doesn't like paths with spaces in them |
| 18:57.41 | BulletCatcher | That's an odd place for such a bug report, but "don't use spaces in your path" is still the workaround. |
| 18:59.06 | apeman | so sad no spaces :( |
| 18:59.15 | allejo | it is an odd place, it was the first result on google |
| 19:24.35 | BulletCatcher | Maybe brlcad will fix it upstream. |
| 20:14.05 | *** part/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 20:33.06 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 20:40.22 | brlcad | never even heard about that issue, I'll take a look |
| 22:01.45 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 22:36.40 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:53.34 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |