| 00:00.16 | *** join/#bzflag bryjen (n=bryjen@2002:4cb1:b40f:0:0:0:0:1) |
| 00:00.16 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 00:01.52 | Epyon | Kay, time for a commit. |
| 00:02.58 | *** join/#bzflag Jefenry (n=Jefenry@pool-71-253-198-50.nrflva.east.verizon.net) |
| 00:03.17 | CIA-3 | BZFlag: 03chaos-dev * r14638 10/trunk/bzwgen/ (11 files): Refactored Zones to use inheritance instead of switches, to allow easier customization. Cleaned up some mess -_- |
| 00:05.40 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 00:08.45 | CIA-3 | BZFlag: 03chaos-dev * r14639 10/trunk/bzwgen/Makefile: Uh, the Makefile. Hope it's correctly updated, but I have no way to check that... |
| 00:10.17 | tannerld | bzwgen? |
| 00:10.40 | rtfm | random map generator |
| 00:10.53 | tannerld | ah |
| 00:11.02 | rtfm | and not random like the maps random maps we have now :) |
| 00:11.05 | rtfm | NICE random |
| 00:11.26 | tannerld | ooo |
| 00:11.47 | *** join/#bzflag spldart (i=haxor@c-76-30-111-23.hsd1.tx.comcast.net) |
| 00:12.01 | Epyon | rtfm, well, not yet -_- |
| 00:12.24 | rtfm | well, I'm more or less talking about the goal of the project |
| 00:12.33 | rtfm | not the current state of the code |
| 00:12.36 | Epyon | Although I guess it already *looks* better. |
| 00:13.37 | Epyon | tannerld, http://chaosforge.org/files/bzfi0006.png |
| 00:13.59 | tannerld | buildings? |
| 00:14.08 | Epyon | Yeah, why not? ;] |
| 00:14.14 | tannerld | heh |
| 00:14.23 | Epyon | Though they will look a lot nicer. |
| 00:17.44 | TD-Linux | will you generate different shapes of buildings? |
| 00:17.51 | TD-Linux | will the shapes of the buildings themselves be random? |
| 00:18.10 | Epyon | Yep, that's the plan, TD-Linux |
| 00:18.32 | Epyon | Though I'm still fighting with that on paper :P |
| 00:20.45 | *** join/#bzflag joeyk (i=1000@pdpc/supporter/active/zer0python) |
| 00:30.48 | *** join/#bzflag bz09 (n=4743702c@bz.bzflag.bz) |
| 00:34.13 | CIA-3 | BZFlag: 03chaos-dev * r14640 10/trunk/bzwgen/ (Zone.cxx Zone.h bzlgen.vcproj): Well, who needs Zone.cxx anyway? |
| 00:49.22 | CIA-3 | BZFlag: 03chaos-dev * r14641 10/trunk/bzwgen/GridGenerator.cxx: Cleanup, and added a little temporary twist with the zone generation. |
| 00:49.29 | brlcad | ~Epyon++ |
| 00:49.43 | Epyon | That is my 4th commit today :( |
| 00:49.51 | Epyon | This must be the record -_- |
| 00:50.48 | CIA-3 | BZFlag: 03chaos-dev * r14642 10/trunk/bzwgen/Makefile: Forgot to remove Zone.cxx from Makefile. Duh. |
| 00:50.58 | Epyon | brlcad, can you check the makefile? |
| 00:51.13 | Epyon | I did edits on it but have no way to check their correctness. |
| 00:52.28 | Rawk | hmm, bzflag svn trunk is giving me this compile error: *** No rule to make target `bzsignal.c', needed by `bzsignal.lo'. Stop. |
| 00:52.35 | Rawk | Any ideas? |
| 00:58.10 | brlcad | Rawk: you have to manually delete your .deps dirs |
| 00:58.20 | brlcad | unclean build through a file rename |
| 00:58.45 | brlcad | Epyon: yeah, I can |
| 01:00.02 | Rawk | ahh, yes a grep gives: "bzflag/src/common/.deps/bzsignal.Plo:bzsignal.lo: bzsignal.c ../../include/bzsignal.h /usr/include/signal.h \" |
| 01:01.31 | tannerld | brlcad: that .deb dir is in the bzflag source dir? |
| 01:02.31 | Rawk | hmm, it doesn't like me deleting the .debs in bzflag/src/common/ |
| 01:02.37 | Rawk | re ./configure ? |
| 01:04.32 | Rawk | ahh yes, that seem to have done the trick. |
| 01:10.05 | brlcad | because they're not .debs dirs |
| 01:10.14 | brlcad | they're .deps |
| 01:14.03 | *** join/#bzflag Pommes_ (n=Pommes@about/essy/frenchy/Pommes) |
| 01:18.57 | Epyon | Can passable be applied to whole mesh, or does it need to be applied to every face? |
| 01:37.21 | *** join/#bzflag Macrosoft|sleep (n=Macrosof@c-75-65-81-245.hsd1.la.comcast.net) |
| 01:38.52 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 01:46.39 | *** join/#bzflag Constitution (n=Constitu@72.24.124.7) |
| 01:48.09 | CIA-3 | BZFlag: 03chaos-dev * r14643 10/trunk/bzwgen/ (14 files): Created a clearer output system. |
| 01:48.41 | Epyon | Duh, that's it for today. Beer time -_- |
| 01:55.42 | Macrosoft|sleep | who is chaos-dev? |
| 01:56.09 | donny_baker | go ack to sleep... this is only a dream... |
| 02:00.19 | *** join/#bzflag The_Vaxorcist (n=phillip@dial-209-148-113-178.sonic.net) |
| 02:02.01 | brlcad | ~Epyon is chaos-dev. "Epyon" was taken. |
| 02:02.02 | ibot | brlcad: okay |
| 02:02.51 | Epyon | brlcad, shouldn't you tell the bot what chaos-dev is instead? xP |
| 02:04.58 | brlcad | ~chaos-dev is Epyon. "chaos-dev" wasn't taken. |
| 02:04.58 | ibot | brlcad: okay |
| 02:05.12 | Epyon | lol :P |
| 02:06.28 | The_Vaxorcist | Is anyone working on adding ogg support to bzflag? |
| 02:08.44 | L4m3r | I doubt it's much of a priority |
| 02:09.02 | L4m3r | seeing as what we have now seems to work OK |
| 02:09.22 | The_Vaxorcist | yeah, just wondering |
| 02:09.55 | The_Vaxorcist | I'm just bored, and feel like coding |
| 02:12.26 | *** join/#bzflag Rawk (n=unknown@203.109.185.128) |
| 02:12.47 | L4m3r | as they say, |
| 02:12.49 | L4m3r | ~pw |
| 02:12.50 | ibot | somebody said patches welcome was a common response by maintainers of Open Source products. It's roughly means "We don't have much time on our hands, so if you write that feature and send it to us we will likely roll it in. If you don't have the time to write it, we don't either. Stop asking for it." |
| 02:13.06 | L4m3r | submit it to SF and someone may bite :) |
| 02:13.25 | bryjen | ping DTRemenak |
| 02:13.42 | *** join/#bzflag TylerM (n=TylerM@osgeo/member/TylerM) |
| 02:14.41 | brlcad | The_Vaxorcist: if you feel like coding, there are probably more useful and interesting things you could be coding in bzflag ;) |
| 02:14.58 | bryjen | i can't get a freshly-built bzflag 2.1 to connect to my 2.1 bzfs. wonder how old DTR's 2.1 bzfs is... |
| 02:15.23 | brlcad | bryjen: i'm consistently having issues connecting to the latest bzfs |
| 02:15.36 | The_Vaxorcist | brlcad: like what? I'm curious. |
| 02:15.38 | brlcad | some bug introduced |
| 02:16.09 | brlcad | The_Vaxorcist: literally thousands of things, to single out any of them would be a disservice |
| 02:16.19 | brlcad | check out the RFE items, they're good starters |
| 02:16.43 | bryjen | the fixing of a thousand bugs begins with one patch ;) |
| 02:17.03 | bryjen | orsomethinglikethat |
| 02:17.13 | brlcad | yeah, feel free to fix the connection problems we're seeing :) |
| 02:17.15 | Rawk | hmm, does anyone have the current svn trunk bzflag working on their system? I'm getting a segfault on amd64 gentoo linux. |
| 02:17.36 | The_Vaxorcist | haha |
| 02:17.40 | brlcad | Rawk: works on mine, need way more info than that to be useful |
| 02:17.47 | daxxar | meh |
| 02:17.51 | daxxar | I've drunk too much today |
| 02:18.06 | daxxar | And I'm still sober enoug to type correctly and realize I need WATER. |
| 02:18.08 | brlcad | what's this "too much" you speak of... wierd |
| 02:18.11 | daxxar | (fail) |
| 02:18.39 | daxxar | I'm a small kid, and I've had 12 brews and three jack&cokes ;-) |
| 02:18.52 | daxxar | It's 4AM and I should've been to bed, sober and happy. |
| 02:19.02 | daxxar | So I can get over my coder's block tomorrow |
| 02:19.05 | daxxar | Really foggy outside |
| 02:19.07 | daxxar | Epyon: Hardly M |
| 02:19.09 | daxxar | Epyon: ;P |
| 02:19.34 | Rawk | brlcad: I'm getting "SceneRenderer::getGroundUV (this=0x0, p=0x7fff19f19f40, uv=0x7fff19f19f70) at SceneRenderer.cxx:518 Cannot access memory at address 0x7fff19f19e38" from a gdb backtrace. |
| 02:20.36 | *** join/#bzflag tuxd00d (n=tuxinato@128.187.178.113) |
| 02:20.36 | bryjen | my client work OK connecting to DTR's servers |
| 02:21.53 | Macrosoft | "patches welcome"? how does one submit a patch? |
| 02:23.10 | brlcad | Rawk: looks like someone called a method on a null object |
| 02:23.23 | brlcad | note the this=0x0 |
| 02:24.31 | Rawk | It seems to stop at "if (useQualityValue >= _HIGH_QUALITY)" in SceneRenderer.cxx http://rafb.net/p/lPEgo676.html |
| 02:25.54 | daxxar | AFAICT, sleep is a good plan. |
| 02:26.05 | daxxar | Good night, brlcad, sorry about the lack of progress lately. |
| 02:26.09 | daxxar | Good night, the rest of you! |
| 02:26.11 | brlcad | Rawk: it's a null pointer derefernce |
| 02:26.24 | brlcad | that's just the first datamember that gets dereferenced |
| 02:26.36 | brlcad | look at the backtrace |
| 02:26.45 | brlcad | it's a preceeding call |
| 02:31.49 | Rawk | hmm, well it's kinda over my head... |
| 02:36.54 | Rawk | I wonder why it calls a method on a null object for me, and not for others... |
| 02:39.49 | Rawk | maybe you don't have rev 14636? |
| 02:41.41 | Rawk | sorry, rev 14643. |
| 02:42.08 | CIA-3 | BZFlag: 03brlcad * r14644 10/branches/ftgl/src/other/ftgl/ (inc/FTCharmap.h src/FTCharmap.cpp): optimize FTCharmap::FontIndex() so that font indices < 128 are precomputed during instantiation so there's no repeated tt_cmap4_char_index() calls. performance is now really close to what it was. |
| 03:16.23 | *** part/#bzflag Macrosoft (n=Macrosof@c-75-65-81-245.hsd1.la.comcast.net) |
| 03:49.47 | *** join/#bzflag tuxd00d (n=tuxinato@128.187.178.113) |
| 04:32.14 | brlcad | Rawk: i'm up to date |
| 04:32.24 | brlcad | pastebin the backtrace |
| 04:32.35 | brlcad | it should be the preceeding call that's accessing null |
| 04:42.09 | Rawk | ok, as soon as I can. |
| 04:58.48 | *** join/#bzflag TimRiker (n=timr@rikers.org) |
| 04:58.48 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 05:06.45 | *** join/#bzflag Winny (n=BZ_Win_@CPE0016b6de59f3-CM000f9fac8236.cpe.net.cable.rogers.com) |
| 05:06.57 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 05:07.42 | Rawk | brlcad: this is all it seems to give me with gdb: http://pastebin.ca/629349 |
| 05:09.12 | Rawk | brlcad: but kdbg gives me more, but I can't copy/paste it :-( |
| 05:11.30 | Rawk | brlcad: the one after SceneRenderer::getGroundUV though, is BackgroundRenderer::buildGeometry |
| 05:12.30 | Rawk | brlcad: "at BackgroundRenderer.cxx:553" |
| 05:27.45 | CIA-3 | BZFlag: 03brlcad * r14645 10/trunk/bzflag/DEVINFO: don't need the trailing *** on the local var block |
| 05:34.47 | CIA-3 | BZFlag: 03brlcad * r14646 10/trunk/bzflag/src/bzflag/BackgroundRenderer.cxx: make sure lastRenderer isn't NULL earlier on in BackgroundRenderer::buildGeometry() to try and prevent a crash |
| 05:35.58 | Rawk | thx brlcad, I'll try now. |
| 05:42.30 | Rawk | brlcad: ok... that didn't work: http://pastebin.ca/629360 |
| 05:44.17 | CIA-3 | BZFlag: 03brlcad * r14647 10/trunk/bzflag/src/bzflag/BackgroundRenderer.cxx: should probably compile |
| 05:46.06 | Rawk | yeah it should be const |
| 05:46.38 | Rawk | no? |
| 05:48.09 | Rawk | ahha, that did it! |
| 05:48.22 | Rawk | thanks brlcad :-) |
| 05:49.08 | brlcad | np |
| 06:32.25 | *** part/#bzflag joeyk (i=1000@pdpc/supporter/active/zer0python) |
| 07:28.09 | CIA-3 | BZFlag: 03l4m3rthanyou * r14648 10/branches/gsoc_irc/bzflag/src/bzfs/ (ircControl.cxx ircControl.h): Woohoo, config reader is just about done. Now for the important junk... |
| 08:20.03 | Rawk | where can I find script files for bzrobots? |
| 11:00.52 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 11:56.25 | *** join/#bzflag KTL (n=KTL@kotnet-149.kulnet.kuleuven.be) |
| 12:32.47 | daxxar | Morning. |
| 12:37.29 | menotume | Afternoon |
| 12:39.28 | spldart | Morn |
| 13:05.26 | *** join/#bzflag Suspect (n=Suspect@68-114-71-106.dhcp.plt.ny.charter.com) |
| 13:59.57 | *** join/#bzflag SimonFlavelle (n=psychosi@CPE-124-179-245-82.vic.bigpond.net.au) |
| 14:00.14 | *** join/#bzflag Macrosoft (n=Macrosof@c-75-65-81-245.hsd1.la.comcast.net) |
| 14:04.15 | *** join/#bzflag PsycheTheGuy (n=psychosi@CPE-58-169-153-27.vic.bigpond.net.au) |
| 14:13.48 | *** part/#bzflag Macrosoft (n=Macrosof@c-75-65-81-245.hsd1.la.comcast.net) |
| 14:33.04 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 14:50.41 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 15:20.41 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 15:36.37 | CIA-3 | BZFlag: 03brlcad * r14649 10/branches/ftgl/ (include/TankGeometryMgr.h src/geometry/TankGeometryMgr.cxx): inline optimization for heavily called tank geometry routines |
| 15:47.03 | *** join/#bzflag poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 15:48.44 | spldart | what would cause constant "Error on MD5. Clearing offending file" on attempting to join servers? |
| 16:16.14 | Thumper_ | spldart: bad entry in your map cache maybe? maybe try clearing your cache? |
| 16:18.27 | spldart | Tried that but no change |
| 16:18.45 | spldart | It's only happening on the one machine though |
| 16:24.12 | spldart | Must be a corrupted build or install... It's starting to have bigger problems now. |
| 16:41.10 | blast007 | spldart: is your My Documents directory on a network location? |
| 16:44.10 | JeffM | or full? |
| 16:55.47 | brlcad | ahh, yay.. don't know how I caused it or how I fixed it, but fixed it is |
| 17:04.25 | *** join/#bzflag noyb (n=noyb@192.18.43.225) |
| 17:06.18 | CIA-3 | BZFlag: 03brlcad * r14650 10/branches/ftgl/src/Makefile.am: compile bzflag before bzrobots and bzadmin so the build can be halted early for frequent bzflag compilations |
| 17:06.45 | CIA-3 | BZFlag: 03brlcad * r14651 10/branches/ftgl/src/other/ftgl/inc/FTPoint.h: add inline keyword for stronger hinting |
| 17:07.16 | JeffM | brlcad, why don't you merge to mainline before you change too much? |
| 17:12.26 | *** join/#bzflag KTL (n=KTL@kotnet-149.kulnet.kuleuven.be) |
| 17:13.33 | brlcad | I'm still just doing simple optimizing |
| 17:13.54 | brlcad | really close to matching performance |
| 17:14.36 | brlcad | that's what I was stuck on all last night, spent hours trying to find a bug I introduced on optimizing the font manager |
| 17:15.07 | brlcad | the std::string's were coming up in the profile among a variety of other things, so I've been tweaking |
| 17:15.10 | JeffM | I can tell that |
| 17:15.13 | JeffM | do THAT in mainline |
| 17:15.22 | JeffM | no reason for it to be in a branch |
| 17:15.56 | brlcad | well, kinda, goes both ways |
| 17:16.31 | JeffM | we know it's a good thing, go for it |
| 17:16.33 | JeffM | :) |
| 17:16.35 | brlcad | the point of the branch was to test the new font system, and see how performance looks .. this is all just part of tweaking impl as part of that perf. eval |
| 17:16.50 | JeffM | the performance is close enough as is |
| 17:16.59 | brlcad | i will, i'm just about finished with all the tweaks i'm gonna do |
| 17:17.21 | brlcad | just this last batch of strings and I'll probably call it "done" |
| 17:34.14 | brlcad | when are bzdb cache variables updated (are they ever?) |
| 17:35.36 | JeffM | when they change |
| 17:35.47 | JeffM | the cache system installs a callback |
| 17:35.58 | JeffM | that gets the value from BZDB and updates the cache var |
| 17:36.20 | brlcad | hm, so why wouldn't be want to cache all variables |
| 17:36.30 | brlcad | other than the if table lookup time |
| 17:36.34 | JeffM | not all of them are called a lot |
| 17:36.42 | JeffM | and it's more memory to cache them |
| 17:36.54 | JeffM | so it's a work/benifit problem |
| 17:37.03 | brlcad | hmm |
| 17:37.09 | JeffM | the benifit from caching a var that is called a number of times per frame is huge |
| 17:37.13 | brlcad | sounds like it's something bzdb should be doing anyways |
| 17:37.17 | JeffM | the benifit from one that is called Once, is nothing |
| 17:37.30 | JeffM | bzdb dosn't know how the value is going to be used |
| 17:37.49 | JeffM | BZDB also keeps it all in a map based on keys that are strings |
| 17:38.02 | JeffM | a better way would be to keep int float and bool versions fo all data |
| 17:38.13 | JeffM | and give a unique ID to each item that is fast indexable |
| 17:38.22 | JeffM | then have those that want fast access to it, get and store the IDE |
| 17:38.24 | JeffM | ID |
| 17:38.33 | JeffM | but then you have more then one copy of the ID hanging around |
| 17:39.11 | JeffM | most vars are one shots, that ether only are setup once, or when they change |
| 17:39.29 | JeffM | but stuff like gravity, speed, etc.. those are cached out |
| 17:39.37 | JeffM | now THOSE I think should be pulled out of BZDB |
| 17:39.44 | JeffM | and applied to tank specific states |
| 17:39.52 | JeffM | so that we can change them on a per tank basis |
| 17:40.15 | JeffM | or per shot, for shot speed, etc.. |
| 17:40.32 | JeffM | </endrant> |
| 17:40.49 | brlcad | you could still have pershot/pertank along with such "global defaults/limits" |
| 17:41.09 | JeffM | if they are sent for ever tank, the client dosn't need "global" ones |
| 17:41.10 | JeffM | or defaults |
| 17:41.14 | JeffM | the server does |
| 17:41.21 | JeffM | but that's just server setup stuff then |
| 17:41.33 | brlcad | that'd be the point, you dont' need to send for every tank if 90% of the time it's the same value |
| 17:41.45 | JeffM | why not just send em every tank |
| 17:41.54 | brlcad | why send em every tank |
| 17:42.00 | JeffM | less logic on the client == good ;) |
| 17:42.07 | JeffM | then the client code is simpler |
| 17:42.20 | brlcad | well, the why not would be that it's more net chatter that really wasn't necessary |
| 17:42.23 | JeffM | it's just a dumb client that DRs based on the current state |
| 17:42.37 | JeffM | if it never cahgnes, it's sent once on first add |
| 17:42.42 | JeffM | so it's not realy more "chatter" |
| 17:43.05 | JeffM | if it changes a lot, then its' the same as using a default, cus then it wont' be the default all the time |
| 17:43.05 | brlcad | even once per add |
| 17:43.12 | JeffM | it's nothing |
| 17:43.23 | JeffM | your game tho, just my opion |
| 17:43.33 | brlcad | it's a trivial detail |
| 17:43.35 | JeffM | I prefer code that dosn't have to check more then one place for it's value |
| 17:43.41 | JeffM | just simpler to maintain |
| 17:43.51 | JeffM | having them per tank would open a lot of stuff |
| 17:44.02 | brlcad | i don't disagree with that latter |
| 17:44.12 | brlcad | having per tank and per shot would be great to have |
| 17:44.19 | JeffM | even if you didn't send the default out with add, the cleint then uses the db a lot less |
| 17:44.34 | JeffM | since it'd have to keep it's own per tank value, that it just sets from the default |
| 17:44.51 | JeffM | not reading it from the db every frame |
| 17:45.37 | brlcad | that was my point about the db, though -- it shouldn't have to read it from the db every frame regardless, or at least that 'overhead' could/should be a lot less without the need for the cache hack |
| 17:46.16 | brlcad | breaking out the data types would certainly help, among a bunch of other opts that come to mind |
| 17:47.10 | brlcad | the std::map lookup is a bit of a pig for such frequent access of arbitrary strings that need evaluating |
| 17:47.24 | brlcad | to be calling most any of them every frame |
| 17:51.04 | JeffM | yeah that's the bigest hog and the reason cache was made |
| 17:51.14 | JeffM | I'd like to see all the cache items made into per tank |
| 17:52.19 | brlcad | only a handful of them have to do with tank behavior |
| 17:52.23 | brlcad | most of them are hud related |
| 17:52.31 | brlcad | basically a wrapper around a global |
| 17:52.49 | brlcad | course I suppose that can be said for all bzdb items |
| 17:53.05 | Chestal | I once started on some niec templates to autoamtically have cache access for all the stuff in global.cxx, but the code got lost somehow |
| 17:53.45 | Chestal | also, the interdependencies of variables are not corectly covered at the moment |
| 17:54.12 | Chestal | i.e. when you change one var not all the necessary callbaks for th dependent vars would be called |
| 17:55.15 | brlcad | bzdb is a half-baked interpreter, could just embed a full interpreter and use that along with some caching system |
| 17:55.39 | Chestal | and I think one map lookup / frame is negligible, some of the cached vars have hundreds of accesses per frame I think |
| 17:55.42 | brlcad | tcl or lua or python or whatever could probably be munged to work well/better/enough |
| 17:58.50 | Chestal | what do we have now? only simple arithmetic expressions? |
| 18:05.03 | *** join/#bzflag BenUrban_ (n=benurban@unaffiliated/benurban) |
| 18:43.59 | *** join/#bzflag spldart (n=short_ci@c-76-30-111-23.hsd1.tx.comcast.net) |
| 19:49.11 | *** join/#bzflag zee011 (i=d5040bfc@gateway/web/cgi-irc/zeebrothers.net/x-dabe14895796ec84) |
| 20:08.23 | *** join/#bzflag KTL (n=KTL@kotnet-149.kulnet.kuleuven.be) |
| 20:10.52 | *** join/#bzflag zee518 (i=540c0dc1@gateway/web/cgi-irc/zeebrothers.net/x-1e3cd768d528229e) |
| 20:18.43 | CIA-3 | BZFlag: 03brlcad * r14652 10/branches/ftgl/src/other/ftgl/ (inc/FTFace.h src/FTFace.cpp): |
| 20:18.43 | CIA-3 | BZFlag: sneak a few more percentage points improvement depending on how many strings are |
| 20:18.43 | CIA-3 | BZFlag: being drawn by precomputing a kerning matrix for char-to-char progressions for |
| 20:18.43 | CIA-3 | BZFlag: each font face. makes FTFace::KernAdvance() really cheap at the expense of a |
| 20:18.43 | CIA-3 | BZFlag: little memory (64k per face). can be toggled via constructor too. |
| 20:27.42 | spldart | BlastJeffM> Linux and I just realized my filesystem has some corruption... gonna reboot -force checkdisk |
| 20:38.17 | CIA-3 | BZFlag: 03brlcad * r14653 10/branches/ftgl/src/other/freetype/Makefile: grumble grumble, need to gut their crummy build system.. |
| 20:53.09 | CIA-3 | BZFlag: 03brlcad * r14654 10/branches/ftgl/ (32 files in 5 dirs): |
| 20:53.09 | CIA-3 | BZFlag: profile showed a blip for new/delete of std::string's in the font manager, so |
| 20:53.09 | CIA-3 | BZFlag: convert getStringWidth and stripAnsiChars over to char arrays. no longer a blip |
| 20:53.09 | CIA-3 | BZFlag: on profile (though probably still pretty insignificant a gain if any). |
| 20:53.23 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 20:55.43 | CIA-3 | BZFlag: 03brlcad * r14655 10/branches/ftgl/src/bzflag/ControlPanel.cxx: hopefully aren't more ifdef windows sections that were missed |
| 20:57.31 | CIA-3 | BZFlag: 03brlcad * r14656 10/branches/ftgl/src/bzflag/ControlPanel.cxx: bah, again |
| 21:01.11 | *** join/#bzflag LongDon (n=LongDon@host-091-097-074-084.ewe-ip-backbone.de) |
| 21:29.32 | *** join/#bzflag spldart (n=short_ci@c-76-30-111-23.hsd1.tx.comcast.net) |
| 21:31.15 | *** join/#bzflag TD-Linux (n=TD-Linux@about/essy/indecisive/TD-Linux) |
| 21:32.57 | *** join/#bzflag F12 (n=ink@pD9EB49BD.dip.t-dialin.net) |
| 21:38.18 | *** join/#bzflag F12 (n=ink@pD9EB49BD.dip.t-dialin.net) |
| 22:16.50 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 22:43.16 | *** join/#bzflag [dmp] (n=dennis@koderen.dk) |
| 22:56.28 | *** join/#bzflag Klinnerson (n=Jim@ip72-220-147-9.sd.sd.cox.net) |
| 23:01.26 | delusional_ | very slow website, almost dead>>>> http://my.bzflag.org |
| 23:05.35 | AAA_awright | Not slow her |
| 23:05.49 | AAA_awright | Wait. Now it is. |
| 23:05.55 | AAA_awright | >_> |
| 23:06.06 | AAA_awright | Try mine: http://bzflag.redjacket.ws/index.php/serverlist |
| 23:06.53 | AAA_awright | I just fixed a bug so when the list server goes down it doesn't think all the servers listed also are off. (It still connects to servers when it can't get the list of them, for when the list server goes down) |
| 23:07.07 | AAA_awright | ... |
| 23:07.15 | AAA_awright | It doesn't work very well appearently. |
| 23:08.17 | AAA_awright | ~forummods |
| 23:08.17 | ibot | forummods are L4m3r DTRemenak Learner Blast TimRiker Bryjen donny_baker |
| 23:08.20 | AAA_awright | ping |
| 23:09.43 | AAA_awright | we need a ~serveradmins |
| 23:09.49 | AAA_awright | ~serveradmins |
| 23:10.24 | blast007 | wee, mysql is eating the CPU |
| 23:11.14 | spldart | ooops |
| 23:11.57 | spldart | Oh... thought my checkout was causing a problem |
| 23:12.08 | blast007 | nope, that's run at SF, spldart |
| 23:12.29 | blast007 | mysql is hovering at around 12 to 28% right now |
| 23:12.43 | AAA_awright | ~bigredbutton |
| 23:12.44 | ibot | blast007 the list server is down |
| 23:12.47 | spldart | one of the bzflag http's is bzflag.org according to ibot |
| 23:13.12 | spldart | I guess I don't understaned subversion |
| 23:20.22 | *** join/#bzflag DavidHKMrPowers (n=chatzill@unaffiliated/davidhkmrpowers) |
| 23:23.56 | Winny | blast007: how's the drupal skin coming? ;) |
| 23:26.03 | spldart | stupid rain causing stupid drop-outs in my stupid long haul wireless :( |
