| 00:05.04 | *** join/#bzflag Saturos (n=Saturos@p57A0CA07.dip.t-dialin.net) |
| 00:05.34 | *** join/#bzflag Saturos (n=Saturos@p57A0CA07.dip.t-dialin.net) |
| 00:13.04 | *** part/#bzflag ndim (i=hun@foobar.n-dimensional.de) |
| 00:25.49 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 00:27.04 | *** join/#bzflag Tedius (n=Tedius@adsl-76-205-107-200.dsl.bcvloh.sbcglobal.net) |
| 00:31.00 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 00:35.49 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 00:44.02 | JeffM | cbg? |
| 00:44.54 | CBG | JeffM: I decided to post my question on the bzbb instead, as a reply to the Map Licences post. |
| 00:45.10 | JeffM | you can restrict it to be no mod as well |
| 00:45.16 | JeffM | you just can't restrict who uses it |
| 00:46.22 | CBG | Ok, great. Thanks JeffM! |
| 00:46.48 | JeffM | the point is to prevent "you can use it but I have to be admin" |
| 00:46.53 | JeffM | or "only use with my permission" |
| 00:47.03 | CBG | Yeah, that's what I thought, I was just wanting to clarify. |
| 00:48.15 | CBG | :) See anything good? |
| 00:48.19 | JeffM | yes |
| 00:48.25 | JeffM | one was hella big |
| 00:48.31 | JeffM | 1200 sq. ft |
| 00:48.33 | CBG | My bro's looking for a house atm, not much luck considering his price range. |
| 00:48.35 | CBG | wow |
| 00:49.26 | JeffM | looks like I'll have to swap to cable tho :( |
| 00:52.56 | BZ_Win | the stone ages :p |
| 00:55.33 | JeffM | it'll take me from a 120 month bill for TV/net/phone to a 70$ a month bill for TV and net |
| 00:57.27 | JeffM | not bad for 2 DVRs and what they call 8meg down 512k up service |
| 00:59.35 | CBG | do you need much more than that (8Mbps/512Kbps)? |
| 00:59.46 | JeffM | probalby not |
| 00:59.50 | Constitution | "what they call"... I like that |
| 00:59.57 | JeffM | can save 10 if I go down to "4 megs" |
| 01:02.36 | JeffM | the page does say that some area's would have it as 10M/1M |
| 01:03.02 | JeffM | landlords will be pissed when I move, they will loose TV |
| 01:06.22 | JeffM | and I loose that loverly Tivo inerface :( |
| 01:17.13 | *** join/#bzflag Winny (n=BZ_Win_@CPE0016b6de59f3-CM000f9fac8236.cpe.net.cable.rogers.com) |
| 01:24.44 | Winny | rolling backouts... bbl |
| 02:02.00 | *** join/#bzflag Pommes_ (n=Pommes@about/essy/frenchy/Pommes) |
| 02:02.12 | *** join/#bzflag Rawk (n=unknown@203.109.176.242) |
| 02:02.48 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 02:33.27 | blast007 | brlcad: you around? |
| 02:42.07 | brlcad | nope |
| 02:46.03 | *** join/#bzflag zee737 (i=4792a928@gateway/web/cgi-irc/zeebrothers.net/x-301c23dddf7f7170) |
| 02:58.09 | *** join/#bzflag rob1n (n=emp@unaffiliated/rob1n) |
| 02:58.11 | blast007 | brlcad :) |
| 02:58.40 | blast007 | should I just commit the new list in a subfolder for now? It's multiple files |
| 02:59.37 | blast007 | figure I can 'svn mv' it when it's finished |
| 03:07.55 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 03:10.20 | *** join/#bzflag Suspect_1 (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 03:19.29 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) [NETSPLIT VICTIM] |
| 03:23.02 | *** join/#bzflag QuantumBeep (n=QuantumB@doc-24-32-46-104.leesville.la.cebridge.net) |
| 03:29.39 | brlcad | blast007: yeah, the where isn't so critical as it can be moved .. but I'd think probably either a dir in misc/ or in src/ |
| 03:30.09 | blast007 | the list server is currently located in the db/ "module" |
| 03:30.36 | brlcad | ah, that's right .. hm |
| 03:32.05 | brlcad | okay, so same thing but in db module .. if it's multiple files, then it probably should be organized into a dir by itself |
| 03:32.10 | brlcad | regardless of the module |
| 03:48.58 | *** join/#bzflag rob1n_ (n=rob1n@63-228-107-102.tukw.qwest.net) |
| 04:11.10 | *** join/#bzflag kierra (i=4a5f4dc1@gateway/web/cgi-irc/zeebrothers.net/x-dd1ac3ee9ab4c044) |
| 04:11.39 | *** part/#bzflag kierra (i=4a5f4dc1@gateway/web/cgi-irc/zeebrothers.net/x-dd1ac3ee9ab4c044) |
| 04:27.40 | *** join/#bzflag The_Interigator (n=bldfreak@ool-45770c9b.dyn.optonline.net) |
| 04:27.42 | The_Interigator | Salve. |
| 04:32.50 | *** join/#bzflag jude- (n=jude@c-68-84-206-92.hsd1.az.comcast.net) |
| 04:32.51 | jude- | hello all |
| 04:33.02 | a_meteorite | hi jude- |
| 04:35.22 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 04:39.40 | tannerld | hi JeffM |
| 04:39.42 | tannerld | err.. |
| 04:39.52 | tannerld | hi jude- :P |
| 04:40.27 | jude- | lol |
| 04:40.41 | JeffM | heh |
| 04:41.15 | jude- | last time I was here, we had a raging debate about which widget set, GTK or Qt, was better |
| 04:41.22 | jude- | did it reach a conclusion? |
| 04:41.39 | JeffM | use what you want :) |
| 04:41.52 | JeffM | better is to subjective a term |
| 04:41.52 | jude- | JeffM: tried that, but no one except me wants to use FLTK :( |
| 04:42.18 | jude- | so I'm changing course for the greater good |
| 04:42.18 | JeffM | then that is ALL that matters |
| 04:42.34 | JeffM | will it slow you down? |
| 04:42.38 | jude- | I dunno |
| 04:42.50 | JeffM | do you know FLTK better? and are there any HUGE reasons not to use it? |
| 04:42.59 | JeffM | other then people saying "GTK is better!!!!!" |
| 04:42.59 | jude- | "it's minimal and ugly" |
| 04:43.03 | JeffM | it is ugly |
| 04:43.06 | JeffM | I'll give it that |
| 04:43.13 | JeffM | but you ain't going for fancy |
| 04:43.17 | JeffM | your goin for functional |
| 04:43.22 | JeffM | will it do what you need/want ? |
| 04:43.31 | jude- | I hope so |
| 04:43.37 | JeffM | hope or know? |
| 04:43.47 | JeffM | changing in the middle will suck |
| 04:43.57 | jude- | I'm not sure whether or not I'll need multithreading outside what the widget set will provide |
| 04:44.09 | jude- | FLTK doesn't provide an abstract thread class; GTK and Qt do |
| 04:44.10 | JeffM | why will you need threading in an editor? |
| 04:44.29 | JeffM | it's not going to be comutationaly intesive |
| 04:44.37 | JeffM | and if it is, it's not going to be a background task |
| 04:44.52 | JeffM | so who cares if the main edit thread is blocked with a "working" progress bar? |
| 04:45.18 | jude- | threading is one of the approaches I considered when thinking about how to render texture matrices and dynamic colors |
| 04:45.25 | JeffM | overkill |
| 04:45.31 | JeffM | BIG TIME |
| 04:45.35 | jude- | heh |
| 04:45.36 | JeffM | will it do the rest of it? |
| 04:45.44 | JeffM | don't overthink your project, or you'll never finish |
| 04:46.03 | JeffM | if you want to do those threads later, you can use a thread lib |
| 04:46.14 | JeffM | no need to tie that to the widget set |
| 04:46.23 | JeffM | will it do the rest of it? |
| 04:46.31 | jude- | will FLTK do the rest of it? |
| 04:47.02 | jude- | FLTK for me is fine |
| 04:47.07 | JeffM | the rest if your UI |
| 04:47.09 | JeffM | then use it |
| 04:47.14 | JeffM | do what your familar with |
| 04:47.28 | JeffM | it'll have an ugly widet set |
| 04:47.35 | JeffM | hell the current one has an ugly widet set |
| 04:47.38 | JeffM | cus it's WINDOWS |
| 04:47.43 | JeffM | at least it'll be functionl |
| 04:47.49 | a_meteorite | yeah, no offense, and I'd like to see something done better than quick, but FLTK is ugly... |
| 04:47.59 | JeffM | who cares? |
| 04:48.01 | JeffM | it's an editor |
| 04:48.03 | a_meteorite | I know |
| 04:48.04 | JeffM | not itunes |
| 04:48.06 | JeffM | you'll live |
| 04:48.15 | a_meteorite | just saying... if there's a choice :) |
| 04:48.23 | JeffM | there are lots of choices |
| 04:48.34 | JeffM | and they must be weighted on what's important |
| 04:48.44 | JeffM | FTGL draws the same on all OSs |
| 04:48.48 | JeffM | and is super lightweight |
| 04:48.56 | JeffM | it also draws INSIDE GL |
| 04:49.07 | a_meteorite | right, that's why I said I'd rather have something better than quick |
| 04:49.11 | jude- | purple_cow: any thoughts? |
| 04:49.20 | JeffM | he'll say GTK |
| 04:49.23 | jude- | I know |
| 04:49.25 | a_meteorite | if FLTK works, sure. I'm just commenting that it is a tad ugly compared to GTK or Qt :) |
| 04:49.26 | JeffM | but that's a loaded question |
| 04:49.41 | JeffM | it's not like HE'LL ever maintain the editor |
| 04:49.45 | purple_cow | haw |
| 04:50.06 | JeffM | so no mater what anyone who maintains it will ahve to learn the widegts |
| 04:50.06 | jude- | JeffM: see why I'm considering changing the widget set while the project's young? I'll be putting up with this all summer :) |
| 04:50.18 | JeffM | GTK is harder to build on windows |
| 04:50.26 | purple_cow | I think you should choose one and stick to it |
| 04:50.28 | JeffM | IIRC it's also "iffy" on th emac |
| 04:50.38 | JeffM | never did QT |
| 04:50.41 | purple_cow | FLTK makes integration very easy |
| 04:50.43 | JeffM | I'd go with what you know |
| 04:50.45 | JeffM | it does |
| 04:50.53 | JeffM | I was able to build FLTK easy |
| 04:51.25 | jude- | a_meteorite: how do you define "ugly"? |
| 04:51.42 | a_meteorite | doesn't try to fit into OS conventions whatsoever |
| 04:51.47 | a_meteorite | but neither does any GUI toolkit |
| 04:51.49 | a_meteorite | so it's moot |
| 04:51.49 | JeffM | it's ugly cus it's a booring widet set |
| 04:51.55 | JeffM | a_meteorite, some do |
| 04:52.04 | JeffM | is FLTK skinable? |
| 04:52.05 | jude- | wxWidgets does, IIRC |
| 04:52.06 | a_meteorite | well, I'm not much of a GUI programmer :) |
| 04:52.09 | jude- | JeffM: dunno |
| 04:52.13 | jude- | not officially |
| 04:52.18 | jude- | but you can use images for buttons |
| 04:52.21 | jude- | and whatnot |
| 04:52.26 | JeffM | k |
| 04:52.29 | JeffM | it'll work |
| 04:52.42 | JeffM | and the sceeenshots for docs will be the same for all OSs |
| 04:52.48 | jude- | but it has no concept of themes |
| 04:52.55 | jude- | heh--tis true :) |
| 04:53.01 | a_meteorite | that's good |
| 04:53.03 | a_meteorite | makes docs easy |
| 04:53.03 | JeffM | if somone complains that much later, they can redo the UI in there fav TK later |
| 04:53.13 | JeffM | go with what you know |
| 04:53.33 | JeffM | the current most used editor uses a toolkit that everyone in the project hates |
| 04:53.46 | jude- | BZEdit? |
| 04:53.47 | JeffM | FLTK is leauges better then it |
| 04:53.50 | JeffM | yeah |
| 04:53.53 | JeffM | MFC :) |
| 04:54.05 | jude- | BZEdit isn't *that* bad... |
| 04:54.12 | JeffM | look at it's code |
| 04:54.15 | JeffM | for the windows one |
| 04:54.18 | jude- | oh |
| 04:54.22 | JeffM | port that sucker to any other platform ;) |
| 04:54.24 | jude- | haven't seen that yet |
| 04:54.29 | JeffM | noone uses the nix one |
| 04:54.42 | jude- | ...and that's the one I looked at |
| 04:54.46 | jude- | go figure ;) |
| 04:54.46 | a_meteorite | I haven't actually seen or heard of anyone getting the nix one to work |
| 04:54.55 | tannerld | i tried; its out of date |
| 04:55.01 | JeffM | few can get it to compile |
| 04:55.24 | JeffM | I said FEW |
| 04:55.28 | JeffM | not nobody |
| 04:55.33 | JeffM | you are one of the few |
| 04:55.35 | JeffM | the proud |
| 04:55.43 | purple_cow | a_meteorite did |
| 04:55.49 | a_meteorite | I did? |
| 04:55.55 | jude- | lol |
| 04:55.55 | JeffM | the people that put default params in method bodys |
| 04:56.26 | JeffM | did that ever get put as part of the C++ standard? |
| 04:56.49 | jude- | dunno, but it works with GCC and MinGW, IIRC |
| 04:57.16 | jude- | so, for our purposes, it might as well be in the standard :) |
| 04:57.30 | JeffM | that dosn't mean it's C++ standard |
| 04:57.38 | jude- | it's "de facto" standard |
| 04:57.41 | JeffM | GCC has it's set of C++ extensions, just as VC does |
| 04:58.25 | jude- | de facto standards still carry weight |
| 04:58.36 | jude- | look at all the windows "standards" for example |
| 04:58.49 | jude- | few are truly standard |
| 04:58.53 | JeffM | you can't call it "de facto" just cus you like the OSs it works on ;) |
| 04:59.02 | JeffM | I mean for OSs, then windows is the defacto |
| 04:59.08 | JeffM | so that makes the MS one defacto |
| 04:59.14 | JeffM | it's an extension |
| 04:59.21 | jude- | I'm calling it "de facto" because I haven't come across an instance yet where default params refused to compile |
| 04:59.22 | JeffM | deal with it ;) |
| 04:59.33 | JeffM | in the decleration? |
| 04:59.37 | jude- | that, and I see it a lot in textbooks |
| 04:59.38 | JeffM | not the definition? |
| 04:59.43 | JeffM | not the header |
| 04:59.46 | JeffM | the cpp |
| 04:59.52 | jude- | i.e. void foo(int param = 0) { /* code */ } |
| 04:59.55 | JeffM | the header is part of the C++ standard |
| 04:59.57 | JeffM | yeah |
| 05:00.01 | JeffM | is that standard? |
| 05:00.03 | JeffM | VC dosn't do that |
| 05:00.06 | JeffM | or didn't |
| 05:00.07 | jude- | I'm not sure |
| 05:00.11 | JeffM | I havent' tried it in a while |
| 05:00.22 | JeffM | if it's in a header then yeah |
| 05:01.02 | JeffM | but if you have void foo(int param =0); in a header, then void foo(int param = 0){code;} again elsewhere, it will error |
| 05:01.11 | JeffM | redefs of params, etc.. |
| 05:01.13 | jude- | oh, both places? |
| 05:01.15 | jude- | no, haven't seen that |
| 05:01.43 | purple_cow | you can only do it in one place |
| 05:01.45 | JeffM | yeah BOTH |
| 05:01.51 | JeffM | oyu had it in both IIRC ;) |
| 05:02.02 | purple_cow | no I didn't |
| 05:02.03 | JeffM | I kept having to pull one |
| 05:02.05 | purple_cow | gcc has never supported that |
| 05:02.10 | jude- | right |
| 05:02.16 | jude- | haven't gotten that to work |
| 05:02.23 | JeffM | you said it was ther cus you copied and pasted from the header into the cpp |
| 05:02.26 | JeffM | I recall this clearly |
| 05:02.37 | purple_cow | your face! |
| 05:02.40 | JeffM | heh |
| 05:03.25 | JeffM | well it was still a pain with the GTKGLArea stuff |
| 05:03.26 | CIA-3 | BZFlag: 03blast007 * r14338 10/trunk/db/bzfls2/ (6 files in 2 dirs): Initial commit of list server rewrite. Currently supports base functionality of LIST, ADD, and REMOVE actions. |
| 05:03.44 | purple_cow | yeah, I'll give you that |
| 05:04.01 | JeffM | but blast007 how did you do a new list server, with out your own debian box with root access? |
| 05:04.02 | purple_cow | though I don't understand why people were willing to try building bzedit but weren't willing to install that library |
| 05:04.13 | JeffM | purple_cow, HSF |
| 05:04.16 | blast007 | JeffM: hmm? |
| 05:04.31 | JeffM | blast007, tim said he coould only do it once he got his new debian server ;) |
| 05:04.46 | purple_cow | HSF? |
| 05:04.51 | blast007 | and actually, I *DO* have a debian server with root access ;P |
| 05:04.51 | JeffM | human stupidity factor |
| 05:05.02 | purple_cow | ah |
| 05:05.02 | JeffM | blast007, but tim dosn't have root, so it does not exist |
| 05:05.06 | blast007 | heh |
| 05:05.36 | JeffM | the list server is heavaly tied to the debian OS. that's why it runs on BSD now |
| 05:06.07 | blast007 | how was tim going to run a second one? |
| 05:06.23 | JeffM | purple_cow, mostly it wasn't a package since it was depricated, so it wasn't a simple click to install, so it was "hard" |
| 05:06.35 | JeffM | blast007, debian machine on xmission |
| 05:06.38 | blast007 | right |
| 05:06.42 | JeffM | once he got it "set up" |
| 05:06.55 | blast007 | but was he going to modify the client/server to look at more than one? |
| 05:07.02 | JeffM | cus ya know there arn't other data center class machines that he could use |
| 05:07.05 | JeffM | like in germany |
| 05:07.10 | JeffM | blast007, I guess so |
| 05:07.26 | blast007 | doesn't sound very well thought out |
| 05:07.27 | JeffM | he used terms like "second" and "backup" |
| 05:07.27 | blast007 | he'd have to sync as well |
| 05:07.36 | JeffM | well the first one wasn't ,and look how well it's working |
| 05:07.45 | JeffM | I think he was just gonna do mysql replication |
| 05:07.50 | blast007 | the first one makes my eyes bleed |
| 05:08.09 | *** join/#bzflag surftank (i=44cd7b51@gateway/web/cgi-irc/zeebrothers.net/x-0e8581a0f7f4926e) |
| 05:08.15 | blast007 | I'm hoping mine is easier to follow and understand |
| 05:08.16 | JeffM | heh |
| 05:08.25 | JeffM | refactor == good |
| 05:11.05 | JeffM | wonder when brlcad is going to put his changes to font manager back into GPx01 |
| 05:12.09 | JeffM | that's the thing I shoudl finish, it's so close to being actualy playable |
| 05:16.45 | brlcad | JeffM: i've been working all day on that (and stuff related to it) |
| 05:17.21 | brlcad | still hunting down a bug in the ftgltexturefont map though |
| 05:17.31 | JeffM | ah |
| 05:17.40 | JeffM | you gonna put it in the mainline? |
| 05:22.42 | brlcad | soon as I get this bug fixed |
| 05:23.10 | brlcad | it's screwing with the font rebuilding causing a crash just iterating over the map |
| 05:27.28 | brlcad | wonder how others feel about picking up ftgl/freetype2 as a bz dependency for that font manager |
| 05:27.42 | jude- | brlcad: I thought so too |
| 05:28.02 | brlcad | jude-: then why the belaboring :) |
| 05:28.33 | jude- | however, being that I'm still a new, naive developer to BZFlag, I figured that the other devs were correct in suggesting that I find a different TK |
| 05:28.58 | jude- | I haven't touched the GUI code yet...it's all still FLTK |
| 05:29.00 | purple_cow | your first mistake was listening to people |
| 05:29.14 | jude- | oh? |
| 05:29.20 | brlcad | it's hard enough to find a solution that isn't contentious, and you found one that while not anyone's favorite .. nobody really opposes it |
| 05:29.26 | purple_cow | bike sheds |
| 05:29.34 | jude- | ahh |
| 05:30.00 | jude- | then I'll stick with FLTK |
| 05:30.41 | purple_cow | that sounds like a smashing idea |
| 05:30.47 | jude- | really? |
| 05:30.54 | brlcad | maybe you should find a different TK |
| 05:31.09 | jude- | brlcad: why? |
| 05:31.24 | brlcad | tis a joke jude- :) |
| 05:31.34 | jude- | oh |
| 05:32.36 | jude- | brlcad: the difficulty I'd been facing recently is that I was under the impression that the other devs had enough authority over my project to tell me which TK to use |
| 05:32.50 | jude- | ...among other things |
| 05:33.01 | brlcad | it's not like that |
| 05:33.03 | jude- | ...given that I'm being payed to do it |
| 05:33.07 | jude- | *paid |
| 05:33.13 | purple_cow | here's how it is |
| 05:33.21 | brlcad | it's about finding solutions that we can all live with |
| 05:33.22 | purple_cow | "other devs" can make suggestions |
| 05:33.29 | purple_cow | but fundamentally it's your project, and your decision |
| 05:33.51 | jude- | ok |
| 05:34.02 | jude- | sorry |
| 05:34.19 | purple_cow | unless someone with authority over SoC (say, brlcad) says "absolutely not", then you don't have to listen |
| 05:34.32 | jude- | okay |
| 05:34.36 | purple_cow | especially when it comes to contentious issues like toolkit selection |
| 05:34.41 | jude- | thanks for clarifying that :) |
| 05:35.58 | brlcad | other devs don't really have the authority to say "do it this way" .. you should just care a little when other devs say "please don't [insert idea here]" and even then, it matters who says that, how much they really care, and how much the decision matters |
| 05:36.45 | jude- | okay |
| 05:37.26 | jude- | so...anyone object to FLTK enought to say "please don't use FLTK as your widget set"? |
| 05:37.48 | JeffM | use it, don't overthink it or your'll never get done |
| 05:38.00 | JeffM | don't worry about "covering your butt" |
| 05:38.10 | brlcad | we're past that, afaik everyone that it would matter has already said go for it effectively |
| 05:38.25 | jude- | okay |
| 05:38.26 | JeffM | if somone one has a huge issue with it, they'd have broguht it up by now, if they come in later, THEY can change it |
| 05:38.40 | JeffM | your making it into a bikeshed |
| 05:38.45 | jude- | oh |
| 05:38.50 | jude- | don't want to do that :) |
| 05:38.59 | brlcad | your project also has the (unique) flexibility of being a new/isolated tool |
| 05:39.14 | brlcad | lot more wiggle room in the design department |
| 05:39.23 | jude- | this is true |
| 05:39.32 | JeffM | and it's not like the UI look is core functonaility |
| 05:39.37 | JeffM | it's not even the main game |
| 05:39.43 | jude- | indeed |
| 05:39.49 | purple_cow | and we all know how good that looks ;-) |
| 05:39.56 | JeffM | yeah |
| 05:40.06 | The_Interigator | Do purple cows make purple milk? |
| 05:40.08 | JeffM | FLTK will look BETTER then the game |
| 05:40.10 | brlcad | it'd look a bit better with new ftgl font goodness |
| 05:40.16 | brlcad | heh |
| 05:40.23 | purple_cow | Ok, got nose upgraded. Time to clean my bathroom |
| 05:40.29 | purple_cow | The_Interigator: good luck finding out |
| 05:40.46 | The_Interigator | :( |
| 05:41.08 | brlcad | ~spell interigator |
| 05:41.17 | The_Interigator | .... |
| 05:41.22 | The_Interigator | Its not a word, its a name. |
| 05:41.27 | brlcad | clearly |
| 05:41.30 | jude- | sorry for having to ask all this--while I use OSS every day, I haven't had the privilage to *really* develop a project with another team |
| 05:41.46 | jude- | until now |
| 05:42.16 | purple_cow | jude-: that's fine |
| 05:42.38 | JeffM | did it get cleared? |
| 05:42.44 | brlcad | the debugger isn't helping at all |
| 05:42.47 | purple_cow | it's hard to put your foot down on design decisions when in your situation |
| 05:42.50 | brlcad | no, you don't clear or free anything :) |
| 05:42.57 | JeffM | so clear it |
| 05:42.57 | *** join/#bzflag plasma_kaz (n=Miranda@about/essy/MeanieBeanie/plasmakaz) |
| 05:43.02 | JeffM | and rebuild it |
| 05:43.16 | jude- | purple_cow: I don't want to offend anyone any more than I have to :) |
| 05:43.35 | JeffM | with that attiude, you'll never get anything done |
| 05:43.45 | JeffM | some one person will be offended by any choice you make |
| 05:43.51 | JeffM | so just do what you think is right |
| 05:44.00 | JeffM | if there is an issue,it's up to THEM to prove it to you |
| 05:44.04 | brlcad | JeffM: I would, but then that'd be a memory leak |
| 05:44.07 | JeffM | if there proof makes sense |
| 05:44.16 | JeffM | brlcad, the map contains pointers? |
| 05:44.18 | brlcad | as you've got new'd ftgltexturefont's |
| 05:44.24 | brlcad | yeah |
| 05:44.25 | jude- | JeffM: thanks, I'll remember that :) |
| 05:44.26 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 05:44.26 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 05:44.28 | JeffM | eww |
| 05:44.43 | jude- | hello L4m3r |
| 05:44.45 | JeffM | free em on a context clear, then clear the map ;) |
| 05:44.46 | brlcad | so I was trying to iterate and free each .. hence the crashing |
| 05:45.00 | brlcad | that's what crashes |
| 05:45.16 | JeffM | how are you iterating? |
| 05:45.18 | brlcad | the map has elements that make no sense |
| 05:45.26 | L4m3r | hi jude- |
| 05:45.39 | jude- | L4m3r: respawn! |
| 05:45.48 | L4m3r | heh |
| 05:45.59 | jude- | who/what killed you? |
| 05:46.02 | L4m3r | Housing (Hosing) really ruined my day today |
| 05:46.21 | jude- | hosing? |
| 05:46.27 | L4m3r | as in "I got hosed" |
| 05:46.38 | jude- | by whom? |
| 05:46.40 | *** join/#bzflag DavidHKMrPowers (n=chatzill@unaffiliated/davidhkmrpowers) |
| 05:46.45 | L4m3r | ucla housing services :) |
| 05:46.50 | brlcad | std::map<int,FTGLTextureFont*>::iterator itr; for (itr = faces[i].sizes.begin(); itr != faces[i].sizes.end(); itr++) { ... crashes during itr++ .. only the first itr seems correct |
| 05:47.02 | jude- | L4m3r: sorry to hear that |
| 05:47.05 | L4m3r | today, I moved |
| 05:47.37 | JeffM | what do you do in the loop? |
| 05:47.41 | L4m3r | as it was planned, I had a nice room on the top floor of the building I was already in... nice view and all. I was stoked... very easy move within the same building |
| 05:47.43 | JeffM | just a free? |
| 05:47.46 | JeffM | or also an erase? |
| 05:48.07 | JeffM | itr=faces[i].erase(itr); ? |
| 05:48.12 | brlcad | std::cout << "rebuilding font " << i << " with size " << (*itr).first << " hmm " << (*itr).second << std::endl; |
| 05:48.18 | brlcad | just iterate and print will crash |
| 05:48.25 | L4m3r | I went down to get my key this afternoon and they told me I had been moved to another building, one of the farthest dorms from mine... >_< |
| 05:48.29 | JeffM | i is valid? |
| 05:48.31 | jude- | brlcad: you sure the map has a nonzero size? |
| 05:48.42 | L4m3r | as if that wasn't enough, I've been crammed with a roommate into a room that was obviously meant for one person |
| 05:48.49 | brlcad | ooh, i take that back |
| 05:48.55 | jude- | L4m3r: ouch |
| 05:49.07 | brlcad | just printing doesn't crash.. interesting |
| 05:49.10 | L4m3r | so I spent 6 hours moving my stuff up and down a hill |
| 05:49.33 | jude- | L4m3r: can't you challenge that somehow? |
| 05:49.51 | brlcad | JeffM: hah, yes, I am erasing |
| 05:49.52 | L4m3r | I will complain to my boss about it |
| 05:50.02 | JeffM | brlcad, if your erasing you can't ++ that itr |
| 05:50.08 | JeffM | erase returns the next one |
| 05:50.14 | JeffM | so that case you can't ++ |
| 05:50.14 | L4m3r | but they give employees a huge discount on housing so I don't think they want us to bitch about it :\ |
| 05:50.21 | brlcad | i erase in a different routine |
| 05:50.22 | JeffM | that's why I never do for loops with maps |
| 05:50.28 | JeffM | not in that loop? |
| 05:50.31 | brlcad | nope |
| 05:50.34 | JeffM | hmm |
| 05:50.41 | brlcad | but the size of the map does change |
| 05:50.43 | jude- | L4m3r: you could always try :) |
| 05:50.55 | L4m3r | I will :) |
| 05:50.59 | JeffM | the erase code I often use, is only valid on windows |
| 05:51.01 | brlcad | since it's resized in that other routine (with a different iterator) |
| 05:51.02 | jude- | it isn't an excuse for ucla's short-coming :) |
| 05:51.03 | a_meteorite | I thought iterators were usually pointers ... |
| 05:51.09 | L4m3r | but for now, I need to start setting this room up |
| 05:51.13 | JeffM | seems that not all versions of STL return an itr on erase |
| 05:51.30 | JeffM | check on the erase if I do itr = map.erase(itr) |
| 05:51.36 | a_meteorite | oh, I see, he did use a pointer |
| 05:51.38 | L4m3r | I'm going to steal a loft-bed from another room... there's not enough floorspace in here to justify low beds |
| 05:51.38 | JeffM | can't do that on non windders |
| 05:51.50 | JeffM | a_meteorite, they can act like them |
| 05:51.56 | a_meteorite | ah |
| 05:52.01 | JeffM | but they are NOT them |
| 05:52.03 | JeffM | they are classes |
| 05:52.05 | a_meteorite | I only half get pointers anyways :) |
| 05:52.07 | a_meteorite | oh |
| 05:52.07 | brlcad | nah, it just deletes the .second and calls erase on the map entry |
| 05:52.08 | JeffM | that contain a refrence |
| 05:52.11 | a_meteorite | wow |
| 05:52.18 | jude- | a_meteorite: the pointer-related operators (i.e. *, ->, etc) work on iterators like pointers |
| 05:52.25 | JeffM | brlcad, does it ++ the iter after the erase? |
| 05:52.52 | jude- | a_meteorite: but they themselves are NOT pointers. They are iterators. It's a design pattern |
| 05:52.56 | brlcad | it doesn't use the iter after the erase (in that routine) |
| 05:53.01 | jude- | ~wiki Iterator |
| 05:53.08 | JeffM | hmmm |
| 05:53.10 | a_meteorite | jude-: remind me to get lessons from you :) |
| 05:53.16 | jude- | lol |
| 05:53.26 | JeffM | is that called inside a loop? |
| 05:54.17 | JeffM | a_meteorite, the pointer methods on the iterator for a vector have been overiden to return the refrence to the contained value |
| 05:54.32 | JeffM | maps don't do that, they have a first and a second cus there is 2 data values for each item |
| 05:54.35 | Macrosoft | beware the power of wikipedia |
| 05:54.36 | brlcad | it's that for loop { cout details ; rebuild(index, size); } ... that rebuild routine looks up the font's index/size with find(), deletes it, erases, no return val |
| 05:54.36 | a_meteorite | ahh, I see, so they're not really pointers. |
| 05:54.37 | JeffM | the key and the value |
| 05:54.46 | a_meteorite | they're just overloaded |
| 05:54.56 | L4m3r | iterators exist because some data structures are stored non-contiguously :) |
| 05:54.59 | JeffM | they are calsses with methods |
| 05:55.23 | a_meteorite | k |
| 05:55.25 | jude- | indeed |
| 05:55.36 | jude- | ~iterator++ |
| 05:55.36 | a_meteorite | some of these concepts are pretty interesting :) |
| 05:55.46 | JeffM | L4m3r, it's always stored in order, just not by continous index of keys ;) |
| 05:56.00 | L4m3r | heh |
| 05:56.34 | brlcad | so I think I see why it's happening now at least .. though I don't like it .. I'd expect a little more intelligent iterating on maps |
| 05:56.47 | JeffM | erase jacks you up |
| 05:56.51 | JeffM | I found that out a lot later |
| 05:57.05 | JeffM | I see why windows STL returns the next iterator |
| 05:57.08 | JeffM | makes it a lot nicer |
| 05:57.37 | brlcad | cept this is a case of routine calling a routine on the same container, a little more obfuscated than calling erase right in that loop |
| 05:57.43 | JeffM | yeah |
| 05:57.49 | JeffM | that will jack that iterator up :) |
| 05:57.58 | JeffM | now you can make a copy of the iterator |
| 05:58.00 | JeffM | move past it |
| 05:58.09 | JeffM | then delete the one behind it |
| 05:58.12 | JeffM | that should work |
| 05:59.55 | brlcad | hm, if that's the case.. |
| 06:00.04 | brlcad | then I should be able to get away with simply iterating in reverse |
| 06:04.48 | brlcad | woo hoo! |
| 06:05.29 | brlcad | finally! .. that lil fscker took way too long to pin down ... |
| 06:05.40 | brlcad | thanks for your help, though -- that certainly did it |
| 06:13.09 | brlcad | interestingly enough, I can now toggle between your font manager and bz's with nearly identical code, including performance metrics that compare the two |
| 06:35.02 | *** join/#bzflag codergeek42 (n=peter@fedora/codergeek42) |
| 06:37.35 | *** join/#bzflag L4m3r_ (i=l4m3r@about/essy/warning/L4m3r) |
| 06:37.35 | *** mode/#bzflag [+v L4m3r_] by ChanServ |
| 06:46.15 | *** join/#bzflag lodxcol (n=lodxcol@unaffiliated/lodxcol) |
| 06:52.35 | *** join/#bzflag HighKarateKitty (n=HighKara@ip68-98-31-187.ph.ph.cox.net) |
| 06:58.19 | *** join/#bzflag stylus (i=stylus@freenode/helper/stylus) |
| 07:14.25 | DTRemenak | jude-: just to weigh in on a dead discussion here, I don't think I've heard any actual developer say that you should not use FLTK. Some have complained that it's ugly, and I've complained that it's a bit lax in 64-bit-goodness, but we complain about *everything.* |
| 07:14.32 | DTRemenak | there is no perfect toolkit; FLTK doesn't suck any worse than any of the rest of them as far as I can tell |
| 07:15.51 | jude- | thanks for that |
| 07:17.41 | jude- | the difficulty is, I couldn't tell if the other developers were just merely complaining, or insinuating that I should change my mind |
| 07:19.04 | jude- | ...which brought on this discussion :) |
| 07:19.09 | DTRemenak | yeah, I know..."dude this sucks" and "dude this sucks, ditch it" sound awefully similar sometimes :) |
| 07:19.11 | brlcad | DTRemenak: thanks for the lead on the ogl state .. that was part of several issues |
| 07:19.32 | DTRemenak | brlcad: yeah, I had a ton of problems with that when I was trying to pull it into bz |
| 07:19.51 | brlcad | it? |
| 07:19.53 | DTRemenak | glad it helped; sorry I couldn't be more precise |
| 07:19.59 | DTRemenak | font manager |
| 07:20.14 | brlcad | ah, yes |
| 07:20.37 | DTRemenak | all the font manager variations are based on the same code JeffM wrote ages ago, they've just diverged differently |
| 07:21.58 | DTRemenak | from what I've heard, the recentish ttf one is the best of them, but it is probably still lacking some of the features from bz's |
| 07:22.00 | brlcad | yeah, i'd have to merge two semi divergent versions to pull it into bz (again) |
| 07:22.06 | DTRemenak | yeah :) |
| 07:22.35 | brlcad | the ttf one is pretty sweet, has some nice features that bz's doesn't have (aside from the ttfness) |
| 07:23.00 | DTRemenak | should be a lot easier than the first time though, at least bz's code is expecting something sensible, not the wacky stuff we had in there before |
| 07:23.22 | brlcad | i got it all hooked up now so it's a simple compile-time toggle, added a few of the routines from bz's that was missing so they were more close |
| 07:23.33 | DTRemenak | ah, cool...in your project, I assume |
| 07:23.38 | brlcad | right |
| 07:23.45 | brlcad | got both working |
| 07:23.55 | DTRemenak | new one is probably a bit faster, the ansi stuff and so on is a lot of dead weight if you're not using it |
| 07:23.57 | brlcad | except bz's rebuild() doesn't seem to work |
| 07:24.16 | brlcad | actually, bz's is faster .. i added timing code too |
| 07:24.22 | DTRemenak | used to be worse before tupone cleaned up the copy/free stuff |
| 07:24.27 | DTRemenak | really |
| 07:24.30 | DTRemenak | that's surprising |
| 07:25.20 | brlcad | ran some profiles, it's spending most of its time actually rendering the textured font |
| 07:26.17 | brlcad | there is a little bit of overhead evaluating the ttf that bz's doesn't have to do -- only using textured font, though, and not a bitmap/image font |
| 07:26.30 | DTRemenak | yeah |
| 07:26.47 | DTRemenak | bitmap should not be any faster on modern cards though |
| 07:27.11 | brlcad | the difference is about 2x for about 1000 drawString's per frame (e.g. 50fps vs 25fps) |
| 07:27.24 | DTRemenak | wow |
| 07:27.38 | DTRemenak | that's a lot more than I would have expected |
| 07:27.52 | brlcad | it's not noticable for just a few dozen |
| 07:27.56 | brlcad | dominated by other factors |
| 07:28.00 | DTRemenak | yeah |
| 07:28.10 | DTRemenak | still surprising :) |
| 07:28.37 | brlcad | so theoretically.. for bz it shouldn't be "too" bad .. especially given just how much better it looks |
| 07:28.58 | DTRemenak | yeah, not needing to scale (or do the silly snapping thing at low sizes) would be cool |
| 07:39.52 | brlcad | alas, I see more optimizations that could be done to bz's current than to the ftgl version -- the time is being spent in ftgl land |
| 07:53.33 | a_meteorite | awilcox: if you're there... remember that bug I had with forking bzfs on mpm-worker apache/mod_php? well, it works now once I proxy back requests to a lighttpd/fastcgi/php5.2 server :) |
| 07:53.46 | a_meteorite | apparently it don't like forking processes under mpm-worker |
| 07:58.19 | Macrosoft | so, if hosting a server on comcast's residential net service is against the TOS...when do the men in dark clothes come to take me away...never to be seen again |
| 08:01.01 | jude- | Macrosoft: if you get caught :) |
| 08:01.08 | jude- | screw the TOS |
| 08:01.10 | jude- | it's Comcrap |
| 08:01.21 | jude- | they don't take their customers seriously; we don't take them seriously :) |
| 08:01.26 | Macrosoft | its com-cataclysmic |
| 08:01.50 | Macrosoft | so...how can they catch me hosting? |
| 08:02.00 | jude- | heh--I could probably use masquerading to give my entire block free broadband and not get caught |
| 08:02.16 | a_meteorite | Macrosoft: by sniffing your traffic |
| 08:02.19 | a_meteorite | by being smart |
| 08:02.25 | Macrosoft | masquerading?...sounds like a NAT |
| 08:02.43 | jude- | it's an iptables feature |
| 08:02.46 | jude- | in *nix |
| 08:03.01 | a_meteorite | by looking at you using a ton of bandwidth and actually seeing what ports they're going on and such |
| 08:03.02 | jude- | let other PCs pretend to be one PC already on the 'net |
| 08:03.10 | a_meteorite | jude-: :D |
| 08:03.36 | jude- | I use it to let my PDA access the internet using ethernet-over-usb in it's docking cradle |
| 08:03.57 | jude- | the PDA masquerades as my PC |
| 08:04.10 | Macrosoft | my PDA doesnt have that function (palm TE) |
| 08:04.15 | jude- | it...could |
| 08:04.21 | jude- | actually, it's a PC thing |
| 08:04.26 | jude- | you don't need to do anything to the PDA |
| 08:04.34 | Macrosoft | palm desktop be damned |
| 08:04.57 | jude- | you just need to tell your PC to allow your PDA to masquerade as itself |
| 08:05.07 | Macrosoft | im been trying to get linux to work on my palm |
| 08:05.13 | jude- | I know |
| 08:05.16 | jude- | ramdisk still not working? |
| 08:05.32 | Macrosoft | i bought an SD card |
| 08:05.38 | jude- | that's a start :) |
| 08:05.45 | a_meteorite | bye all, night |
| 08:05.53 | jude- | bye a_meteorite |
| 08:05.55 | Macrosoft | but i still cant get it to mount rootFS |
| 08:06.07 | jude- | can you pastebin the error message? |
| 08:06.20 | jude- | ...and are you sure you're giving Garux the right boot params? |
| 08:06.42 | Macrosoft | the message is short.. i could put it here |
| 08:06.54 | Macrosoft | its just one line |
| 08:06.57 | jude- | kk |
| 08:07.07 | Macrosoft | *booting* |
| 08:07.12 | jude- | lol |
| 08:07.14 | jude- | that's it? |
| 08:07.26 | jude- | and it just freezes? |
| 08:07.27 | Macrosoft | no |
| 08:07.54 | Macrosoft | ill give you the boot param's |
| 08:08.51 | Macrosoft | root=/dev/mmcblk0p1 rootfstype=ext2 console=tty0 fbcon=map:0 font:MINI4x6 |
| 08:09.03 | jude- | did you format your SD card to ext2? |
| 08:09.12 | Macrosoft | no, how? |
| 08:09.17 | jude- | there's the problem :) |
| 08:09.30 | jude- | mkfs.ext2 /dev/sda1 |
| 08:09.32 | Macrosoft | how does one do that |
| 08:09.45 | jude- | (replace /dev/sda1 with whatever device file corresponds to the first partition on your SD card) |
| 08:10.00 | jude- | use Linux |
| 08:10.06 | jude- | and a USB card reader |
| 08:10.13 | jude- | and mkfs.ext2 |
| 08:10.30 | jude- | (which should be under /sbin; you'll need to be root to use it) |
| 08:10.57 | jude- | ya with me? |
| 08:11.01 | Macrosoft | i need 2 partitions |
| 08:11.16 | Macrosoft | one small one for palm os |
| 08:11.29 | Macrosoft | and the rest can go to ext2 |
| 08:11.51 | jude- | right |
| 08:11.55 | jude- | just like the T|E2 |
| 08:12.07 | jude- | make the second partition ext2 then :) |
| 08:12.12 | jude- | and the first one vfat |
| 08:12.27 | Macrosoft | does palmOS use vfat? |
| 08:12.30 | jude- | yup |
| 08:12.59 | jude- | you'll also need to put zimage and initrd in the root of the vfat partition |
| 08:13.09 | jude- | ...if you need an initrd, that is :) |
| 08:13.15 | Macrosoft | zimage? |
| 08:13.38 | Macrosoft | ~wiki zimage |
| 08:13.39 | jude- | the kernel image |
| 08:13.57 | jude- | hang on a sec... |
| 08:14.15 | Macrosoft | i thought that was part of the garux.prc file |
| 08:15.06 | jude- | I dunno...it isn't with the T|E2 (but then again, the E2 is vastly different than the E) |
| 08:15.10 | jude- | let me find a link to the documentation |
| 08:15.23 | jude- | (not the sourceforge one) |
| 08:15.43 | Macrosoft | theres no image defined in the boot params |
| 08:16.19 | Macrosoft | and im using the default boot params (site says its the most likely to work) |
| 08:18.45 | Macrosoft | ...dont worry about it...i need to get some sleep anyway, its 3:20AM here |
| 08:19.22 | jude- | heh--says its still in beta |
| 08:19.31 | jude- | I guess you're not alone if you're experiencing problems :) |
| 08:19.37 | jude- | you need a rootfs |
| 08:19.56 | jude- | by that, I mean you need an image of a root filesystem |
| 08:20.05 | jude- | try getting Familiar Linux on there |
| 08:20.12 | jude- | i.e. get one of their rootfs-es |
| 08:20.18 | jude- | and unpacking it into your SD card |
| 08:20.22 | jude- | (the ext2 partition) |
| 08:20.36 | jude- | I guess the zimage is built-in...my bad :) |
| 08:20.42 | jude- | you were right |
| 08:20.52 | *** part/#bzflag Rawk (n=unknown@203.109.176.242) |
| 08:21.10 | jude- | also, change your boot param to "root=/dev/mmcblk0p2" |
| 08:21.19 | jude- | so it'll try to boot into the second partition |
| 08:21.34 | jude- | ...assuming you made the first one :) |
| 08:21.48 | *** join/#bzflag Pumpernickel (n=pumperni@about/essy/bacon/PuMpErNiCkLe) |
| 08:22.20 | jude- | garux by itself is just a bootloader |
| 08:25.19 | *** join/#bzflag Blue_Eyes (n=Blue@host134-144-dynamic.56-82-r.retail.telecomitalia.it) |
| 08:27.45 | jude- | also, have a look at the Zire 71...very similar to the T|E architecturally |
| 08:28.02 | jude- | ...and it already has pretty much complete Linux support :) |
| 08:28.14 | jude- | you might be able to use it's rootfs |
| 08:39.04 | brlcad | mmm.. ttf font's look so much nicer |
| 09:11.30 | *** join/#bzflag KTL (n=KTL@kotnet-149.kulnet.kuleuven.be) |
| 09:24.52 | *** join/#bzflag noyb (i=noyb@nat/sun/x-25cc5918fbe53ed7) |
| 11:02.39 | *** join/#bzflag tannerld_ (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 12:02.10 | daxxar | hey brlcad =) |
| 12:25.57 | *** join/#bzflag Winny (n=BZ_Win_@CPE0016b6de59f3-CM000f9fac8236.cpe.net.cable.rogers.com) |
| 12:37.29 | *** join/#bzflag ElectricElf (n=dbharris@76.64.131.227) |
| 12:44.01 | *** join/#bzflag delusional (n=delusion@pool-71-253-10-50.pitbpa.east.verizon.net) |
| 13:02.49 | daxxar | Hm |
| 13:04.08 | daxxar | For anyone who's interested in bzscripted (the scripted headless client) - as a user (i.e. writing scripts), it'd be in your and my best interest if you post questions, suggestions and feedback on http://gsoc.daxxar.com/2007/06/17/api-design-thoughts/ :-) |
| 13:17.55 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 13:17.55 | *** mode/#bzflag [+v tupone] by ChanServ |
| 13:18.24 | tupone | hola brlcad |
| 13:40.02 | *** join/#bzflag delusional_ (n=delusion@pool-71-253-10-50.pitbpa.east.verizon.net) |
| 13:51.56 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-003-004.ewe-ip-backbone.de) |
| 13:55.03 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 13:55.03 | *** mode/#bzflag [+v tupone] by ChanServ |
| 14:02.27 | brad | is there a way to disable tank explosions when they die? |
| 14:04.18 | brlcad | CIA0 tupone and daxxar |
| 14:15.00 | daxxar | Ciao? :-) |
| 14:17.26 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 14:22.47 | blast007 | brad: _tankExplosionSize |
| 14:22.56 | blast007 | might work, haven't tried setting it to 0 |
| 14:23.29 | *** join/#bzflag RatOmeter_ (n=chatzill@139.78.95.188) |
| 14:37.45 | Winny | rofl, someone is trying to start up a server with thier email as the addres |
| 14:37.51 | blast007 | hah |
| 14:38.04 | blast007 | that's a new one |
| 14:38.16 | Winny | indeed |
| 14:38.57 | daxxar | Hmm, bzflag-by-email |
| 14:41.39 | Winny | hmm, anyone else think someone should can the enchancements forum? All it is these days are kiddies going "OMG 2X FLAG IN ONE LOLZZ!?!??!" |
| 14:42.39 | blast007 | "Forum closed for summer! Come back in the fall!" (I wish...) ;) |
| 14:42.58 | Winny | hehe |
| 14:44.16 | Macrosoft | *ping* |
| 14:44.30 | Macrosoft | ... |
| 14:44.34 | Winny | *pong* |
| 14:44.35 | Winny | ... |
| 14:45.05 | Macrosoft | who was it that said earlier that they stopped hating comcast? |
| 14:45.40 | Macrosoft | you should hate them, they're against net neutrality |
| 14:46.03 | Macrosoft | without that, there would be no bzflag |
| 14:46.58 | *** join/#bzflag kung (n=kung@Yd358.y.pppool.de) |
| 14:47.22 | kung | hi there |
| 14:47.26 | Winny | hello again |
| 14:47.27 | Macrosoft | :( no more bzflag |
| 14:47.33 | kung | no more? |
| 14:47.53 | blast007 | kung: he's just babling about "net neutrality" |
| 14:47.58 | blast007 | and comcast ;) |
| 14:48.04 | blast007 | kung: have a question? |
| 14:48.17 | daxxar | brlcad: Did you see the blogpost? |
| 14:48.18 | kung | I need an official eMail adress of the project |
| 14:48.24 | Winny | ...for? |
| 14:48.34 | Winny | you can ask your questions here |
| 14:48.38 | Winny | we don't bite |
| 14:48.41 | Winny | that much... |
| 14:48.41 | kung | eh nope |
| 14:48.48 | kung | not these questions..well...I could.. |
| 14:48.58 | blast007 | what is the nature of the questions? |
| 14:48.59 | kung | but if I post them here I get kicked for spamming. |
| 14:49.13 | kung | and its more than a question but not for the public forum necessarily |
| 14:49.14 | Macrosoft | ? |
| 14:49.15 | daxxar | Advertising or flooding? |
| 14:49.33 | kung | I'm collecting opinions of project officials.. |
| 14:49.45 | kung | well we created this linux live dvd (live.linux-gamers.net) |
| 14:49.54 | kung | and bzflag is one of the games on itg.. |
| 14:49.56 | kung | -g |
| 14:50.04 | kung | so I want to give and get some feedback |
| 14:50.07 | kung | thats about it |
| 14:50.25 | kung | but an eMail woulb be very convenient for this purpose..^^ |
| 14:50.40 | daxxar | Haha, cool project, kung :) |
| 14:51.02 | kung | thx :) |
| 14:51.04 | Winny | there is more then one dev, maybe try PMing them on BZBB? |
| 14:51.32 | kung | guess I'll come back here later... |
| 14:51.55 | kung | got to head home now |
| 14:52.00 | kung | bbl |
| 14:52.07 | Winny | interesting |
| 14:57.36 | CIA-3 | BZFlag: 03blast007 * r14339 10/trunk/db/bzfls2/database.sql: Change the size of 'serverid' from smallint to int |
| 14:57.52 | blast007 | ruskie :P |
| 14:58.21 | ruskie | most of the stuff on that dvd is non-Free though... |
| 14:58.26 | ruskie | freeware mostly |
| 14:58.32 | ruskie | or part-Free |
| 14:59.15 | ruskie | some of those don't have a completly Free implementation of everything unlike bzflag |
| 14:59.29 | ruskie | they have some .so that is locked so that it can't get cheated etc... |
| 14:59.49 | Winny | wow, the BZFlag logo on that game REALLY sucks |
| 15:00.07 | Winny | its one of those tanks with the apple on the side... |
| 15:00.08 | brlcad | daxxar: yes, I did see it |
| 15:00.58 | blast007 | Winny: heh |
| 15:01.35 | brlcad | daxxar: and it looks pretty good -- and I did have several comments... |
| 15:01.43 | brlcad | heh, yay .. my apple-tank |
| 15:02.13 | Winny | thats yours?! |
| 15:02.25 | Winny | :p |
| 15:03.41 | brlcad | well, of course -- I made it for the os x icon for when you install bzflag on os x |
| 15:03.53 | brlcad | not my fault that folks use it for other purposes :P |
| 15:04.10 | Winny | but you did make it :P |
| 15:04.13 | daxxar | brlcad: Would you then please either privmsg me them or (preferred) post them on the blag? ;-) |
| 15:04.14 | Macrosoft | you have a link to the pic, i havent seen it |
| 15:04.16 | Macrosoft | ? |
| 15:05.03 | blast007 | Macrosoft: do a google images search for "bzflag mac" |
| 15:05.10 | Macrosoft | ok |
| 15:05.27 | Winny | http://1vs1.bzleague.com/images/MacBZFlag.png |
| 15:05.37 | Winny | or click that |
| 15:05.59 | daxxar | That's not too ugly - except for the apple logo not being pretty |
| 15:06.07 | Macrosoft | crap, i have to wait for gimp to load |
| 15:06.08 | CBG | sorry, I must be having a blonde moment... "freeware" isn't "free"? |
| 15:06.13 | brlcad | there were several variations |
| 15:06.15 | CBG | (ruskie ^) |
| 15:06.33 | brlcad | daxxar: possibly, though I'd just as rather discuss it in here too ;) |
| 15:06.37 | daxxar | CBG: libre or gratis? |
| 15:06.39 | Macrosoft | nice tank |
| 15:06.56 | Macrosoft | gotta go to work, later |
| 15:07.00 | daxxar | CBG: Freeware is gratis, but not libre. ;-) |
| 15:07.02 | CBG | daxxar: pardon? to me, "free" means "$0" |
| 15:07.04 | daxxar | CBG: (free as in beer, not as in speech) |
| 15:07.14 | brlcad | i agree that the non-interactive approach is the way to go -- can't really lock-step bz with all of the robocode actions since they might not complete |
| 15:07.24 | daxxar | CBG: http://en.wikipedia.org/wiki/Gratis_versus_Libre |
| 15:07.30 | CBG | ok, thanks. |
| 15:08.00 | CBG | what does "freedom" mean in terms of a game ?? |
| 15:08.14 | daxxar | brlcad: 'might not complete'? |
| 15:08.17 | brlcad | free to kick your opponent's butt? :) |
| 15:08.24 | daxxar | CBG: It's more in terms of software than a game specifically |
| 15:09.02 | daxxar | CBG: Freedom as in 'freedom to do what you want with it', i.e. open source |
| 15:09.22 | daxxar | CBG: " .. the term gratis are used to distinguish freeware (gratis software) from free software." |
| 15:09.57 | CBG | I don't see what anyone would say they want a "free" game when they could also say they want an "open-source" game and _totally avoid all confusion_ !! |
| 15:10.22 | CBG | s/what/why/ |
| 15:10.33 | ruskie | cause open-source != Free |
| 15:10.41 | CBG | Exactly. |
| 15:10.45 | daxxar | CBG: It depends the license the source is released as, afaik. |
| 15:10.50 | daxxar | CBG: http://en.wikipedia.org/wiki/Free_software |
| 15:11.09 | CBG | Why say "I want free software" when you mean "I want open source software". "Free software" means "$0 software" to me and a LOT of other people. |
| 15:11.12 | brlcad | daxxar: I think either can work in the case of bzflag as each tick is simply an interation through the event loop -- the harder part, however, is what do you do when the bot says "turn 45" and they cannot turn 45 |
| 15:11.20 | Winny | I think we have a new record of longest location on the forum... "Location: Inferno's map with radar. That map is awesome!!!! It has little mazes all over the walls!!! Yay!!!!" |
| 15:11.34 | daxxar | brlcad: You mean the blocking mode? |
| 15:11.34 | brlcad | i forget the details of robocode's callbacks for when an action cannot complete |
| 15:11.38 | brlcad | for either mode |
| 15:11.40 | CBG | ~lart Richard Stallman |
| 15:11.40 | ibot | takes Richard Stallman to the vet for a "special" visit |
| 15:11.48 | ruskie | ~lart CBG |
| 15:11.48 | ibot | squishes CBG like a bug |
| 15:11.59 | daxxar | brlcad: In the blocking case, it should raise an event and return from the turn-call |
| 15:12.26 | daxxar | brlcad: In the nonblocking case, it should merely stop turning, set 'turn remaining' to 0, and raise an event. |
| 15:12.30 | daxxar | brlcad: imho |
| 15:12.46 | ruskie | anyway plenty of topics about Free, free and open all around... |
| 15:13.03 | brlcad | okay, and whether it's blocking or not is a parameter of the simulation when it's set up and not the bots? or the other way around? |
| 15:13.54 | daxxar | brlcad: Wether it's blocking or not depends on the function you invoke. RoboCode has a hierarchy like Robot -> AdvancedRobot, where AdvancedRobot adds 'setTurn..', 'setSpeed' etcetera - which just set internal states. |
| 15:13.58 | brlcad | i think either could be made to work as interactive is really just bundling actions together and non-interactive is quasi-stateless streaming ala opengl |
| 15:14.00 | blast007 | ruskie: show me a Free game that's as good as Half Life 2 ;) oh right, doesn't exist |
| 15:14.03 | CBG | I'm going to invent a new type of vehicle, it will be a giant mouse-ball thing that you walk around in. Only I'm going to call it a Car because that term is already used for something else and it will totally confuse everyone! HAHA!!! |
| 15:14.16 | blast007 | CBG: hehe |
| 15:14.50 | ruskie | blast007, erm... I don't consider that a good game... |
| 15:14.52 | blast007 | I don't use non-Car vehicles /me gets in his giant mouse ball |
| 15:14.55 | daxxar | brlcad: So if you do setTurnLeft(45) - you set it up to turn 45 degrees left, and it works itself along this when you execute(). If you do turnLeft(45) - it basically does the same as setTurnLeft(45); while (getTurnRemaining() > 0) execute(); |
| 15:15.10 | blast007 | ruskie: right, because you're not a real gamer |
| 15:15.17 | ruskie | blast007, lol |
| 15:15.24 | ruskie | I consider wesnoth a good game |
| 15:15.27 | CBG | blast007: :D lol |
| 15:15.40 | brlcad | daxxar: okay, so then basically it's up to the bot as they're implemented |
| 15:15.52 | daxxar | brlcad: Aye |
| 15:15.55 | brlcad | the hard(erish) part is making the back-end state work with either :) |
| 15:16.30 | CBG | wesnoth? I think I tried that for about 30 seconds before destroying all evidence of it from my drive. :| |
| 15:16.35 | ruskie | lol |
| 15:16.36 | blast007 | ruskie: my point exactly ;) |
| 15:16.49 | daxxar | brlcad: Well, yes - but if I just implement turnLeft(..) as setTurnLeft(..) while (getTurnRemaining() > 0) wait(..); |
| 15:16.51 | brlcad | one of the goals i'm hoping to achieve is actual drop-in execution of robocode bots |
| 15:16.54 | daxxar | .. it should work out. |
| 15:16.55 | ruskie | I don't rank games based on pwetty pics or fragging or such... |
| 15:17.00 | ruskie | it needs to be enjoyable |
| 15:17.12 | CBG | Yep, looking at the wesnoth site, that is the game I am thinking of. Give me Halo anyday. :P |
| 15:17.22 | brlcad | that is taking an existing robocode bot (which there are dozens/hundreds available) .. and have it actually operate unmodified |
| 15:17.27 | blast007 | I have a high end video card. I need to use it. |
| 15:17.30 | CBG | But saying that, I have to admit, my fave game ever, is Enemy Territory, which is free. |
| 15:17.34 | ruskie | CBG, I acctually prefer to use my brain |
| 15:17.35 | CBG | ...... free as in beer... ?? lol |
| 15:17.43 | blast007 | CBG: it's free, not Free! |
| 15:17.46 | daxxar | brlcad: Yeah, that would be kinda neat. I'm kinda curious if it's easily achievable. |
| 15:17.49 | CBG | ruskie: uh, other games require brain usage too |
| 15:17.55 | ruskie | erm |
| 15:17.57 | brlcad | whether it behaves identical of course depends on several things since the bots are clearly in a different kind of simulation, but the events are mostly all the same or can have similar characteristics |
| 15:17.58 | CBG | but other games also look good |
| 15:18.03 | CBG | and other games are also fun ! |
| 15:18.04 | daxxar | brlcad: I'm trying to find a nice backend design which allows for sane usage of the execute()-command |
| 15:18.08 | CBG | blast007: oh? shucks!! |
| 15:18.20 | ruskie | when I played hl2 my brain was switched to off other than the clicking and moving stuff |
| 15:18.29 | CBG | I must go hang myself for using the word "free" to mean "no cost" ! |
| 15:18.39 | ruskie | CBG, but free does mean no cost |
| 15:18.45 | CBG | You can click and move stuff without a brain? WOW. |
| 15:18.47 | ruskie | but the word Free doesn't |
| 15:18.53 | CBG | ruskie: wahey! finally some sense! |
| 15:18.59 | Winny | yay... pythonian bots again |
| 15:19.05 | CBG | "Free" == "free" at beginning of sentence |
| 15:19.08 | blast007 | Winny: fun.. |
| 15:19.11 | *** join/#bzflag kung (n=kung@dslb-084-059-104-188.pools.arcor-ip.net) |
| 15:19.21 | CBG | Free software rocks. == Software that you don't have to pay for rocks. |
| 15:19.45 | brlcad | daxxar: a word of caution on over-architecting the back-end .. if you know an approach will get the job done and simply involve some replicated typing, that will be better than a bigger backend that doesn't work yet or lacks an implementation :) |
| 15:19.54 | ruskie | CBG, I never used the word Free at the begining of a sentance |
| 15:19.54 | CBG | Why does Richard Stallman decide that software that you can edit however you like should be called "Free Software" when "Free Software" CLEARLY has another much more LOGICAL meaning?! |
| 15:20.01 | daxxar | brlcad: Yeah, true. |
| 15:20.06 | CBG | ruskie: but believe it or not, people DO! |
| 15:20.06 | kung | re |
| 15:20.17 | CBG | Humans are freaking CRAZY like that. |
| 15:20.29 | ruskie | nahh |
| 15:20.33 | CBG | They tend to put all sorts of odd words at the start of their sentences! |
| 15:20.33 | ruskie | it's just the english language |
| 15:20.36 | daxxar | brlcad: I'm not sure how to port the 'ticks'-design. It can't translate to frames - we're headless. Should it translate to a set timestep instead? |
| 15:20.39 | brlcad | daxxar: from what you said -- it really is a lot like implementing opengl (in terms of supporting execute()) |
| 15:20.49 | CBG | Like, "Humans", "They" and even "Like"! |
| 15:20.53 | blast007 | ruskie: other languages don't have capital letters? |
| 15:21.11 | CBG | Don't be silly, blast007. Of course they don't! |
| 15:21.16 | ruskie | blast007, other languages acctually have a differentiation between free and Free |
| 15:21.22 | CBG | Tu est stupide! |
| 15:21.23 | brlcad | daxxar: the client has a concept of ticks regardless of being headless -- it's one pass through the simulation loop |
| 15:21.31 | blast007 | ruskie: so does English |
| 15:21.41 | blast007 | could just call them "open software" |
| 15:21.42 | daxxar | brlcad: One call to doMotionUpdate() etc? Yeah. Perhaps use that instead. |
| 15:21.45 | ruskie | blast007, no |
| 15:21.48 | blast007 | since it's referring to "open-source" |
| 15:21.51 | ruskie | open != Free |
| 15:21.55 | brlcad | you could do fixed timestep as well, but I think that'd actually be more work |
| 15:22.00 | CBG | ruskie: says who? |
| 15:22.05 | daxxar | Hm. Wait, that could actually work pretty nicely. |
| 15:22.12 | CBG | one guy that just one day decided that? |
| 15:22.16 | ruskie | CBG, heard of m$ shared source program? |
| 15:22.23 | ruskie | that's considered open-source |
| 15:22.26 | brlcad | being able to run the bots with a modified bzfs that is decoupled from the real-time clock would be follow-on work |
| 15:22.33 | ruskie | yet it's not even close to being Free Software |
| 15:22.46 | brlcad | so you could run an entire CTF simulation with 4 on 4 or something, and have it run in 0.03s etc |
| 15:22.47 | daxxar | brlcad: Hehe, yeah, true. To simulate battles. :) |
| 15:22.54 | CBG | What the hell gives one man the right to use an existing word to define something TOTALLY different !? |
| 15:23.12 | ruskie | the same thing that gives you the right to biatch about it |
| 15:23.20 | brlcad | CBG: free will, he can do whatever he wants .. you don't have to agree or listen to him |
| 15:23.26 | Manu | blast007: lol |
| 15:24.13 | CBG | Then I disagree and if anyone says "free software" with any capitalisation, I'll take it as "software you don't pay for" because it is LOGICAL and I'm not a sucker that is easily brainwashed. :) |
| 15:24.26 | brlcad | daxxar: setting up the architecture/implementation so it's at least moving in that direction is pretty important as that's one of the points |
| 15:24.46 | daxxar | .. make execute() a wrapper for the update-loop, simply. But that would lead to an issue where the bot doesn't call execute() for a "long" period of time, and then the next call to execute() makes the bot do a *lot* of movement / turning / whatever. |
| 15:25.03 | brlcad | er, one of the important points of doing this -- one being allowing AI students to use the framework down the road for things like evolutionary computing |
| 15:25.41 | ruskie | CBG, gosh and you still play brainless FPS games... |
| 15:26.00 | brlcad | the short-term goal, though, is to have a bot api that players can write against that matches the robocode api (as translated to C++ or whatever) |
| 15:26.02 | CBG | You're entitled to your opinion too, ruskie, no matter how wrong it is!! :) |
| 15:26.13 | ruskie | :) |
| 15:26.14 | CBG | I play a variety of games - games that I enjoy. |
| 15:26.18 | Manu | ruskie, CBG be calmed :) |
| 15:26.22 | CBG | Games that pass the time. |
| 15:26.48 | brlcad | daxxar: yes, that's a minor problem though -- as that's how they programmed the bot |
| 15:26.50 | CBG | Games that are - now, wait for this, this is spectacular, are you ready? here we go - FUN! |
| 15:27.11 | CBG | If you find games like wesnoth fun, fine. Play that. |
| 15:27.16 | daxxar | brlcad: Do you think putting the world update loop in one thread and the bot in another, then just always looping the update loop, make the turnLeft() a wrapper for 'setTurnLeft(); while (getTurnRemaining() > 0) wait();' and execute a wrapper for a wait(); - could work? |
| 15:27.17 | brlcad | daxxar: kind of desireable even as it allows for bot behavior routines that are repetitious |
| 15:27.22 | CBG | I hated it, so I play games that I find fun. |
| 15:27.34 | brlcad | like animated dance sequences when a flag is captured .. |
| 15:27.40 | daxxar | Hehe =p |
| 15:27.55 | brlcad | seriously, someone will do that |
| 15:28.00 | Winny | ruskie, what is possibly more fun then arguing with the interwebz?? |
| 15:28.36 | CBG | intehwebz rox |
| 15:28.41 | Manu | brlcad: you are kidding, aren't you? :p |
| 15:29.04 | brlcad | Manu: heh, nope .. i'm sure if the api allows it, someone will do it .. guaranteed :) |
| 15:29.05 | ruskie | Winny, ow I don't know... reading a good book... |
| 15:29.06 | CBG | ~blast007++ |
| 15:30.21 | brlcad | daxxar: hm, that could possibly work though I'm not sure what exactly the threading buys you other than clean run-time separation |
| 15:30.24 | Manu | brlcad: yes, probably, I have in mind a dev ;) |
| 15:30.58 | brlcad | and for that, it would seem just as well to make that be the separation between the bot and the simulation loop (over a simple port protocol) |
| 15:31.42 | brlcad | so you don't need threading, it's basically process-level separation |
| 15:34.22 | daxxar | You mean a separate process that the bot runs in? Kindof like an extended bzrc that uses unix-sockets or something? |
| 15:34.32 | brlcad | daxxar: on that note, I like your milestone 1 about cleaning it up such that there's no gui-related code in the client, though stripping out the "bzrobots-specific stuff" may be premature (as that could all be reusable) |
| 15:34.56 | daxxar | Well, I'm probably using bzrobots as a starting point - so there's not much GUI to strip out ;-) |
| 15:35.01 | daxxar | I mean stuff like RCLink and such |
| 15:35.28 | brlcad | a whiteboard would be great right about now |
| 15:35.41 | daxxar | ^_^ |
| 15:36.39 | brlcad | as it stands now, you kick off bzrobots and it opens up a communications port where it can be fed commands that control the tank |
| 15:37.02 | brlcad | that much is all fine and dandy and wouldn't necessarily need to change (though it could if warranted by something better) |
| 15:37.38 | daxxar | Well, for something like RoboCode compatability it would need a whole more complex protocol. ;-) |
| 15:38.05 | brlcad | exactly my thoughts too -- and there's nothing wrong with entirely changing that protocol |
| 15:38.36 | brlcad | it's the nature of keeping it something that actually is interacted over a port so you really could write your own bot in whatever isoteric language if you know the bot communications protocol |
| 15:40.18 | brlcad | by process-level separation, I don't mean that there'd be two binaries -- you could still just invoke bzrobots feeding it a compiled robocode bot plugin, or via the swig interface for a given language -- it'd just connect to itself (fork, pipe, communicate) |
| 15:41.46 | brlcad | does that make sense? |
| 15:43.08 | daxxar | Yeah |
| 15:43.32 | *** join/#bzflag KTL (n=KTL@kotnet-149.kulnet.kuleuven.be) |
| 15:43.54 | daxxar | Does bzrobots build on win32? |
| 15:44.03 | daxxar | Couldn't find it in the vc8 solution file |
| 15:44.29 | brlcad | don't worry about them ;) |
| 15:44.35 | brlcad | they'll figure themselves out |
| 15:44.40 | brlcad | unless you're on win32 |
| 15:44.53 | daxxar | Not at the moment, left my workstation in Trondheim - so I'm only on Linux ;) |
| 15:45.02 | daxxar | Also, where should my stuff go? Somewhere like https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/src/bzscripted/ |
| 15:45.40 | brlcad | I was thinking that you'd work directly on bzrobots |
| 15:46.06 | daxxar | But what about the current version of bzrobots? Doesn't it serve it's own purpose? |
| 15:46.19 | daxxar | I wish McNabb was more online on IRC ;) |
| 15:46.37 | brlcad | the idea is to improve what we have, not have N discrete efforts :) |
| 15:46.52 | *** join/#bzflag a_temp_dist (n=a_temp_d@about/essy/alarming/a-temp-dist) |
| 15:46.57 | brlcad | it could be forked, but it's not really in production distribution yet so it can be changed |
| 15:47.15 | daxxar | But this is a majorly different direction than the current bzrobots, isn't it? |
| 15:47.21 | brlcad | but that's also why making it semi-compatible wouldn't be a bad idea (i.e. being able to telnet to a port to control tanks) |
| 15:47.36 | daxxar | Well, perhaps only in technicalities. |
| 15:48.32 | brlcad | yeah, only in technicalities -- the approach mentioned really just massively revamps that ascii communications protocol and adds a lot more (of optional infrastructure) |
| 15:48.34 | daxxar | The protocol could be in human readable format, assuming it's not enough traffic to make parsing it an overhead. |
| 15:49.45 | brlcad | acmcnabb's approach of making it simple tcp communications protocol was a good one I think .. it really does make the bot writer's job easy and is particularly useful for interactive testing (which allowing any language to be the driver) |
| 15:50.19 | brlcad | this addition really is beefing up the protocol so it can do and respond to everything that robocode api does |
| 15:50.49 | brlcad | and adding that C++ interface (minimally) .. swig interface would be even better, but I don't see that happening this summer |
| 15:50.55 | daxxar | But the current bzrobots calls the world update functions all the time, regardless of wether or not you want it. Isn't that the functionality an execute()-call should trigger? |
| 15:51.47 | brlcad | yeah, but you can change that aspect |
| 15:52.04 | brlcad | you have liberty to entirely redo/replace/change that protocol and how the run-loop behaves |
| 15:52.26 | brlcad | just keeping that simple constraint of being able to telnet to a port and feed commands |
| 15:52.59 | daxxar | But that allows for the player to 'leap' (i.e. teleport / cheat) from point a to point b, simply by doing setForward('arbitrary distance'); sleep('time that move *would* take'); execute(); |
| 15:53.25 | brlcad | i'd imagine that for an existing robocode bot converted to C++, you'd compile that as a plugin and bzrobots would simply connect to it's own port and run the plugin |
| 15:53.39 | daxxar | yeah, that I agree with |
| 15:54.36 | brlcad | actually that statement alone is probably the biggest overarching goal as I've seen it .. being able to "just" do that would be a major win |
| 15:54.49 | brlcad | not that "just" that is anything simple |
| 15:55.24 | daxxar | I don't understand |
| 15:55.45 | *** join/#bzflag SpazzyMcGee (n=Spazzy_M@client-82-14-64-195.brnt.adsl.virgin.net) |
| 15:55.51 | daxxar | I'm talking about a tank moving from point a to point b without touching any of the steps between a and b. |
| 15:56.25 | brlcad | er, and that wouldn't necessarily allow a player to teleport/cheat -- you'd have to write the simulation framework such that it actually does the actions stateful to what is physically possible via the simulation |
| 15:57.06 | brlcad | yeah, two topics -- i wasn't responding to the cheat comment |
| 15:57.18 | daxxar | Oh. :p |
| 15:57.34 | daxxar | Ah, yes, then I understand |
| 15:57.49 | daxxar | Okay, what do you envision 'setForward(500); sleep(500/speed); execute();' doing? |
| 15:57.58 | brlcad | i'm saying .. probably the "main goal" would be: to be able to take an existing robocode bot converted to C++, you'd compile that as a plugin and bzrobots would simply connect to it's own port and run the plugin |
| 15:58.16 | daxxar | I agree with that |
| 15:58.21 | brlcad | okay, great :) |
| 15:58.30 | daxxar | :) |
| 15:58.56 | brlcad | before answering that, what does "sleep(500/speed)" do per robocode spec? |
| 15:59.25 | daxxar | That's heavy pseudocode, I just mean 'delay further execution of my thread for the time it would take to move 500 units' |
| 16:00.20 | daxxar | I don't like putting the smoothness of the bots movements at the hands of the bot developer - i.e. not calling the game update code frequently enough. |
| 16:00.29 | brlcad | take just the simpler setForward(500); execute(); .. what do you see that doing? |
| 16:01.02 | daxxar | Per robocode spec, that moves at the current speed for 1 'tick' |
| 16:01.11 | daxxar | (to a max of 500 units) |
| 16:01.28 | brlcad | and if you execute() again? |
| 16:01.35 | daxxar | One more tick |
| 16:01.45 | brlcad | so, it sets a desired goal state |
| 16:01.49 | daxxar | Yes |
| 16:01.52 | daxxar | That's the nonblocking mode |
| 16:01.57 | brlcad | sure |
| 16:02.14 | daxxar | Sorry, I'll have to go AFK for a quick bit, help out my father. |
| 16:02.23 | brlcad | alright |
| 16:02.40 | brlcad | hmm.. likewise now that you mention it |
| 16:02.44 | brlcad | it is that day, isn't it |
| 16:06.23 | brlcad | so before I get too deep along this font manager path now that I have some momentum.. would anyone have any heartache over picking up ftgl (and freetype2) as a bzflag dependency, replacing the current bzflag font implementation with JeffM's better one? |
| 16:06.38 | brlcad | hm, maybe a good case for an svn branch given how much it touches |
| 16:08.54 | tupone | brlcad, rephrase |
| 16:10.59 | brlcad | daxxar: and to answer your question for whenever you get back .. any "sleeping" in the simulation loop would effectively be a no-op -- the tank would just sit their waiting, or would be no different than looping over setForward(); execute() for the time given .. those commands aren't blocking from what you've told me and if they were, then setForward would be effectively an execute() loop until it was done and sleep would just make the tank sit |
| 16:11.47 | brlcad | tupone: i've been working on the font system for a couple weeks now for a different purpose .. and in the process I've got a tool now that draws some strings in opengl |
| 16:12.01 | brlcad | using bz's font manager and related facilities, just like the client |
| 16:12.44 | brlcad | i've also got it working with a different font manager that jeff wrote (all of which are based on the manager interface jeff started) |
| 16:13.03 | daxxar | Hm, back again. |
| 16:13.20 | brlcad | that newer version uses ftgl for the font drawing implementation, actually uses TTF fonts (and/or whatever freetype can read) |
| 16:13.31 | brlcad | which just look amazing in comparison, quality-wise |
| 16:13.36 | tupone | ftgl is not supported on gentoo on this arch: arm ia64 m68k mips ppc-macos s390 sh sparc-fbsd |
| 16:13.51 | tupone | all the major one are supported. |
| 16:14.22 | brlcad | tupone: it's pretty small, it'd be sitting in src/other for the platform environments that don't have it during configure.. :) |
| 16:14.22 | tupone | speed? I knew it was slow if just put in |
| 16:14.46 | brlcad | i've been testing performance, I have metrics going for my interface |
| 16:14.55 | daxxar | brlcad: execute(); blocks until the update is done, but that's not much. |
| 16:14.56 | daxxar | AFAIK |
| 16:15.08 | tupone | damn slow |
| 16:15.22 | tupone | not alone, alone was very fast |
| 16:15.28 | brlcad | daxxar: i'm saying if setForward() was blocking.. and you only make blocking calls, then execute() does nothing ;) |
| 16:15.59 | daxxar | brlcad: Well, the non-blocking calls are called set* |
| 16:16.08 | daxxar | brlcad: setForward() - nonblocking, forward() - blocking |
| 16:16.09 | daxxar | iirc |
| 16:16.33 | daxxar | forward() is afaict the same as setForward(); then looping execute() until the desired distance is reached |
| 16:16.38 | brlcad | tupone: hm, i'm not seeing damn slow here .. at least until you scale up to about a thousand or more drawStrings |
| 16:16.48 | daxxar | The problem is that the RoboCode API allows for 'thinking time' before *each frame* - bzflag doesn't. |
| 16:16.56 | tupone | probably some GL related performance problem. If that works, with the good speed, I'm all for putting in |
| 16:17.12 | brlcad | daxxar: okay, that's what I thought .. then with that .. sleep() wouldn't really do anything other than loop over execute() and most |
| 16:17.43 | brlcad | tupone: how intensive bzflag with the fonts is unknown to me, which is why I was thinking a branch |
| 16:17.55 | daxxar | As I understand it, RoboCode is on some level turn-based - turns for all players are executed "simultaneously", but you have processing time before 'giving your move' to the simulation. |
| 16:18.03 | DTRemenak | brlcad: it's pretty heavy, actually |
| 16:18.04 | brlcad | tupone: when you talk about "alone", what do you mean? only freetype2? |
| 16:18.22 | tupone | alone, mean with just some example program |
| 16:18.31 | DTRemenak | every time there's an ansi code it breaks and draws a new string |
| 16:18.33 | tupone | that does no use GL intensively |
| 16:19.37 | DTRemenak | wouldn't surprise me at all to exceed a few hundred strings per frame |
| 16:19.38 | tupone | maybe switching settings too much on the GL machine is slowing it down |
| 16:20.05 | brlcad | yeah, a few hundred wouldn't surprise me, a thousand would though |
| 16:20.20 | DTRemenak | yeah, that's getting up there a bit :) |
| 16:20.57 | brlcad | tupone: it is certainly slower, can't deny that .. whether it matters to bz's level is the unknown right now |
| 16:21.27 | DTRemenak | tupone: jeff did some interesting caching iirc, which helps speed a good bit |
| 16:21.27 | brlcad | e.g. all of the ansi stuff would be unchanged.. heck, I'll have to merge it all in directly from the existing |
| 16:21.40 | tupone | brlcad, I did the porting, some times ago, and it was slow. I'm not an openGL guru though |
| 16:21.43 | brlcad | yeah, it tells ftgl to preload the textures |
| 16:22.00 | DTRemenak | he did mention that using ftgl "raw" was hella slow |
| 16:22.28 | brlcad | yeah, I tested all of the other font types that ftgl provides.. they were all 2x to 100x slower than the texturefonts |
| 16:22.32 | daxxar | .. Which is why a timestep-based system would be appropriate. One tick = e.g. 100ms, and if execution exceeds that time, raise onSkippedTurn() (like AdvancedRobot does) |
| 16:23.33 | daxxar | That also the only way I can see us actually implementing onSkippedTurn ;-) |
| 16:24.12 | tupone | just saying, that my porting was quick and fast (and bad) and I didn't change any of the FTGL code. If you are doing the same I hink you fail, if you are doing more, well, I think you can succeed |
| 16:24.25 | brlcad | daxxar: i'm all for that, and it's not really any different -- unthrottled, a tick is around 0.5 ms depending on cpu speed |
| 16:24.57 | brlcad | i'd just say make the tick really small, like one ms or ten |
| 16:25.35 | daxxar | brlcad: But then simple overhead like network communication could make the tick actually be too fast. |
| 16:26.04 | daxxar | So your code's execute() doesn't reach bzrobots before the turn is over |
| 16:26.13 | brlcad | tupone: I've not changed the ftgl code yet -- and did see a few points of improvement there, though probably fairly minor |
| 16:26.39 | brlcad | ftgl was spending most of it's time actually drawing the textures, and that's not going to get any faster save removing a few gl state calls |
| 16:26.44 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 16:26.53 | brlcad | maybe reduce the call-through hierarchy |
| 16:27.11 | brlcad | bz's was faster simply because it was blitting smaller textures |
| 16:27.14 | tupone | I mean probably the use of the openglgstate can save something. Dunno really |
| 16:27.49 | brlcad | well, sounds like a good case for making a branch then to test this theory :) |
| 16:27.58 | DTRemenak | yup |
| 16:27.59 | tupone | yep |
| 16:28.01 | brlcad | see how much it matters |
| 16:28.30 | brlcad | and if it is slower, does having fonts that look that much better make it worth it or not |
| 16:30.13 | tupone | well, slow I meant unplayable |
| 16:30.25 | brlcad | daxxar: that's a fundamental limitation, I wouldn't cripple the bots just because it might make the non-blocking stateful calls problematic |
| 16:30.39 | tupone | like 20-30 FPS |
| 16:31.12 | brlcad | daxxar: i see the simulation loop actually continuing regardless of calls to execute() ... execute() really just means, do the things I told you to do now |
| 16:31.20 | brlcad | tupone: and your normal fps is? |
| 16:31.24 | brlcad | is/was |
| 16:31.31 | tupone | about 80 |
| 16:31.35 | tupone | was |
| 16:31.43 | tupone | IIRC |
| 16:32.04 | daxxar | brlcad: Per RoboCode workings, I don't think it'll move you anywhere if you don't do execute() (or call a blocking function) |
| 16:32.06 | brlcad | so a .3 to .4 hit |
| 16:32.19 | tupone | I don't have anymore the source so I cannot test it :/ |
| 16:32.23 | brlcad | daxxar: sure, that's fine |
| 16:33.23 | brlcad | i'm saying if you had a really slow telnet/port/tcp/whatever connection .. the client is effectively sleeping until it receives an execute or blocking call |
| 16:33.42 | brlcad | so whether the even tick is .1 ms or 100 ms doesn't really change |
| 16:33.53 | brlcad | just changes the amount of work that will get done |
| 16:34.33 | daxxar | But then each execute(); should make the bot do the exact same amount of work |
| 16:34.45 | brlcad | yep |
| 16:35.10 | daxxar | And it should in practice require a bot to call one execute() for each time_step ms. (e.g. 100ms) |
| 16:35.22 | brlcad | i think we're saying the same things, unless i'm misunderstanding something .. |
| 16:35.29 | daxxar | (Or one blocking call) |
| 16:35.31 | brlcad | it's really just how long that timestep is |
| 16:36.36 | daxxar | RoboCode spec also dictates that calling execute() too late 30 times or more equals a disqualification. :p |
| 16:37.03 | brlcad | well that gets to the simulation itself -- which is in bzfs' domain |
| 16:37.14 | daxxar | True 'nough. |
| 16:37.31 | brlcad | akin to idling on a field, the server might kick you |
| 16:37.34 | daxxar | execute(); shouldn't return until the server has sent a 'turn_over'-thing. |
| 16:38.13 | brlcad | erm, you can't guarantee that -- delay to the server is entirely variable |
| 16:38.19 | brlcad | could be 2ms could be 2000ms |
| 16:38.33 | brlcad | and everything in between |
| 16:38.44 | daxxar | Well, still. while (true) execute(); shouldn't send more than one execute every timestep |
| 16:38.55 | daxxar | :-/ |
| 16:39.07 | brlcad | sure |
| 16:39.28 | brlcad | you're still going to have your "client run-loop" that is the bot client's simulation loop |
| 16:39.48 | brlcad | and it can't do any more than the gui client does |
| 16:40.43 | daxxar | But are you saying execute() should return immediately? |
| 16:41.31 | brlcad | what does robocode do? :) |
| 16:41.51 | daxxar | public void execute() |
| 16:41.52 | daxxar | <PROTECTED> |
| 16:41.56 | daxxar | I believe it 'blocks' |
| 16:42.13 | brlcad | actually, that means it's non-blocking |
| 16:42.37 | brlcad | to me at least .. once they've started means it basically returns after a tick |
| 16:42.52 | brlcad | as actions will be queued up |
| 16:43.00 | daxxar | http://robocode.sourceforge.net/docs/robocode/robocode/AdvancedRobot.html#onSkippedTurn(robocode.SkippedTurnEvent) |
| 16:43.16 | daxxar | Yeah, execute() returns after a tick |
| 16:43.25 | daxxar | <PROTECTED> |
| 16:43.44 | daxxar | See this example from the robocode api docs: http://rafb.net/p/YclsZj74.html |
| 16:44.11 | daxxar | That should not, imo, *spam* "execute"-messages to the communications port - it should send one each timestep |
| 16:44.23 | brlcad | right |
| 16:44.49 | brlcad | and even if they do, it'll only do one execute per tick |
| 16:45.09 | brlcad | and N blocking messages if they can complete in time per tick |
| 16:46.03 | brlcad | http://rafb.net/p/YclsZj74.html is a very good example to work with -- even valid c++ ;) |
| 16:46.03 | daxxar | What does that last sentence mean? |
| 16:46.09 | daxxar | (before the paste) |
| 16:46.30 | daxxar | Hehe, yeah ;-) |
| 16:48.14 | brlcad | if you did forward(0.01); for example .. and that conceivably only takes 2 ms of simulation time and you have a 50 ms tick time frame .. then conceivably, calling that 25 times is no different than calling forward(.25); just once |
| 16:48.40 | brlcad | the difference is that you can interleave other actions |
| 16:49.20 | brlcad | that will matter for things like dodging, aiming, and other fine-tuned skills |
| 16:50.14 | daxxar | Ah, right |
| 16:50.17 | daxxar | Now I understand. :-) |
| 16:50.40 | daxxar | But doing all these intricate tick-calculations in a different process than the actual client code can get .. messy? |
| 16:53.39 | *** join/#bzflag bujkyl (n=heath@c-71-207-245-33.hsd1.al.comcast.net) |
| 16:59.02 | brlcad | only the client needs to do that |
| 17:00.11 | brlcad | tupone & DTRemenak: just for eyecandy -- both calling drawString 1002 times/frame: http://bzflag.bz/tmp/bzfonts.png and http://bzflag.bz/tmp/ftglfonts.png |
| 17:00.37 | brlcad | and humorously enough both using the same font |
| 17:01.17 | brlcad | (profont) |
| 17:02.25 | DTRemenak | scaled up beyond the largest one we ship though, so not really a fair quality comparision :) |
| 17:03.49 | daxxar | brlcad: Hm, yes, if execute() sends 'execute'-command without blocking or making sure the turn passes. |
| 17:03.49 | DTRemenak | 5% difference or so, not bad |
| 17:04.01 | brlcad | true, though the point wasn't so much for the numbers as the look |
| 17:05.02 | DTRemenak | FM always prefers scaling down, so forcing it to scale up is not exactly fair for quality :) |
| 17:06.06 | brlcad | that was just because there's font size mismatches |
| 17:06.14 | DTRemenak | yeah |
| 17:06.17 | brlcad | font size 16 to bz is very different from size 16 to ftgl |
| 17:06.22 | brlcad | s/ftgl/freetype/ |
| 17:06.33 | DTRemenak | we don't do "points" :) |
| 17:06.51 | brlcad | so to make the blit textures match up, I have to increase the bz size usually by about 2x |
| 17:07.04 | brlcad | that's where that 2x came from that I didn't realize at first .. |
| 17:07.10 | DTRemenak | ah |
| 17:07.17 | brlcad | so they really are pretty close |
| 17:07.30 | brlcad | still slower, but closer |
| 17:08.45 | brlcad | http://bzflag.bz/tmp/bzfonts2.png |
| 17:09.16 | brlcad | still looks more assish in comparison imho to the ftgl version, save for the fps text |
| 17:10.02 | DTRemenak | how does it look with one of the other fonts? |
| 17:10.33 | DTRemenak | profont is a bit odd (not that I doubt ftgl will produce better results anyway) |
| 17:10.34 | brlcad | like which? |
| 17:10.49 | DTRemenak | the others are all autogenerated; profont was done by hand, iirc |
| 17:11.30 | DTRemenak | I dunno, pick one :) toga sans maybe |
| 17:11.48 | brlcad | toga! toga! toga! |
| 17:11.57 | DTRemenak | hehe |
| 17:12.50 | brlcad | hmm, how about vera .. can't find a ttf for toga |
| 17:13.09 | DTRemenak | and if you want to be a bit harder on bz's side, use the 12's instead of the 16's, they're rendered differently (crappierly) by fonttool |
| 17:13.19 | DTRemenak | sure |
| 17:17.27 | DTRemenak | if you want to do a really thorough review (not that I think it's necessary), comparing each of the fonts at 12 (unscaled snapped), 14 (scaled), and 16 (unscaled AA) would do the trick |
| 17:18.45 | brlcad | http://bzflag.bz/tmp/bzgl_vmb.png and http://bzflag.bz/tmp/ftgl_vmb.png |
| 17:19.34 | brlcad | for that font, bz's unaliased looks better for the 8pt font |
| 17:19.41 | DTRemenak | hm, ftgl is exhibiting some aa too |
| 17:19.43 | DTRemenak | yeah |
| 17:19.43 | brlcad | er aliased |
| 17:20.11 | DTRemenak | is there a way to turn that off? we had complaints using AA fonts at scoreboard sizes |
| 17:20.16 | brlcad | there's probably a way to get ftgl to do aliased, but I only looked for all of 5min last night |
| 17:20.24 | DTRemenak | heh, ok :) |
| 17:20.35 | tupone | brlcad, me, more then the beautifulness of the font, that is a plus for me, I'm interested on the extendibility for utf-8 |
| 17:20.41 | brlcad | i mean, freetype supports it .. it's just a matter of how to force it |
| 17:21.12 | DTRemenak | tupone: both systems are easily extendable |
| 17:21.13 | brlcad | yeah, this would allow unicode fonts and fairly arbitrary resolutions |
| 17:21.22 | tupone | so , even for the same look, I'm for ftgl at all |
| 17:21.53 | tupone | DTRemenak, I'm blind then. I cannot see on the current font system |
| 17:22.06 | DTRemenak | there's nothing stopping our current fontmanager from rendering every character under the sun, except that we keep passing ascii strings to it |
| 17:22.24 | tupone | ascii? |
| 17:22.36 | brlcad | there needs to be an AA option in BZ similar to what is done for the OS .. alias below [specified font size], AA otherwise |
| 17:22.38 | DTRemenak | 7-bit characters |
| 17:22.57 | DTRemenak | tupone: font storage is arbitrary, you can specify any characters you want in the png and fmt files |
| 17:22.59 | tupone | I'm talking about UTF-8, not ascii |
| 17:23.17 | DTRemenak | I know |
| 17:23.27 | DTRemenak | bzflag itself does not pass utf-8 strings anywhere |
| 17:23.30 | DTRemenak | so we'll never render them |
| 17:23.38 | tupone | but it can be done |
| 17:23.41 | DTRemenak | yes |
| 17:24.20 | brlcad | also, just for info .. that window screenshot is a "bzflag window", only using libPlatform setup .. good stuff :) |
| 17:24.22 | tupone | and you want to support arbitrarly 2**(put a number here) characters |
| 17:24.26 | tupone | ? |
| 17:24.28 | DTRemenak | currently they're not in the font maps (except for profont), just to keep the size down. regenerating them all to include a full table would take all of half an hour. |
| 17:25.05 | DTRemenak | tupone: we can support an arbitrary number of characters, yes |
| 17:25.46 | tupone | with the current limits on texture memory usage. Great |
| 17:26.14 | DTRemenak | yeah |
| 17:26.38 | brlcad | daxxar: i think execute still needs to "block", but just for the remainder of the tick -- similar to how forward(0.1); would block for 2ms |
| 17:26.39 | DTRemenak | so that's not really something we "gain" by moving to ftgl, except that we don't have to regenerate the font tables to enable it |
| 17:26.53 | DTRemenak | ttfs are better in that sense |
| 17:27.18 | brlcad | yeah, ftgl still uses font tables, it just autogenerates them as needed from the ttf |
| 17:27.19 | daxxar | brlcad: But I find calculating the 'remainder of the tick' from the other end of a comm port a bit .. tricksy? |
| 17:27.30 | brlcad | and only for whatever characters you ask it to |
| 17:27.49 | JeffM | so was the ttf stuff slower? |
| 17:28.18 | DTRemenak | JeffM: looks like your ttf stuff is "barely" slower...like 5% ish |
| 17:28.27 | brlcad | daxxar: shouldn't be too tricksy .. i'd imagine it'll be a little more obvious once you get blocking calls going |
| 17:28.45 | brlcad | it's not more tricky than dealing with blocking calls that take more than a tick's time |
| 17:28.51 | tupone | ftgl generates only the characters it needs |
| 17:29.02 | JeffM | cool |
| 17:29.03 | DTRemenak | yes |
| 17:29.12 | JeffM | so well worth puting in? |
| 17:29.21 | DTRemenak | probably. brlcad is looking into it |
| 17:29.29 | brlcad | barely for some sizes .. others it's more or less -- depends on the font and sizes |
| 17:29.35 | JeffM | tupone, when I start up I make FTGL make a bunch of the characters and cache them |
| 17:29.39 | JeffM | for speed :) |
| 17:29.50 | brlcad | JeffM: yeah, I'm looking to stuff it into a branch and see what the performance looks like |
| 17:29.54 | JeffM | I have it generate a premade string with the cmost common |
| 17:30.14 | JeffM | fun |
| 17:30.17 | brlcad | aside from it being just a massive "patch", I need a playground to work on while it's merged in |
| 17:30.38 | JeffM | there would be one way to make it faster then current font setup |
| 17:30.45 | JeffM | chache all the string draws |
| 17:30.47 | brlcad | JeffM: surprisingly, that doesn't really save a whole lot of time from some tests I ran |
| 17:30.48 | tupone | but I don't see why that is a big improvement. Is'n ftgl already caching as it needs them, so the penalty would be only at the startup? |
| 17:31.00 | JeffM | and there color and postion then draw all the same font at the same time |
| 17:31.03 | JeffM | tupone, yeah just startup |
| 17:31.31 | JeffM | mostly so it won't go an allocate another large texture chunk when running |
| 17:31.57 | daxxar | The game client would have to send 'tick_duration' as it initiates the communication, and 'tick_start' each time a tick starts? |
| 17:32.02 | tupone | hmm, well, time is over. Bye :/ |
| 17:32.04 | brlcad | i did get a whooping 5% or so performance on not calling Advance() for every drawString() to compute and return the length |
| 17:32.38 | daxxar | Wouldn't need an 'execute' protocol message, it could just do whatever it was told at the end of each tick - and have a nop/stop/whatever-message to make it not do anything at all. |
| 17:32.43 | brlcad | given all of the calls I was making and most of the calls in bz care about the length beforehand, not after |
| 17:32.44 | JeffM | yeah that basicly draws it twice ish |
| 17:32.55 | JeffM | that could be a good optimisation |
| 17:33.16 | JeffM | changing the text drawing callers to minimise font swaps would help too |
| 17:33.25 | brlcad | i did add that -- didn't buy much, but it was a minor 5% or so for one test case |
| 17:33.33 | JeffM | still something |
| 17:33.58 | brlcad | funny how much slower all of the other ftgl font types are though .. practically useless |
| 17:34.56 | JeffM | who sticked Winny's post? |
| 17:35.08 | JeffM | the other types are for very specific situations |
| 17:35.10 | brlcad | daxxar: the bot code should be oblivious to ticks -- your bot simulation loop will obviously need to keep track of it as that's what the simulation loop is |
| 17:35.13 | JeffM | and cards |
| 17:35.38 | daxxar | brlcad: Ugh, I'm a bit confused as to what element is what. |
| 17:35.56 | brlcad | so long as the behavior is as close to matching robocode (so existing bots can run un-modified), it shouldn't matter much |
| 17:36.09 | brlcad | daxxar: yeah, .. need a freaking white board :) |
| 17:36.45 | daxxar | Yeah, that's the issue. I'm trying to find some architecture that allows robocode bots to run and actually have the same behaviour. |
| 17:37.03 | brlcad | then we're at least towards the same goal ;) |
| 17:37.09 | daxxar | API compliance is no problem, behaviour compliance is a pain |
| 17:37.30 | brlcad | behavior within reason -- where it makes sense in bz-terms |
| 17:38.04 | brlcad | some things like radar visibility could be a bit different as bz doesn't presently have "scan zones" |
| 17:38.26 | daxxar | Also, RoboCode supports view ('radar') and turret in different directions. |
| 17:38.29 | brlcad | effectively takes 0 time to scan 360, where robocode simulator takes several ticks iircs |
| 17:39.20 | daxxar | And turret is independent of movement |
| 17:39.21 | brlcad | yeah, so bots will have different behaviors with the same calls .. since turning a turret in bz turns the tank too |
| 17:39.50 | brlcad | that much is fine |
| 17:40.09 | brlcad | basically just means a turret turn call and a tank turn call do the same thing |
| 17:40.29 | daxxar | That will effectively mean that we can't expect usable AI from the RoboCode community, won't it. |
| 17:40.38 | brlcad | if bz ever decouples the turret, that could be separated |
| 17:40.47 | brlcad | not necessarily |
| 17:40.58 | brlcad | some things will obviously behave differently |
| 17:41.48 | brlcad | alternative is to make the turrent turn call throw an exception/fault of some sort |
| 17:42.10 | brlcad | dont' know if robocode has a means for a turret turn to "fail", if it does, then just use that |
| 17:43.00 | daxxar | Seems not, just for a move to fail. |
| 17:43.11 | daxxar | Not even for a turn to fail - so we'll need to extend that |
| 17:43.25 | brlcad | DTRemenak: another thing ftgl buys us that bz doesn't have is kerning |
| 17:43.42 | brlcad | at least.. semi-automatic kerning |
| 17:43.51 | daxxar | Oh, wait, I think onHitWall is for turning too |
| 17:44.03 | JeffM | SpazzyMcGee, you around? |
| 17:44.29 | brlcad | daxxar: yeah, that's one of the (few) cases where the api can be extended or outright changed since bz is fundamentally different |
| 17:44.31 | SpazzyMcGee | hi |
| 17:44.40 | brlcad | turret, radar, and object visibility |
| 17:45.07 | brlcad | er, as well as 3D, jumping, different weapons, ... hmm :) |
| 17:45.26 | brlcad | daxxar: that's another good point -- only worry about 2D maps for now :) |
| 17:45.27 | daxxar | ^_^ |
| 17:45.44 | brlcad | unless you just find yourself with an abundance of time and need extra milestones |
| 17:45.57 | DTRemenak | bbbbut jumping is important! :P |
| 17:52.00 | daxxar | Hmm |
| 17:57.24 | daxxar | brlcad: A mockup at http://rafb.net/p/Haqajt42.html |
| 17:58.10 | daxxar | Not 100% certain yet how that would work with multiple small blocking moves during one tick, e.g. |
| 17:58.43 | brlcad | not clear to me what those comments are supposed to mean |
| 18:00.39 | brlcad | particularly the sleeps.. there really shouldn't be any sleeps I would think, except maybe in the client simulation loop but certainly not in the bot code plugins |
| 18:00.42 | brlcad | and that's a big maybe |
| 18:02.36 | brlcad | you're going to have to maintain a bot state in the simulation loop that records all of the various possible goal-oriented actions (like turn 90 degrees) |
| 18:03.49 | brlcad | a call like setTurnRight(90) to me is just a command getting set in the simulation loop for that bot that says either turn 90 degrees or turn to whatever that resulting degree angle would be .. just sets the state/goal, nothing more |
| 18:04.43 | brlcad | execute then performs actions that are on that goal stack (like turning) for a given tick |
| 18:06.04 | brlcad | from that perspective, it is a blocking call and will always take up to whatever the tick timeframe is (though possibly less if/when/as the goals are reached) |
| 18:06.39 | *** join/#bzflag [dmp] (n=dennis@koderen.dk) |
| 18:07.18 | daxxar | I'm just eatin' a meal, I'll look over what you've said when I get back |
| 18:07.32 | brlcad | i have to head out myself |
| 18:08.02 | brlcad | sounds like you might be saying the same thing.. the sleep's just seem worrisome |
| 18:09.07 | brlcad | having client commands to set/query the tick duration would be interesting -- would be useful to know if robocode has parameters for controlling the simulation loop itself or whether that's all hard-coded |
| 18:10.04 | brlcad | having the client text-protocol match the robocode names would be helpful too :) |
| 18:12.19 | brlcad | so each call really just becomes a translation to N text commands being sent to the port (e.g. setAhead(100); becomes simply "setAhead 100", similarly for all ()'s) |
| 18:12.20 | *** join/#bzflag LongDon (n=LongDon@host-091-096-133-252.ewe-ip-backbone.de) |
| 18:12.56 | *** join/#bzflag TD-Linux (n=TD-Linux@about/essy/indecisive/TD-Linux) |
| 18:15.24 | Winny | have fun |
| 18:31.38 | *** join/#bzflag ducatiwannabe (n=ducwan@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 18:33.34 | *** join/#bzflag ruskie (i=ruskie@sourcemage/mage/ruskie) |
| 18:35.59 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 18:35.59 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 18:36.52 | *** join/#bzflag ddubs (n=ducatiwa@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 18:39.29 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 18:39.49 | JeffM | yay for cheap tires on the interweb :) |
| 18:42.50 | *** part/#bzflag ddubs (n=ducatiwa@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 18:43.40 | *** join/#bzflag ducatiwannabe (n=ducwan@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 18:44.38 | *** part/#bzflag SpazzyMcGee (n=Spazzy_M@client-82-14-64-195.brnt.adsl.virgin.net) |
| 18:51.05 | WinnyAFK | hehe, my dad saved 50$ on his tires... but it took 45$ of gas to go get them :p |
| 18:55.02 | daxxar | G'bye, brlcad. =) |
| 18:56.11 | daxxar | brlcad: For when you get back; How do you suggest I get some blocking-ish action from the execute()? |
| 18:58.55 | JeffM | these are going to be shiped UPS to me |
| 19:04.08 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 19:06.07 | *** join/#bzflag Electric1lf (n=dbharris@76.64.129.247) |
| 19:09.05 | *** join/#bzflag Tedius (n=Tedius@76.205.120.159) |
| 19:10.21 | *** join/#bzflag Kream (n=john@ip68-105-100-105.sd.sd.cox.net) |
| 19:47.22 | *** join/#bzflag jwir3 (n=scottj@c-66-41-249-30.hsd1.mn.comcast.net) |
| 19:49.30 | *** join/#bzflag RIP (i=5144da81@gateway/web/cgi-irc/zeebrothers.net/x-c93f0e5ec92e8fa3) |
| 19:51.50 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 19:51.50 | *** mode/#bzflag [+v tupone] by ChanServ |
| 19:56.32 | *** join/#bzflag SpazzyMcGee (n=Spazzy_M@82.14.64.195) |
| 20:07.26 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 20:08.02 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 20:14.19 | *** join/#bzflag Flash (n=jwmelto@unaffiliated/flash) |
| 20:39.46 | *** join/#bzflag ddubs (n=ducatiwa@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 20:45.02 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 20:58.29 | *** join/#bzflag wert613 (n=shhh@adsl-76-208-13-62.dsl.sbndin.sbcglobal.net) |
| 20:58.33 | *** part/#bzflag ddubs (n=ducatiwa@adsl-68-95-234-131.dsl.rcsntx.swbell.net) |
| 20:58.37 | wert613 | heya Tedius |
| 20:59.27 | *** mode/#bzflag [+o JeffM2501] by ChanServ |
| 20:59.45 | *** mode/#bzflag [+o blast007] by JeffM2501 |
| 21:00.03 | *** join/#bzflag Zack (n=Zack@static.207-5-115-85.microlnk.com) |
| 21:00.09 | *** mode/#bzflag [-o JeffM] by JeffM |
| 21:00.15 | Zack | DUDE |
| 21:00.26 | JeffM | dude? |
| 21:00.40 | Zack | i just figured out the opengl problem |
| 21:00.44 | wert613 | hows it going guys? |
| 21:00.49 | Zack | i was having with bzflag |
| 21:01.01 | Zack | see |
| 21:01.03 | Zack | what i did |
| 21:01.14 | Zack | is i kept jacking down the quality |
| 21:01.23 | Zack | and it kept getting slower |
| 21:01.32 | Zack | until i did like 300x240 |
| 21:01.38 | Zack | then it went fast |
| 21:01.45 | Zack | using software opengl |
| 21:02.12 | Zack | (this is on a LCD with optimal rez at 1440x900 mind you) |
| 21:02.15 | JeffM | screen size is the largest performance thing for software |
| 21:02.20 | JeffM | what video card do you have? |
| 21:02.28 | Zack | ATI Xpress 200m |
| 21:02.31 | Zack | so |
| 21:02.38 | Zack | i went from forum to forum |
| 21:02.47 | JeffM | no drivers from ATI for it? |
| 21:02.50 | Zack | and they all told me my opengl was working just fine |
| 21:03.07 | JeffM | what OS? |
| 21:03.09 | Zack | umm |
| 21:03.17 | Zack | windoze xp |
| 21:03.24 | Zack | no fglrx for 200m |
| 21:03.29 | Zack | anyway |
| 21:03.32 | JeffM | wait |
| 21:03.40 | JeffM | FGLRX is for linux |
| 21:03.43 | Zack | ik |
| 21:03.47 | JeffM | if your on XP, there are ATI drivers |
| 21:03.53 | JeffM | you make no sense |
| 21:03.58 | Zack | thats why im NOT using linux with BZ |
| 21:04.00 | JeffM | are you using the drivers from ATI |
| 21:04.08 | Zack | because you keep interupting me |
| 21:04.12 | Zack | OK |
| 21:04.19 | a_meteorite | ... wtf? |
| 21:04.26 | Zack | I'm using catalsyt 7.4 |
| 21:04.32 | Zack | on Windows XP |
| 21:04.36 | Zack | on the 200m |
| 21:04.54 | Zack | and INIT recognized my hardware opengl driver |
| 21:05.09 | Zack | (as a few hacks that people gave me on other ircs told me) |
| 21:05.28 | Zack | and it defaulted to low quality |
| 21:05.30 | CBG | you can write more than 5 words per line, if you like. |
| 21:05.50 | JeffM | yeah it's not a fast card, so that would be the setting we can get more then 20 fps at |
| 21:05.53 | eTangenT | k, I vote to remove Pythonian from list server |
| 21:05.56 | JeffM | tho our test isn't great |
| 21:05.59 | eTangenT | the bots on there are terrible |
| 21:06.02 | eTangenT | and they keep going NR |
| 21:06.04 | Zack | so i was getting 1-2fps |
| 21:06.09 | Zack | @ 1440x900 |
| 21:06.23 | a_meteorite | eTangenT: too bad bzflag isn't a democracy :( |
| 21:06.27 | Zack | so i turned smoothing dithering ect off |
| 21:06.45 | blast007 | Zack: did you try just... lowering the resolution? |
| 21:06.46 | Zack | and i got about 1/4 -1/2 fps |
| 21:06.56 | Zack | just WAIT you guys |
| 21:07.00 | blast007 | yeah, that's probably going to make it slower |
| 21:07.14 | blast007 | newer cards do some of the older stuff slower |
| 21:07.36 | JeffM | like we said you can type more on one line |
| 21:07.38 | Zack | so what i did is i lowerd it to an insanly low resolution of 300x240 |
| 21:07.39 | JeffM | this isn't an IM |
| 21:10.30 | Zack | so then i was getting about 40 fps with everything all the way down at 300x240@8bit (my diagnostics told me i my hardware didnt support this with accel so i was at software rendering at this point) (i was still on the menu at this point) so I went to a server and then i went way down to 2 fps again so i played around in my insanly slow invironment |
| 21:11.10 | blast007 | did you fix it? |
| 21:11.18 | blast007 | sounds like it was using software rendering |
| 21:11.22 | Zack | JUST WAIT! |
| 21:11.27 | blast007 | ... |
| 21:11.38 | eTangenT | a_meteorite: I also got autokicked for TKing without ever having TKed. |
| 21:11.39 | Zack | your asking questions im about it answer |
| 21:11.39 | eTangenT | :-\ |
| 21:11.49 | a_meteorite | eTangenT: blame the poor owner |
| 21:11.54 | blast007 | Zack: all I want is a yes or a no |
| 21:12.00 | blast007 | did you fix it? |
| 21:12.08 | blast007 | if yes, then good, glad it works |
| 21:12.10 | JeffM | your giving us an answer? to what? |
| 21:12.18 | JeffM | what is the question? |
| 21:12.30 | a_meteorite | my eyes are bleeding from reading |
| 21:13.06 | blast007 | JeffM: it was probably "What is one example of why summer break is bad?" |
| 21:13.43 | Zack | so i kept getting auto kicked for high latency (aka - lag from high process time per frame, NOT internet's fault) so i found a server that had no autokick as well as no players, so i thought i would get to play around here |
| 21:14.10 | JeffM | are you just telling us this to be your blog? |
| 21:14.14 | JeffM | what is the point here man? |
| 21:14.28 | JeffM | and don't jus say "wait" |
| 21:14.38 | JeffM | lead off with a simple explanation. |
| 21:15.30 | JeffM | instead of the word "dude" and an asumption that we all know what "THE" open gl problem is |
| 21:15.40 | Zack | so i found to my surprise (and delight) that when i changed to 1024x768x32 (so i could render in hardware again) and turned texturing on i was getting excess of 300 fps |
| 21:16.11 | blast007 | right, so you were running at 8bit |
| 21:16.11 | JeffM | umm great |
| 21:16.11 | blast007 | which made it go into software |
| 21:16.11 | Zack | so i went to native resoulution in 32 bit with everything on |
| 21:16.11 | blast007 | 32bit made it use hardware |
| 21:16.19 | Zack | no if you were reading |
| 21:16.25 | Zack | intead of asking questions |
| 21:16.32 | Zack | 8 bit sw made it go faster |
| 21:16.33 | JeffM | you made no sense |
| 21:16.41 | blast007 | o.O |
| 21:16.42 | JeffM | how could we NOT ask questions |
| 21:16.50 | *** join/#bzflag rob1n (n=emp@unaffiliated/rob1n) |
| 21:16.52 | blast007 | you just said it went faster with 32bit |
| 21:16.54 | Zack | but i had it in LOW qualtiy |
| 21:17.04 | blast007 | okay, why do we care? |
| 21:17.04 | JeffM | yeah that'll turn blending off |
| 21:17.16 | JeffM | and maybe put you in non depth buffer |
| 21:17.18 | *** part/#bzflag wert613 (n=shhh@adsl-76-208-13-62.dsl.sbndin.sbcglobal.net) |
| 21:17.20 | JeffM | THAT will go hella slow |
| 21:17.30 | JeffM | yeah what exactly are you trying to explain here? |
| 21:17.33 | Zack | i did a COMBINATION of high AND 32 bit |
| 21:17.41 | blast007 | ok |
| 21:17.42 | JeffM | ok great |
| 21:17.46 | JeffM | whopty freaking do |
| 21:17.47 | Zack | that HIGH quality is WAY faster than LOW quality |
| 21:17.52 | blast007 | yeah |
| 21:17.52 | JeffM | how is that "THE" open GL problem |
| 21:17.54 | JeffM | yeah that's common |
| 21:17.55 | blast007 | you didn't listen apparently |
| 21:17.57 | JeffM | as we tried to tell you |
| 21:18.04 | Zack | its already fixed |
| 21:18.05 | JeffM | newer cards don't do the low quality stuff well |
| 21:18.07 | blast007 | I had said that the older stuff can run slower on new hardware |
| 21:18.22 | Zack | so why is low the defualt? |
| 21:18.25 | JeffM | modern cards are optimised for the higher |
| 21:18.26 | JeffM | it isn't |
| 21:18.28 | blast007 | it's not |
| 21:18.32 | Zack | it really confused me |
| 21:18.33 | JeffM | it's just poor testing code |
| 21:18.44 | JeffM | the inital quality test is a fast check |
| 21:18.48 | JeffM | it' ain't great |
| 21:18.54 | JeffM | that's why you can change it |
| 21:19.01 | Zack | yeah |
| 21:19.01 | Zack | right |
| 21:19.06 | Zack | it took me 30 minutes |
| 21:19.12 | JeffM | great, good for you |
| 21:19.15 | Zack | just to navigate the menu at the speed i was going |
| 21:19.35 | Zack | so i coulndt do fast changes |
| 21:19.38 | blast007 | with my Intel 855, it knows to use High by default though ;) |
| 21:19.43 | JeffM | yeah ATI cards do suck in many ways |
| 21:19.52 | Zack | what are you guys smoking |
| 21:19.55 | Zack | ati is the BOMB |
| 21:20.01 | JeffM | not really |
| 21:20.05 | Zack | yeah |
| 21:20.10 | JeffM | they don't suport a lot of the modes well |
| 21:20.15 | Zack | nvidia just likes to make insane cards |
| 21:20.20 | JeffM | and as you've seen it's slower at the lower quality modes |
| 21:20.22 | a_meteorite | nVidia has better linux support |
| 21:20.24 | JeffM | when it SHOULD be faster |
| 21:20.26 | JeffM | indeed |
| 21:20.30 | Zack | no |
| 21:20.33 | JeffM | nvidia has drivers for nearly all it's chipsets |
| 21:20.38 | JeffM | ATI just a few |
| 21:20.38 | Zack | the 9250 works out of the box |
| 21:20.45 | a_meteorite | 9250 is old |
| 21:20.47 | JeffM | very |
| 21:20.52 | Zack | no proprietary drivers |
| 21:20.57 | Zack | 9250 is awesome |
| 21:21.01 | JeffM | the ATI drivers are propritary |
| 21:21.07 | Zack | YEAH |
| 21:21.11 | Zack | thats my point |
| 21:21.13 | JeffM | DRI just happens to support some hardware accel on some ATI cards |
| 21:21.21 | Zack | jeasus are you guys stoners |
| 21:21.22 | JeffM | DRI does not do it all, for all cards |
| 21:21.31 | JeffM | no, your just poorly informend |
| 21:21.32 | Zack | DRI does up to 9250 |
| 21:21.39 | Zack | 9300+ needs fglrx |
| 21:21.45 | JeffM | if you can't have a civil conversation I'll have to ask you to leave |
| 21:21.53 | JeffM | many cards doo |
| 21:22.01 | JeffM | the entire 9k series is wicked old |
| 21:22.10 | Zack | so my point is that 9250 is very good |
| 21:22.16 | Zack | since it doesnt need fglrx |
| 21:22.17 | JeffM | not really |
| 21:22.20 | blast007 | no, it's not |
| 21:22.22 | JeffM | it's a slow card |
| 21:22.23 | JeffM | I had one |
| 21:22.24 | Zack | and fglrx doesnt support it |
| 21:22.26 | Zack | no |
| 21:22.27 | JeffM | sold it to blast ;) |
| 21:22.30 | blast007 | ;) |
| 21:22.30 | JeffM | yes |
| 21:22.40 | Zack | its not slow |
| 21:22.44 | blast007 | it's better than my Intel chipset, but not by much |
| 21:22.44 | JeffM | little 6600 beats that card all the time |
| 21:22.45 | Zack | if you get the right card |
| 21:22.57 | JeffM | IIRC that card dosnt' even do shaders |
| 21:23.03 | Zack | the GPU is good |
| 21:23.09 | JeffM | it's not shader 3 |
| 21:23.15 | Zack | just need a good card manufacurer |
| 21:23.20 | Zack | yeah its shader 2 |
| 21:23.23 | a_meteorite | that makes no sense |
| 21:23.23 | Zack | so what? |
| 21:23.28 | JeffM | and it's got some big time vertex buffer issues |
| 21:23.32 | blast007 | Zack: I have an nVidia 7900GTO. |
| 21:23.42 | blast007 | want to compare FPS? |
| 21:23.47 | Zack | Yeah and i have 8800gxtx |
| 21:24.00 | JeffM | the 9250 is a toy compared to modern cards |
| 21:24.02 | Zack | in linux games sure |
| 21:24.06 | JeffM | it was never top of the line |
| 21:24.13 | Zack | yeah |
| 21:24.24 | Zack | in agp 2x days |
| 21:24.25 | JeffM | it's a slowed down, disabled version of beter cards |
| 21:24.27 | Zack | it rocked |
| 21:24.34 | a_meteorite | we're no longer in agp 2x days |
| 21:24.37 | JeffM | no, the 98xx series was much better then it |
| 21:24.42 | JeffM | even the 97s |
| 21:24.45 | Zack | no you just need the right card |
| 21:24.49 | blast007 | ... |
| 21:24.52 | Zack | the 9250 GPU is FAST |
| 21:24.55 | JeffM | only 2 people made that card |
| 21:24.57 | JeffM | no it's not |
| 21:24.58 | Zack | the card by ati |
| 21:24.59 | JeffM | it's underclocked |
| 21:25.06 | Zack | EXACTLY |
| 21:25.15 | JeffM | and has pipes disabled |
| 21:25.16 | Zack | and if you get the right card that has the 9250 on it |
| 21:25.20 | Zack | exactly!!! |
| 21:25.24 | JeffM | so even OCing it, you can't get the same performace |
| 21:25.29 | Zack | your just proving me right |
| 21:25.32 | JeffM | cus it's got less pipes |
| 21:25.36 | Zack | no |
| 21:25.38 | JeffM | yes |
| 21:25.41 | Zack | you can get 24 |
| 21:25.49 | Zack | with the right card manufacturer |
| 21:25.57 | JeffM | yeah I'm done |
| 21:26.01 | JeffM | this isn't the place |
| 21:26.08 | JeffM | so you just came here to say you got BZ to work |
| 21:26.08 | JeffM | great |
| 21:26.09 | Zack | you guys have no idea what your talking about |
| 21:26.11 | JeffM | have ufun |
| 21:26.13 | a_meteorite | ... wtf? |
| 21:26.17 | JeffM | yeah we are all idots |
| 21:26.18 | JeffM | bye now |
| 21:26.19 | Zack | yeah |
| 21:26.41 | Zack | bye |
| 21:26.49 | Zack | (tap tap tap) |
| 21:26.56 | Zack | ...bye now... |
| 21:27.01 | Zack | lol |
| 21:27.06 | a_meteorite | this isn't IM |
| 21:27.09 | CBG | cya!! |
| 21:27.18 | Zack | cant even figure out how to quit his irc?? |
| 21:27.30 | Zack | yeah |
| 21:27.31 | a_meteorite | we don't need to know every step of your life or process of thought |
| 21:27.33 | Zack | BYE jeff |
| 21:27.36 | CBG | What OS? |
| 21:27.40 | Zack | me? |
| 21:27.43 | *** mode/#bzflag [+o tupone] by ChanServ |
| 21:27.46 | blast007 | tried close the window...? |
| 21:27.52 | CBG | Zack: No, Zack. |
| 21:28.10 | JeffM | no, I was asyinhg you should leave, since We are all idiots, and this is our channel |
| 21:28.11 | JeffM | bye now |
| 21:28.11 | *** kick/#bzflag [Zack!n=atupone@pdpc/supporter/active/Tupone] by tupone (tupone) |
| 21:28.19 | JeffM | thank you tupone |
| 21:28.22 | tupone | :) |
| 21:28.30 | a_meteorite | my eyes stopped bleeding :) |
| 21:29.04 | *** part/#bzflag LongDon (n=LongDon@host-091-096-133-252.ewe-ip-backbone.de) |
| 21:31.03 | JeffM | heh, 24 pipes, more like 1 |
| 21:31.10 | blast007 | heh |
| 21:31.31 | JeffM | it had one texture unit and 1 vertex unit |
| 21:31.37 | JeffM | 1/2 of the parent chip |
| 21:32.11 | JeffM | performs out the same as a 4mx |
| 21:32.15 | JeffM | sad |
| 21:33.21 | blast007 | JeffM: not if you get it from a good manufacturer!!!!!111one |
| 21:33.35 | JeffM | heh |
| 21:33.50 | JeffM | your choices are ATI... or ATI |
| 21:34.00 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 21:34.02 | a_meteorite | really! I never knew! |
| 21:34.04 | JeffM | I think he means not the 9250 SE |
| 21:34.12 | JeffM | cus that's the bus gimped one |
| 21:35.19 | blast007 | and it doesn't do shaders 2 |
| 21:35.32 | blast007 | 1.4 pixel shaders support up to 6 textures per rendering pass; 1.1 vertex shaders support vertex programs up to 128 instructions |
| 21:36.02 | JeffM | yeah dx8 card |
| 21:36.27 | JeffM | back to looking for break bads for the bike |
| 21:36.32 | blast007 | and sure, it WAS good compared to the agp 2x days.... the card is a 4x/8x device :) |
| 21:36.55 | JeffM | figgure if I have to take the wheels off to change the tires, may as well change the pads too |
| 21:37.09 | a_meteorite | heh, I never took you for the mechanic type :) |
| 21:38.39 | JeffM | had to build my first car |
| 21:38.52 | JeffM | it had been abandoned outside a GM advanced research plant |
| 21:39.03 | a_meteorite | wow |
| 21:39.47 | ts | Why does the corner data in drawinfo need meshes with texcoords? If there are no texcoords bz can draw the textures when not using drawinfo. Why is it needed? |
| 21:40.21 | JeffM | meshes always need texcords |
| 21:40.37 | JeffM | if a mesh has no texcord, it is drawn ether untextured, or with 0 0 for all verts |
| 21:41.06 | *** join/#bzflag bryjen (n=bryjen@2002:4cb1:b40f:0:0:0:0:1) |
| 21:41.06 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 21:41.18 | JeffM | the draw info for LOD is defineing a new set of geometry, it may have a difrent set of UV mapings |
| 21:41.26 | ts | Hmm, I have meshes that show textures without texcoords specified |
| 21:41.28 | JeffM | or even be a billboard or diferent shape |
| 21:41.33 | JeffM | real meshes? |
| 21:41.36 | JeffM | or meshboxes? |
| 21:41.45 | ts | Data structure mesh in bzw |
| 21:42.03 | JeffM | bz would have no way to map the image to the geometry |
| 21:42.14 | JeffM | unless trepan put in a UV generator mode for environ maps |
| 21:42.43 | WinnyAFK | batman! |
| 21:43.23 | ts | So they seem to be auto-generated when not using drawinfo? |
| 21:43.33 | JeffM | I'd doubt that |
| 21:43.39 | JeffM | very much so |
| 21:43.50 | JeffM | a mesh is intended to have UVs |
| 21:43.54 | JeffM | specialy with draw info |
| 21:44.00 | ts | I'm not getting my U/V mapping right |
| 21:44.10 | ts | It's so wrong even for simple objects |
| 21:44.26 | JeffM | if there is any auto mode for meshes that'd be a holdover, and I'd wonder how it maps it? cubic? spherical? |
| 21:44.33 | ts | even without using drawinfo |
| 21:44.50 | JeffM | your doing them by hand? |
| 21:44.59 | ts | No, Wings3D |
| 21:45.47 | ts | I've looked at the U/V editor but I'm lost there. I can map the faces to textures but in the export the textures are showing in wrong direction etc |
| 21:46.07 | JeffM | sounds like an export bug |
| 21:46.46 | ts | Sometimes the output file is completly empty |
| 21:47.03 | ts | only "exported ... wings3d" in first line |
| 21:48.32 | ts | Why did trepan do fixed striping and fixed LODing? |
| 21:49.50 | *** join/#bzflag dsypy (n=bob@dsl092-247-216.chi1.dsl.speakeasy.net) |
| 22:05.43 | JeffM | fixed? |
| 22:06.28 | blast007 | suppose he means not dynamically generated by bzfs |
| 22:06.38 | JeffM | cus that is hard |
| 22:06.50 | JeffM | and will ce wring often |
| 22:06.57 | JeffM | be wrong |
| 22:07.06 | JeffM | often you'll want to go to a billboard at the lowest level |
| 22:08.07 | JeffM | and that needs a new texture, etc.. |
| 22:08.19 | ts | Hmmm, at least LODing can be done fast dynamically |
| 22:08.29 | JeffM | not allways |
| 22:08.37 | JeffM | but that'd be the feature of a real engine |
| 22:08.42 | JeffM | we don't have a real engine :) |
| 22:08.56 | ts | right, we have crap ;) |
| 22:09.04 | *** join/#bzflag poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 22:09.04 | JeffM | it's a lot simpler to just tell our render node to use a new set of verts |
| 22:09.35 | ts | There was some research in LODing at our university, they found a fast algorithm that avoids cracked polys, too |
| 22:09.53 | JeffM | there are some, if you assume manifold geometry |
| 22:09.59 | JeffM | they can't go out to a billboard |
| 22:10.09 | JeffM | tree's do better as a billboard |
| 22:10.25 | JeffM | convex manifolds can be done easy automaticly |
| 22:10.37 | JeffM | so I guess the real question is, why havent' you fixed it? ;) |
| 22:11.02 | ts | I'm looking at what trepan did and I'm trying to understand it. |
| 22:11.17 | ts | It's the first semester I'm taking graphics courses |
| 22:11.24 | ts | (CG and Anim) |
| 22:16.15 | JeffM | just replace it |
| 22:17.29 | JeffM | no need for legacy behavor when it's not a major feature |
| 22:33.28 | *** join/#bzflag nn-laptop (n=knoppix@74.94.43.195) |
| 22:40.02 | *** join/#bzflag PrezKennedy (n=Matthew@c-76-106-124-125.hsd1.md.comcast.net) |
| 22:51.41 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 22:54.56 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 22:54.56 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 22:57.33 | *** join/#bzflag bier__ (n=bier@p54A525C2.dip0.t-ipconnect.de) |
| 23:07.53 | brad | ~blast007++ |
| 23:24.21 | *** join/#bzflag davemicc (n=c2water@cpe-071-071-001-026.triad.res.rr.com) |
| 23:40.18 | Winny | isn't fair :( bass instrument playing up in treble clef :( |
| 23:40.37 | tannerld | ? |
| 23:41.24 | nn-laptop | ? |
| 23:41.40 | *** join/#bzflag triclops (n=triclops@124-168-3-131.dyn.iinet.net.au) |
| 23:41.44 | Winny | tannerld, you know what a bass clef is, right? |
| 23:42.02 | Winny | and you know that a treble clef is ABOVE it, right? |
| 23:42.10 | nn-laptop | Tedius, hi you still testing? |
| 23:42.25 | nn-laptop | -/ playing around |
| 23:44.03 | *** join/#bzflag rob1n (n=emp@unaffiliated/rob1n) |
| 23:46.25 | tannerld | Winny: uh huh.. |
| 23:46.48 | tannerld | Winny: harmonics? |
| 23:46.59 | Winny | I usually play in bass clef (in the staff), not 7 leger linges above it |
| 23:47.01 | Winny | err, 6 |
| 23:47.27 | Tedius | hello, what nn? |
| 23:48.04 | tannerld | Winny: harmonics/shifting :) |
| 23:48.15 | Winny | no, it has to be played up that high |
| 23:49.07 | tannerld | hmm? |
| 23:50.17 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 23:50.56 | *** join/#bzflag wanda (n=coredump@p5499C44B.dip0.t-ipconnect.de) |
