IRC logs for #opendune on OFTC at 2009-11-29
⏴ go to previous day
10:18:24 <TrueBrain> whoho, even segra signed up :p Haha :)
10:42:14 <DorpsGek> SVN: truebrain (r637) -Codechange: s/AirUnit/Team/g. Initial naming can be poor/bad/wrong.
13:33:11 <TrueBrain> I finally renamed 'airunit' away to 'team' ;)
13:35:07 <glx> hmm you forgot something it seems
13:35:47 <DorpsGek> SVN: truebrain (r638) -Fix (r637): sorry glx, forgot the MSVC project again
13:37:01 <TrueBrain> is this going to be your normal join from now on? Join, disconnect 5 minutes later, rejoin, and stay on? :p
13:37:12 <glx> it happens with OFTC only
14:38:37 <glx> hmm packed tile are index in map array
14:39:56 <TrueBrain> of course they are :)
14:40:16 <glx> * 2E9C:323F -> Map array (2 bytes per tile). <-- this is not map array :)
14:40:28 <TrueBrain> it is an auxilary map array
14:40:41 <TrueBrain> 0x8000 means something like: requires update
14:40:47 <glx> map array elements are 4bytes
14:41:04 <TrueBrain> that map array is documented in map.c
14:42:50 <TrueBrain> but they are both map arrays :) Don't make any mistake in that :)
14:43:28 <TrueBrain> no idea why they are seperated
14:47:39 <glx> ok I'll try to convert emu_Structure_GetByPackedTile()
14:48:17 <TrueBrain> I believe the name is wrong btw .. Structure_Get_ should be the prefix .. or maybe it needs a completely different name :p
14:48:56 <TrueBrain> nah, Get_ByPackedTile should be fine :p
14:49:08 <glx> well it returns the structure if there's one on the given tile
14:49:36 <glx> so the name is correct, just the style is "wrong"
14:52:39 <glx> hmm and it should not go in pool
15:05:26 <glx> ,...if ((emu_get_memory8(emu_es, emu_bx, 0x2) & 0x20) == 0) goto l__116F; <-- it tests the last bit of tile.houseID or am I wrong ?
15:05:45 <TrueBrain> depends on what is at es:bx
15:05:58 <TrueBrain> but if it is Structure or Unit, it should never be true
15:06:17 <TrueBrain> houseID is on the lower 3 bits
15:06:28 <TrueBrain> 2 is the 5th bit (starting from 0)
15:07:28 <TrueBrain> & 0x07 gives houseID
15:07:28 <glx> hmm so bytes are from top to bottom and bits are "inverted"
15:08:12 <TrueBrain> a struct always starts at the lower bit
15:09:26 <TrueBrain> so first 9 bits are SpriteID
15:09:29 <TrueBrain> next 7 bits are FoW
15:09:34 <TrueBrain> then 3 bits are houseID
15:10:02 <TrueBrain> so 0x0001FF is spriteID, 0x00FE00 is FoW and 0x070000 is houseID
15:10:30 <glx> but it's not accessed that way :)
15:10:38 <TrueBrain> you are very vague ..
15:10:59 <glx> it's accessed using get_memory8 which confused me :)
15:11:20 <glx> and then the bytes are "inverted"
15:13:24 <glx> hmm no, indeed it's the same order as the bits
15:25:08 <glx> hmm ok something is broken now :)
16:04:55 <Xaroth> I see Segra has registered :o
16:07:12 <Xaroth> and also good to see SharQueDo is still watching the forums :o
17:24:02 <TrueBrain> glx: I was thinking about naming the 'flags' like: isBuilding
17:24:17 <TrueBrain> btw, I think it will be 'index of object'
17:24:40 <TrueBrain> but I think we can assume it will hold more than just the structure?
17:24:53 <glx> I tried to look for all flags access, but found nothing precise yet
17:25:38 <TrueBrain> I think the first is something like 'uncovered'
17:29:04 <TrueBrain> your patch looks fine bt
17:29:22 <TrueBrain> I will fiddle with the flags (in general) some other day I guess ... as I think I will make all the flags a single bit
17:29:25 <TrueBrain> much easier to use :)
17:29:47 <glx> my first version was like that ;)
17:30:15 <TrueBrain> maybe I will put the flags in a struct, so you can read/write them at once, or one by one .. not sure yet
17:30:19 <TrueBrain> I guess we have to toy with it a bit
17:30:22 <TrueBrain> for not this is just fine :)
17:30:36 <TrueBrain> oh, bit 1 most likely is 'covered' ;)
17:30:43 <TrueBrain> it is reversed from what I expected
17:30:56 <glx> the struct is a good idea
17:31:11 <TrueBrain> yeah, but we do that at a later stage, for all flags at once :)
17:31:18 <TrueBrain> not related to your patch :)
17:36:44 <DorpsGek> SVN: glx (r639) -Add: C-ified Structure_Get_ByPackedTile()
22:09:55 <Xaroth> hm, apparently the Nagios lot are building an 'enterprise' variant of Nagios
22:10:13 <Xaroth> which, evidently, has all the features people bitch and moan the normal nagios is missing
22:10:20 <Xaroth> (db backend, a 'proper' webinterface, etc)
22:37:42 <Xaroth> glx: you don't happen to know what is actually going on in emu_Tile_GetDistanceOffset?
22:40:54 <Xaroth> I -think- it's not GetDistanceOffset, but instead GetDistancePacked
22:42:09 <glx> first step is abs((arg1 & 0x3F) - (arg2 & 0x3F))
22:42:48 <Xaroth> after that it's getting ((arg1 >> 6) & 0x3F) - ((arg2 >> 6) & 0x3F)
22:43:09 <Xaroth> which, is damn wel equal to Tile_GetPackedX & Tile_GetPackedY
22:43:12 <Xaroth> return (packed >> 0) & 0x3F;
22:43:14 <Xaroth> return (packed >> 6) & 0x3F;.
22:43:48 <Xaroth> then at least I got that one right :P
22:44:17 <glx> abs(x1-x2) then abs(y1-y2)
22:44:37 <Xaroth> identical to Tile_GetDistance
22:44:47 <Xaroth> only that one uses tile32
22:45:30 <glx> then it exchanges them so the second is the smallest
22:45:50 <Xaroth> highest + half smallest
22:47:47 <glx> so a simple return Tile_GetDistance(unpack(arg1), unpack(arg2)) should work
22:48:21 <Xaroth> hm, did it a bit different than that, but first see if it works as I want it to
22:50:48 <Xaroth> well that appears to work
22:51:03 <Xaroth> uint16 distance_x = abs(Tile_GetPackedX(packed_from) - Tile_GetPackedX(packed_from));
22:51:49 <glx> one should be packed_to ;)
22:52:36 <Xaroth> :o it now also prints Thank you for playing Dune II.
22:52:59 <Xaroth> never noticed that opendune did that :o
23:00:39 <Xaroth> glx / TrueBrain : oppinions please :)
23:02:02 <TrueBrain> Xaroth: please check other emu functions how to do the newline and aligning
23:02:06 <TrueBrain> yes, I am very picky about that
23:02:55 <Xaroth> wrt the newline between emu_ax = and the line above in emu_tile_
23:04:02 <Xaroth> TrueBrain: Unpacking the packed, then calling Tile_GetDistance or keeping the inline unpacking in the calculation?
23:04:21 <TrueBrain> huh? what? I lost you :p
23:04:26 <TrueBrain> I think this is fine how it is
23:04:54 <Xaroth> + uint16 distance_x = abs(Tile_GetPackedX(packed_from) - Tile_GetPackedX(packed_to));
23:04:57 <Xaroth> + uint16 distance_y = abs(Tile_GetPackedY(packed_from) - Tile_GetPackedY(packed_to));
23:05:07 <TrueBrain> yes, looks fine, not?
23:05:30 <TrueBrain> oh, you mean calling Tile_GetDistance
23:05:32 <TrueBrain> yes, that might be more nice
23:06:03 <glx> yes I'll call existing function when possible :)
23:08:03 <TrueBrain> now align packed_from and packed_to, and I am happy
23:08:45 <Xaroth> I should introduce you to one of our customers, he likes stuff alligned as well :P
23:08:51 <glx> intermediate variable are optionnal I think :)
23:08:59 <TrueBrain> I think they are nicer :)
23:09:11 <TrueBrain> Xaroth: well, yes, but in open source projects it is also VERY important to make HIGHLY readable code
23:09:19 <TrueBrain> as the chances we will still be here in 4 years are very slim
23:09:31 <Xaroth> I'll still be here if I can help it :P
23:09:40 <TrueBrain> so better us to waste another 10 minutes on good readability, then later on make people mad for not-readability :p
23:09:46 <TrueBrain> sure, if we can help it ... ;)
23:09:55 <TrueBrain> hell, I am still in OpenTTD, so is glx
23:10:02 <TrueBrain> I think we are one of the oldest (ignoring orudge :p)
23:10:47 <TrueBrain> reminds me, what is your daytime job glx?
23:10:53 <TrueBrain> did I ever ask that? :)
23:11:09 <TrueBrain> so what do you do? (no offense meant)
23:11:40 <TrueBrain> Xaroth: I personally would do the one in Tile_GetDistancePacked too, but that is optional I guess
23:12:02 <Xaroth> ah fook, forgot to save that file :P
23:12:09 <TrueBrain> make sure to test it
23:12:45 <TrueBrain> I believe it is Rubidiums favorite commit message :p
23:12:48 <TrueBrain> "Save before commit"
23:13:28 <Xaroth> well if you see the amount of stuff he commits it's bound to happen more than a few times :P
23:13:57 <glx> for Belugas, it's compile before commit ;)
23:14:04 <TrueBrain> he is even worse in commit often than I am, so yes :p
23:14:20 <TrueBrain> s/commit often/commit-often/
23:14:49 <glx> petern is I have a patch for that
23:15:03 <glx> he has patches for a lot of things ;)
23:15:21 <TrueBrain> in fact, I believe the infinite monkeys applies to him
23:15:38 <TrueBrain> he has an infinite pool of infinite patches, which do everything
23:16:20 <TrueBrain> and I .. I go to bed :)
23:17:30 <Xaroth> time to check this patch, then comitt if it runs fine :o
23:17:48 <TrueBrain> nice job on the patch Xaroth :) Things can be easy :)
23:17:59 <TrueBrain> "begrijpend lezen" I think it is
23:18:03 <glx> if first mission works as usual it should be ok ;)
23:18:09 <Xaroth> well I had to read it 3 times to figure it out, but i had one of those 'waaait a minute' moments
23:19:48 <glx> yes sometimes dune2 does overcomplicated things when there's a simpler way
23:20:26 <Xaroth> think that once i comit this patch i'll make a new teaser for the clan
23:20:40 <Xaroth> seeing midfreak is happily playing it (and even posted a bug :o )
23:20:58 <Xaroth> (which was a duplicate, but still... he's normally lazy as fook with bug reporting)
23:22:41 <Xaroth> I think there's something wrong with it still
23:22:55 <Xaroth> harvesters not automagically harvesting
23:24:05 <glx> there's no reason for that
23:24:19 <Xaroth> so it must be a bug :)
23:24:45 <glx> and with your previous version (the one not calling Tile_GetDistance)
23:24:54 <Xaroth> and it's harvesting again
23:25:36 <Xaroth> it's calculating s.x vs s.y , which also include offsets
23:26:00 <glx> it's a substraction, they should eliminate each other
23:26:00 <Xaroth> no, but it might yield different return values that confuse the AI
23:29:10 <Xaroth> now I'm interested to figure out why the other way doesn't work tho :o
23:31:01 <glx> you can compare results of both version with an assert
23:34:05 <Xaroth> distances of >2000 o_O
23:34:39 <Xaroth> ax: 3840ax: 3712ax: 3584ax: 3456ax: 3328ax: 3200ax: 3072ax: 2944ax: 2816ax: 2688
23:34:43 <Xaroth> ax: 2560ax: 2688ax: 2816ax: 2944ax: 3072ax: 3200ax: 3328ax: 3456ax: 3584ax: 3712
23:34:49 <Xaroth> (printf on the return val ftw)
23:35:24 <Xaroth> ax: 15ax: 14ax: 14ax: 13ax: 13ax: 12ax: 12ax: 11ax: 11ax: 10ax: 10ax: 10ax: 11ax
23:35:27 <Xaroth> : 11ax: 12ax: 12ax: 13ax: 13ax: 14ax: 14ax: 15ax: 14ax: 13ax: 13ax: 12ax: 12ax:
23:35:33 <Xaroth> that .. is quite a significant difference :p
23:35:58 <Xaroth> it's the tile32 struct I thinkg
23:37:08 <glx> give me your current diff, I'll do some debugging
23:38:08 <Xaroth> working version of Tile_GetDistancePacked:
23:38:08 <Xaroth> uint16 distance_x = abs(Tile_GetPackedX(packed_from) - Tile_GetPackedX(packed_to));
23:38:11 <Xaroth> uint16 distance_y = abs(Tile_GetPackedY(packed_from) - Tile_GetPackedY(packed_to));
23:38:14 <Xaroth> if (distance_x > distance_y) return distance_x + (distance_y / 2);
23:38:18 <Xaroth> return distance_y + (distance_x / 2);
23:39:21 <glx> why do I need to use -p1 to apply it ???
23:40:03 <glx> then you clicked on the wrong dir :)
23:40:20 <glx> trunk shouldn't be in the patch
23:40:21 <Xaroth> i create patch on the root dir :P
23:41:37 <Xaroth> looking at tile32 it makes sense actually
23:41:46 <Xaroth> px and py are surrounded by u* and o*
23:42:16 <Xaroth> so they skew the actual values of the bits
23:42:43 <Xaroth> 0x1 becomes 0x4 due to ux/uy
23:43:23 <Xaroth> yes, so 00000001 vs 00000100
23:43:48 <Xaroth> 2 being 00000010 vs 00001000
23:45:17 <glx> ok so f__0F3F_0104_0013_C3B8 does the same :)
23:45:50 <glx> now I understand why it does +0x80 >> 8 :)
23:46:09 <Xaroth> I don't, yet, but that's good to know :P
23:46:50 <glx> it calls Tile_GetDistance, adds 0x80 to the result and shifts
23:49:01 <Xaroth> why does it do that then?
23:50:02 <glx> I think it adds 0x80 to do upper rounding
23:50:15 <Xaroth> @calc 3840 / ( 2 ** 8)
23:50:31 <Xaroth> @calc 2712 / ( 2 ** 8)
23:50:34 <Xaroth> @calc 3712 / ( 2 ** 8)
23:51:38 <Xaroth> time to verify, and commit
23:52:05 <glx> anyway GetDistance and GetDistancePacked don't use the same scale
23:52:19 <Xaroth> hang on, if i put 14.5 in an uint16, does that yield 14 or 15?
23:52:35 <Xaroth> so always rounded down?
23:54:39 <glx> naming will need an update when we'll understand the scale difference :)
23:54:51 <Xaroth> most likely, but for now it seems to work
23:56:39 <glx> oh and when you use printf to compare results, use %x instead ;)
23:56:53 <glx> it's easier to spot the offset
23:58:00 <glx> 0x0780 vs 0x0007 <-- immediate understanding :)
23:58:46 <DorpsGek> SVN: xaroth (r640) -Add: C-ified emu_Tile_GetDistanceOffset and renamed it to its actual use
continue to next day ⏵