IRC logs for #opendune on OFTC at 2009-11-26
⏴ go to previous day
02:36:07 <DorpsGek> SVN: glx (r613) -Fix (r611): forgot to update a file
04:37:22 *** boekabart has joined #openDune
05:06:34 *** boekabart has joined #openDune
09:20:03 <TrueBrain> why did glx sound suprise it doesn't auto-update, while I told that like 3 times :p
13:38:37 <Xaroth> that's about how far my writing french goes :P
14:22:17 <glx> OFTC is not very stable today :)
14:22:27 <Xaroth> oftc is blaming you though :P
14:22:33 <Xaroth> [glx [glx@2a01:e35:2f59:c7c0:a07f:68ab:586e:abb1] quits (Remote host closed the connection)
14:23:08 <glx> but my connection works well, IPTV running without problems
15:08:51 <TrueBrain> + return (((id & 0x3F00) / 4) | ((id & 0x7E) / 2)) & 0x3FFF; <- any posibility you write this more readable :)
15:08:55 <TrueBrain> and here you should use << >>, as here you mean bit thingies
15:09:44 <TrueBrain> + if (Unit_Get_ByIndex(id)->flags & 0x2 == 0) return 0; <- missing () around &, and please use 0x0002 :)
15:10:17 <TrueBrain> and can you make '1' '2' and '3' enums? :)
15:15:36 <TrueBrain> it has been a really long day already ... and I am just 50% there :p
15:22:47 <Xaroth> going to work on a small standalone nagios vmware instance i think
15:24:49 <Xaroth> nagios isn't that hard :P
15:24:51 <TrueBrain> nagios, the most impossible piece of software, but everyone needs it :p
15:37:51 <Xaroth> always wanted to properly re-do our nagios systems
15:37:59 <Xaroth> it's not the nagios part
15:38:13 <Xaroth> nagios is piss easy to configure :P
15:38:25 <TrueBrain> if you plan to never change it again
15:38:38 <TrueBrain> it is just one of those pieces of software
16:49:08 <Xaroth> right, if nobody annoys me tonight I'll be able to work some on emu_Tile
16:49:12 <Xaroth> see how that turns out
16:51:36 <Xaroth> TrueBrain: mind if i make some small additions to your worklist?
16:54:07 <glx> now I know why tiles have to be packed :)
16:54:30 <Xaroth> and modified worklist to show the amount of named functions
16:54:37 <glx> it's the only way to get 2 bits for 0XC000 :)
16:55:12 <Xaroth> nevermind, i should get to home first I think :P
17:09:05 <TrueBrain> glx: don;t forget doxygen comments (to at least the enum itself)
17:09:29 <TrueBrain> any way to use the tile functions?
17:09:32 <TrueBrain> and you forgot a 'case 1' :)
17:10:33 <TrueBrain> and please replace 'ID' in doxygen comments for Index :)
17:11:08 <TrueBrain> and good job on noticing it was tiles :) Didn't expect that :)
17:15:43 <glx> I checked all calls to Encode :)
17:16:07 <glx> and analysed what was passed for type 1
17:19:25 <TrueBrain> but as the index is a compressed tile, can't you use Tile_GetPackX and Tile_GetPackY?
17:21:08 <TrueBrain> for Decode there is no hope (By the lack of 'SetPackedX' :p)
17:21:22 <TrueBrain> well, you can use PackXY there I guess
17:26:27 <TrueBrain> so an encoded has in the higher 2 bits the tile .. so (id >> 14) == 1 means unit, == 2 means structure, == 3 means tile ... that is completely reversed from what encoding accepts :p
17:26:31 <TrueBrain> a bit stupid (design wise)
17:28:34 <TrueBrain> I also don't understand the decoding of the tile :)
17:28:48 <TrueBrain> why so complicated ... you already have a 12bit ...
17:29:10 <TrueBrain> why oh why make that a 14bit, with lowest bit of the 2 7bit pairs always on ...
17:30:53 <TrueBrain> well, I guess it has a use at some point :p At least it is nice to know we can make the maps 128x128 if we would like to :p
17:35:25 <glx> Tile_UnpackTile could also use Tile_GetPackedX and TileGetPackedY
17:59:44 <TrueBrain> looks very good, reflects nicely what it does :)
18:00:06 <TrueBrain> you only no longer need the 0x3FFF mask ;)
18:00:10 <TrueBrain> is kind of implied now :)
18:17:42 <DorpsGek> SVN: glx (r614) -Add: named and C-ified Tools_Index_GetType(), Tools_Index_Encode() and Tools_Index_Decode()
18:18:53 <glx> worklist needs a refresh ;)
18:18:59 <TrueBrain> yeah .. needs manual trigger
18:19:04 <TrueBrain> but you need to sign off on a function either way
18:19:08 <TrueBrain> so it is not that important
18:24:06 <TrueBrain> Xaroth: your math was off .. the amount of named functions can only be based on amount of functions left .. as all converted functions are named too :p
18:45:57 <Xaroth> converted functions are also named ;)
18:46:12 <Xaroth> it checks for an emu_ prefix, so once they are gone, the named functions will disappear too
18:46:33 <TrueBrain> Xaroth: you based it on the 1000+ value
18:46:39 <TrueBrain> where it is the 900+ value, like it is now :)
18:55:15 <TrueBrain> damn, Hillary Duffs latest movie REALLY sucks
19:00:50 <TrueBrain> well, one can hope, can't he? :)
19:01:08 <TrueBrain> oh, you are catching on?
19:39:49 *** TrueBrain has joined #openDune
19:58:42 <glx> hmm which function to do now
20:28:46 <glx> hmm dune2 seems to have self modifying code
20:30:05 <glx> 8B 46 0A BA 0C 00 F7 EA BA 8A 2E 8B D8 8E C2 26 8B 87 74 00 0B C0 74 10 3D 01 00 74 25 3D 02 00 75 03 E9 82 00 <-- 176C:0039
20:30:05 <glx> 8b 46 0a ba 0c 00 f7 ea ba 93 2c 8b d8 8e c2 26 8b 87 74 00 0b c0 74 10 3d 01 00 74 25 3d 02 00 75 03 e9 82 00 <-- corresponding stuff in dune2.exe
20:31:44 <glx> so the BA 93 2C (emu_dx = 0x2C93) in dune2.exe is BA 8A 2E (emu_dx = 0x2E8A) in decompiled/JIT
20:33:51 <glx> I noticed it when trying to solve some unresolved jumps
20:34:12 <SmatZ> can it be because of relocation?
20:35:27 <glx> not really important, it's a memory page :)
20:35:37 <SmatZ> eg. the binary exe is relocated before main() is executed (address of segment (or so) is added to given addresses in the binary image)
20:36:10 <SmatZ> emu_dx = 0x2C93 in fact means "offset 0x2c93 from to-be-added base"
20:38:31 <glx> anyway I noticed it because searching for the hexa didn't worked :)
20:38:43 <glx> of course, it's not the "same"
20:39:39 <glx> ok so no self modifying code
20:52:14 * TrueBrain hugs SmatZ for being spot-on
20:52:28 <TrueBrain> glx: it is the reason dune2.exe is useless to us :)
20:53:14 <glx> I can solve some unresolved jumps by reading it (but only the easy one :)
20:53:24 <TrueBrain> install the debugging DOSBox
20:53:27 <TrueBrain> and you can resolve it too :p
20:55:12 <glx> f__176C_000E_000E_633D() <-- I can resolve the 2 unresolved jumps (they are indeed 3 ;) ), but it jumps to undecompiled part of the function
20:55:29 <TrueBrain> then you need to ship me crash.bin ;)
20:55:31 <glx> so it's not an easy to solve and I'll make a crash.bin instead
21:05:26 <DorpsGek> SVN: truebrain (r615) -Fix: also remove @define after implementing function
21:06:28 <glx> I always forgot the @define
21:06:56 <glx> (and sometimes the function_names.txt)
21:09:53 <DorpsGek> SVN: truebrain (r616) [JIT] -Add: mapped another 9 functions (crash-bins provided by glx)
21:10:08 <DorpsGek> SVN: truebrain (r617) -Update (r616): update decompiled code
21:10:14 <Xaroth> another 9 functions O_O
21:10:19 <TrueBrain> in r616 there is too much, but I couldn't be arsed figuring out what
21:10:24 <TrueBrain> yeah ... they triggered quiet a few things
21:10:28 <glx> Xaroth: some are just a goto :)
21:11:18 <TrueBrain> 1 real new function
21:11:56 <TrueBrain> but it tells you about the construct
21:13:53 <glx> ,...if (emu_ax != 0x2) goto l__005E;
21:14:05 <glx> this I was able to do it myself ;)
21:15:10 <TrueBrain> so get to work :p :p
21:20:18 <glx> for not die, not destruct and not invalid position
21:23:31 <TrueBrain> good luck ) I am off to bed :)
22:21:09 *** Xaroth_ has joined #openDune
22:47:06 *** Xaroth has joined #openDune
22:47:06 *** ChanServ sets mode: +o Xaroth
23:14:33 *** Xaroth sets mode: +o TrueBrain
23:14:39 *** Xaroth sets mode: +v boekabart
continue to next day ⏵