IRC logs for #opendune on OFTC at 2009-10-12
⏴ go to previous day
07:57:43 <Xaroth> hm, How come with structs you put the type of the struct before the { and after the } ? :o
07:58:02 <Xaroth> I take it it has some kind of special meaning?
08:02:43 <Xaroth> also, TrueBrain, if you can explain me how to run the emu so that I can also assist in decompiling, I should be able to throw in some mindless hours of playing.. not now ofc seeing i'm at work.
08:04:04 <Xaroth> I can probably finish an entire house in a few days
08:20:57 <Xaroth> re: src/units.h , there's claimed to be 27 units in the game, so possibly there's a 26
08:22:01 <Xaroth> not confirmed ofcourse
08:23:57 <Xaroth> re: src/building.h , the ones missing from the list are: Starport, House of IX, WOR and the Palace, at least those I miss from that list
08:24:20 <Xaroth> WOR should only show up on a hark mission, IX and SP show up in mission.. 5 or 6 i think
08:29:21 <Xaroth> re: src/house.h , I think I might be able to find a post on the fed2k forums about that
08:36:18 <Xaroth> hm, can't find it anymore, but if there are I at least know their names, Fremen, Sardukar and Mercenaries (the 3 'houses' from superdune/dune-ex) .. I would find it higly unlikely that Fibble went through all the trouble in changing every bit of each house into their own, especially as fremen and sardukar are already 'used' in the game
08:36:33 <Xaroth> (I just don't know how sardukar are treated, ie, their own house, or something special)
08:37:02 <Xaroth> (I would suggest their own house, but as I can't confirm, I won't confirm :) )
09:13:49 <TrueBrain> Xaroth: JIT: only works on linux, and doing what Alberth does is more than plenty I guess :) (and much easier ;))
09:14:03 <Xaroth> I can run on vmware :P, but ok
09:14:09 <TrueBrain> structs: that is how C works
09:15:52 <TrueBrain> okay .. the 'hint' in src/function_names.txt was, that the first 2 parameters is in fact 'tile32'
09:16:06 <Xaroth> tempted to change the != 0 to != 0x0 tho
09:16:14 <Xaroth> yeh, was looking at that, i just completed it like.. 2 minutes ago :P
09:17:30 <Xaroth> that &= / |= line all in the if? bit cluttered then right
09:18:00 <Xaroth> yeh, but you can make 1 big if out of it
09:18:00 <TrueBrain> resolves any and all | & ^ ~ .. :p
09:20:39 <Xaroth> now you got me confused, but I think you're processing it a bit faster than my brain can cope :P
09:20:57 <TrueBrain> var06 + var08 becomes 'tile32'
09:21:20 <TrueBrain> in tile32 there are 3 types, 's', 'd', and 'all'
09:21:48 <Xaroth> s/all/tile , but go on
09:21:53 <TrueBrain> you need to validate if a tile is valid by looking of & 0xC000 of s.x is zero .. are the final two bits
09:22:09 <TrueBrain> so check tile32.d, what indicates the final 2 bits of x
09:22:18 <TrueBrain> now compare those with zero :p
09:22:36 <Xaroth> and it does the same with y, right
09:22:50 <TrueBrain> the 'u' stands for 'unused'
09:22:50 <Xaroth> if tile.ux != 0x0 && tile.uy != 0x0
09:23:01 * TrueBrain claps in his hands :)
09:23:10 <Xaroth> takes a while, but i get there :P
09:23:40 <Xaroth> and swap true/false then
09:24:20 <Xaroth> meh, you can make that even smaller
09:24:34 <Xaroth> return ( tile.ux != 0x0 || tile.uy != 0x0 );
09:24:49 <TrueBrain> a ! in front, I hope
09:24:58 <TrueBrain> IsValid shouldn't not return true on invalid :p
09:25:46 <Xaroth> wait, i mixed things up a bit i think
09:26:53 <Xaroth> it's ux OR uy: return false, else, true
09:27:09 <TrueBrain> just forget what it says and think for a moment what it does :)
09:27:13 <TrueBrain> ux and uy should always be zero
09:27:41 <Xaroth> return !(tile.ux != 0x0 || tile.uy != 0x0)
09:27:56 <TrueBrain> and now apply that rule .. what was his name ...
09:28:39 <TrueBrain> !(a || b) = !a && !b
09:28:53 <Xaroth> !((tile.ux != 0x0) || (tile.uy != 0x0))
09:29:02 <TrueBrain> LOL! No .. not what I meant :p
09:29:07 <TrueBrain> those () are in fact useless in this case :)
09:29:12 <TrueBrain> !(a || b) = !a && !b
09:29:39 <Xaroth> meh, liked my sollution better.. curly brackets ftw :P
09:30:15 <Xaroth> return ((tile.ux == 0x0) && (tile.uy == 0x0));
09:30:36 <Xaroth> unless overuse of brackets is against the CS
09:31:11 <Xaroth> do bools auto-convert to 0x0 / 0x1 when applied to an uint<something>
09:31:52 <Xaroth> aka, can I make emu_Tile_IsValid call Tile_IsValid and apply the return value directly to emu_ax (seeing that's the thing being set whether true/false)
09:32:55 <TrueBrain> I would make it explicit
09:33:06 <TrueBrain> and yes, it has too many () (the inner ones)
09:35:38 <Xaroth> tile32 *tile = (tile32 *)emu_get_memory32(emu_ss, emu_bp, 0x6);
09:35:49 <Xaroth> tell me i guessed right :P
09:36:00 <TrueBrain> not one I took so far
09:36:08 <Xaroth> what did you use then?
09:36:56 <Xaroth> using pointers in the args?
09:37:17 <TrueBrain> look at any of those files lazy ass :p
09:37:31 <TrueBrain> but: tile32 tile; tile.s.x = bp + 0x6; tile.s.y = bp + 0x8;
09:37:42 <TrueBrain> but yours might be more pretty ..
09:37:54 <Xaroth> AH, now i know what file
09:37:58 <TrueBrain> of course you have to send it to the next function with *tile, but .. yeah ..
09:38:05 <Xaroth> I was looking at the wrong MSVC :P
09:43:51 <Xaroth> Still getting used to that many pointers, but at least it's working somewhat
09:45:16 <TrueBrain> don't do the final cast, make it explicit
09:45:23 <TrueBrain> bool to uint should be done with much explicity in my opinion
09:45:33 <TrueBrain> tile.ux is wrong, it is tile.d.ux I believe
09:45:41 <TrueBrain> Tile_IsValid() ? 1 : 0
09:45:54 <TrueBrain> and check emu_*** for how to deal with the stack in a nice way :)
09:47:06 <Xaroth> so the x value is in fact, tile32.s.x and ux is tile32.d.ux
09:48:17 <Xaroth> must say it's getting smaller and smaller :P
09:48:35 <TrueBrain> please do leave the comment around poping ip and cs (see emu_*** again)
09:48:52 <TrueBrain> 0x6 now becomes 0x0
09:49:08 <TrueBrain> and yeah, then it is what I would expect it to be ;)
09:49:30 <Xaroth> bp is set to sp, so how can the 0x6 change to 0x0 ?
09:49:41 <Xaroth> or is that due to the popping?
09:49:48 <TrueBrain> because you pop the ip and cs, and do not push the bp
09:51:23 <TrueBrain> some of those functions will only get a emu_ variant
09:51:36 <TrueBrain> I don't know if it will be useful to make a real C wrapper for something like: tile.s.x :p
09:51:56 <TrueBrain> well, maybe for later ...
09:52:00 <TrueBrain> yeah, lets leave it in :)
09:52:15 <Xaroth> just the emu, or both?
09:52:38 <Xaroth> heh, GetXY will be quite hilarious then
09:53:01 <Xaroth> void Tile_GetXY(tile32 tile)
09:53:26 <TrueBrain> it wants a value back, not a tile32
09:54:13 <TrueBrain> yeah .. well .. you don't have to, only the emu_s are enough for now .. the first person making it C should add the C wrappers in that case :p
09:54:26 <TrueBrain> I am not sure in the case of GetXY, but I don't know what it is used for
09:54:35 <TrueBrain> but for things like GetX and GetPosX, it is useful to leave the wrapper
09:54:43 <TrueBrain> if we then modify the tile struct, we only have 1 place to edit :)
09:55:44 <TrueBrain> so: temp = a; a = b; b = temp;
09:55:57 <Xaroth> having 2 monitors ftw :P
09:56:06 <Xaroth> libemu left, under you, opendune right
09:58:16 <Xaroth> so it changes ox with px/ux and oy with py/uy
09:58:41 <TrueBrain> look at the result, what it really does
09:58:57 <TrueBrain> oh, this was the weird one where ox wasn't cleared? Hmm .. sad
09:59:48 <Xaroth> need to figure out what it actually does first, though.
10:01:36 <Xaroth> I'll leave that one for now, until I know what exactly it does
10:02:46 <Xaroth> TrueBrain: the (tile_tile) remark kinda shows that it's sending the full tile32 as param, right?
10:03:06 <TrueBrain> that was what I figured
10:03:08 <Xaroth> looking at GetPosX, which only reads 1 param, but the function_names.txt shows the full tile_tile
10:03:18 <TrueBrain> now look at GetPosY
10:03:20 <TrueBrain> and think about it for a sec
10:03:26 <Xaroth> yeh, it does the exact same, for the 2nd param
10:03:39 <Xaroth> just wanted confirmation
10:03:42 <Xaroth> before i mess things up etc :P
10:26:48 <Xaroth> TrueBrain: xorb al, al; orb al bh basically means al = bh ?
10:27:17 <Xaroth> so pack is packing 2 int16 into 1 int16 :o
10:27:35 <TrueBrain> more exact: it makes 12 bits from 32bits :p
11:55:30 <TrueBrain> just 922 functions to name :) How lovely ;)
11:56:39 <TrueBrain> suprisingly low value
11:56:48 <TrueBrain> given that it contains 100,000 lines
11:56:55 <TrueBrain> 100 lines per function on average ..
11:57:02 <glx> it was worse when functions where split
12:23:37 <glx> hmm I failed my math it seems
12:44:32 <glx> hmm what is in 01E7 segment ?
12:45:31 <TrueBrain> PSP and other dos stuff
12:45:53 <glx> it seems to be used as an offset but there are 2 values read there at the begining too
12:46:25 <TrueBrain> there is the filename which is launched, for example
12:48:03 <glx> variable_007B is always 01E7 it seems (value of emu_es at start)
12:49:05 <glx> and it's used as an offset
12:52:36 <glx> emu_get_memory16(01E7, 0x00, 0x2) = 9FFF
12:52:37 <glx> emu_get_memory16(01E7, 0x00, 0x2) = 01DD
12:52:50 <glx> 2C for the second line ;)
12:53:34 <TrueBrain> there is also a MSB around that area, which is th ememory page reserved for the executable
13:04:41 <TrueBrain> glx: look up PSP for DOS .. euh .. Prefix Segment something
13:04:59 <Xaroth> Program Segment Prefix
13:05:49 <glx> cool I can give better name to 2 variables then
13:10:26 <Xaroth> o_O negw using unsigned int?
13:11:50 <Xaroth> ah, changes back and forth to signed, right
13:23:05 <Xaroth> 0F3F:0125 calls overlays :o
13:24:39 <Xaroth> if (u->deviated != 0) return HOUSE_ORDOS;
13:24:51 <Xaroth> would be so funny to have a H vs A fight where one of them has a deviator :P
13:33:55 <TrueBrain> code wise not yet possible ;)
13:35:15 <Xaroth> emu_shrw(&emu_ax, 0x1);
13:35:27 <Xaroth> two of those after eachother :o
13:35:39 <Xaroth> somebody forgot to make it >> 2 ?
13:36:26 <TrueBrain> then you have to do: emu_cl = 2; shrw(ax, cl)
13:36:28 <TrueBrain> which is more expensive
13:36:48 * Xaroth goes try Tile_PackTile
13:41:34 <glx> I can't find why DS and ES contain the same value on program start (I found DS contains PSP address on start, but for ES I still don't know)
13:42:00 <TrueBrain> that is what DOS does
13:42:05 <TrueBrain> so the decompiler puts it there
13:42:21 <glx> but I'm trying to find docs about it :)
13:42:35 <TrueBrain> took me a long time before I found out that I had to set those values
13:42:40 <TrueBrain> in fact .. I just took over DOSBox values
13:43:27 <glx> so I can assume ES=DS=PSPaddr on start
13:43:59 <TrueBrain> header->start_ds = header->offset_psp >> 4;
13:44:01 <TrueBrain> header->start_es = header->offset_psp >> 4;
13:44:03 <TrueBrain> only for executables btw
13:45:32 <Xaroth> TrueBrain: ax & 0xFF00 is the same as al = 0x0 right?
13:45:51 <Xaroth> good, saves me a lot of pain :P
13:46:24 <TrueBrain> again, think about what it tries to do :)
13:46:33 <TrueBrain> and remember you have a tile32 backing you up
13:47:01 <Xaroth> uint16 newX = tile.s.x & 0xFF00;
13:47:16 <TrueBrain> then why not: tile.u.ox?
13:47:24 <TrueBrain> oh, euh .. tile.d.px
13:47:30 <TrueBrain> as the ux part should be 0
13:47:37 <TrueBrain> ox is the lower part
13:47:55 <TrueBrain> I can be wrong, but I believe that was the order :p
13:48:19 <Xaroth> i had them confused then :P
13:48:45 <Xaroth> but it doesn't clear ux/uy (they are clear anyhow, but stil)
13:49:14 <TrueBrain> Xaroth: so if you want to be sure, add it :p
13:49:19 <Xaroth> TrueBrain: is ux -ALWAYS- 0x0 ?
13:49:27 <TrueBrain> it should be, but I give no promises
13:49:38 <Xaroth> then i should stick to the or'ing.
13:49:42 <TrueBrain> glx: PSP is the IP, or what?
13:50:00 <glx> it's emu_es value at start
13:50:13 <TrueBrain> might be worth adding that
13:50:32 <glx> no ES is 01E7 while CS is 01F7
13:51:17 <TrueBrain> hehe, I see the confusion in that :)
13:51:24 <TrueBrain> csip32 is meant as address identification
13:51:29 <TrueBrain> not related to 'codesegment' as such
13:51:41 <TrueBrain> segip32 might be a better name I guess ;)
13:52:08 <TrueBrain> but okay .. I guess it is clear enough :)
13:52:09 <glx> ha you mean adding a prefix/suffix to the variable name
13:52:19 <TrueBrain> yeah, but I noticed I did that nowhere
13:52:51 <TrueBrain> damn, I should work for my payjob, but OpenDUNE is too .... distracting
13:53:18 <TrueBrain> the // comments are not C89
13:53:27 <Xaroth> they aren't in the .c :)
13:53:35 <TrueBrain> and the code really assumes ux and uy are empty
13:53:38 <TrueBrain> so just use that fact
13:53:54 <Xaroth> k, makes it a tad smaller :)
13:54:53 <Xaroth> right down to about.. return tile.d.py | (tile.d.px >> 2);
13:55:04 <Xaroth> I.. should really stop copying those tabs along
13:55:25 <glx> tabs doesn't matter for me (they are converted to ,...)
13:55:45 <TrueBrain> Xaroth: euh, no ... :p
13:56:26 <TrueBrain> and has a >> too much for px :p
13:56:34 <TrueBrain> remember that in the original the px was at the high bits
13:57:02 <DorpsGek> Xaroth: 1111111100000000
13:57:36 <TrueBrain> so first make a picture for yourself what the function does .. it sends the x position in the first 6 bits, the y in the next 6
13:57:39 <TrueBrain> now translate that :)
13:58:13 <TrueBrain> (this btw is a very inefficient way to do tile coordinates)
13:58:21 <Xaroth> aren't those the last 8?
13:58:22 <TrueBrain> ox -> 8 bits, px -> 6 bits, ux -> 2 bits
13:58:32 <TrueBrain> al are the first 8 bits, which is on the most right side :)
13:58:43 <Xaroth> er, yeh, last from LtR :P
13:58:57 <TrueBrain> 76543210 <- bit order
13:59:18 <TrueBrain> or -> bit 0:7, px -> bit 8:13, ux -> bit 14:15
13:59:53 <Xaroth> but it's retrieving bx, emptying out bl, so you have UUPPPPPP________
14:00:17 <TrueBrain> then it moves bh to al ..
14:00:30 <Xaroth> as such generating UUPPPPPPUUPPPPPP
14:00:36 <TrueBrain> well, after a shift of 2
14:01:17 <Xaroth> my mind works in decimal, not in binary
14:01:35 <glx> and use a paper for now :)
14:01:57 <Xaroth> I had it drawn on paper, but I still had it wrong :P
14:02:25 <TrueBrain> and that is why I say you can assume UU is 0, as it is put over the PP from the other coordinate
14:02:43 <TrueBrain> well, at least the ux has to be empty .. :p
14:02:59 <TrueBrain> feel free to add an assert(Tile_IsValid(tile));
14:03:05 <TrueBrain> then you know soon enough ;)
14:03:39 <Xaroth> so it ends up as ****XXXXXXYYYYYY
14:03:56 <TrueBrain> look closely which ends where
14:04:56 <Xaroth> high is left, low is right
14:09:01 <TrueBrain> LibEMU just compiled on MacOSX
14:09:13 <TrueBrain> I just had to point libs to the right place :p
14:13:59 <TrueBrain> I now have 2x 22" WD and 1x 15" WD on my desk :p
14:14:09 <Xaroth> uint px:6 , just so i know, in this case it takes the left (high) bytes for that?
14:14:35 <TrueBrain> those things are in order
14:14:39 <TrueBrain> from left to right in byte order
14:14:47 <TrueBrain> so ox:8, first 8 bits. Then px:6, next 6 bits
14:14:54 <TrueBrain> or at least, so I hope :p
14:15:04 <TrueBrain> we will notice soon enough when you compile your code :p
14:15:31 <TrueBrain> yes, C89 requirement
14:15:37 <TrueBrain> but all not relevant to you
14:15:45 <TrueBrain> all you need to know is that ox is 8 bits, px 6 bits, and ux 2 bits
14:15:47 <Xaroth> they end up at their respective same position in the new part?
14:16:23 <TrueBrain> I have no idea what you try to ask, but it really really is not important how ithappens
14:16:27 <TrueBrain> all you need to know, is that it happens
14:16:47 <Xaroth> well if i need to visualise things I need to know how they look :P
14:17:20 <TrueBrain> first 8 bits are ox, next 6 bits are px, the next 2 are ux, and then it repeats for y
14:17:29 <TrueBrain> where the first bit is on the most right side of a bit-string
14:18:53 <glx> ok I finally starting to understand what the code does with the environment variables
14:19:05 <Xaroth> I -think- i gets it now :P
14:21:45 <TrueBrain> k, OpenDUNE does not work on OSX 10.6 .. SDL fucks up some internal OSX thingy
14:21:51 <TrueBrain> making it throw an internal error :p
14:22:27 <Xaroth> OSX has always been issues with getting things to 'work' :P
14:22:35 <glx> well SDL always fucks up on OSX :)
14:22:44 <TrueBrain> at least it compiled :p
14:22:54 <Xaroth> if it compiles, ship it :P
14:23:13 <TrueBrain> don't confuse windows
14:23:28 * Xaroth can still remember the winME days..
14:25:13 <Xaroth> think that was actually the first pc I ever literall threw out the second it was replaced
14:26:52 <TrueBrain> I love starports .. 2 harvesters for 300 :)
14:30:18 <TrueBrain> FUCKING RETARD! ATe my harvester again :(
14:31:56 <Xaroth> ofc will be replaced once I get the non-emu way in a sensible way
14:32:26 <TrueBrain> of course it can be written much more compact, but yes :p
14:32:33 <Xaroth> that's what I'm doing now :)
14:32:39 <Xaroth> as long as my logic is correct
14:34:39 <Xaroth> @base 2 16 1111111111000000
14:38:43 <Xaroth> come to think of it, wouldn't a PackedTile be more.. neat?
14:39:37 <Xaroth> as a struct, like tile32
14:39:46 <TrueBrain> yeah, you weren't really clear :p
14:39:49 <TrueBrain> and no, in this case that won't help :)
14:39:54 <TrueBrain> uint16 as output is plenty :)
14:40:09 <TrueBrain> the idea of packing is to serialize the data
14:40:26 <Xaroth> i know, for savegames and whatnot
14:40:42 <TrueBrain> so you want to avoid custom formats for that
14:41:30 <Xaroth> how so? isn't it more neat to have a structure for that?
14:41:43 <TrueBrain> it is the serialize data :)
14:41:48 <TrueBrain> not to make it some other kind of format :p
14:41:53 <TrueBrain> then you didn't serialize anything ;)
14:42:10 <TrueBrain> type(serialize(myclass)) : otherclass
14:42:48 <Xaroth> you're the expert in this, i'm just voicing random ideas
14:42:57 <TrueBrain> and I am trying to explain why ;)
14:43:12 <TrueBrain> in the perfect world, it returns a uint8[], but that is a bit unpractical
14:44:23 <Xaroth> anyways, i was trying to figure out how to unpack most efficiently
14:47:00 <Xaroth> right side probably & 0x3F
14:48:13 <Xaroth> hrm, i'm being a dumbass again
14:48:19 <Xaroth> first customer work before i continue
15:05:21 <DorpsGek> Xaroth: 1100101100100
15:07:19 <DorpsGek> SVN: truebrain (r267) [JIT] -Add: mapped another 235 functions (campaign 5, begin of campaign 6 (starport!))
15:07:38 <DorpsGek> SVN: truebrain (r268) -Update (r267): update decompiled code
15:11:30 <Xaroth> getting it unpacked is a pita
15:11:56 <Xaroth> at least, to do it in a small piece of code
15:19:42 <TrueBrain> euh .. darling .. GetPosX returns px, not ox :)
15:20:00 <Xaroth> that was before I realised I was reading the wrong way :P
15:20:41 <TrueBrain> the rest looks fine
15:21:21 <Xaroth> finally something useful :P
15:24:02 <Xaroth> that looks more disturbing on irssi than I had hoped...
15:37:08 <TrueBrain> Parse error: syntax error, unexpected '[', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/publix/php/products.php on line 546
15:37:40 <Xaroth> that still doesn't make sense heh
15:37:50 <TrueBrain> best PHP error EVER!
15:57:15 <glx> it seems dune resizes PSP block
15:57:56 <glx> anyway it does strange things related to memory
15:59:32 <TrueBrain> well, not the PSP block
16:03:37 <glx> at a moment it checks value of 353F:795A but I see no trace of it being set (same for 353F:7A68)
16:04:09 <TrueBrain> either it is pre-set, or it is a bug :)
16:20:16 <glx> hmm what can be in 40:70 ?
16:21:37 <glx> ok its emu_get_memory8 (BIOS_MEMORY_PAGE, 0, BIOS_COUNTER_OVERFLOW)
16:38:18 <glx> ,.../* Unresolved jump */ emu_pushf(); emu_flags.inf = 0; emu_push(emu_cs); emu_cs = emu_get_memory16(0, 0, 0x21 * 4 + 2); emu_push(0x00DD); emu_ip = emu_get_memory16(0, 0, 0x21 * 4 + 0); emu_last_cs = 0x01F7; emu_last_ip = 0x00DB; emu_last_length = 0x0044; emu_last_crc = 0x8C82; emu_call();
16:38:18 <glx> after understanding this part, I know why it does DOS version checks :)
17:02:14 <glx> refreshed, added 4 more variables
17:19:51 <glx> btw the pasted code above is a nice direct call to INT21 handler :)
17:20:14 <TrueBrain> yup, a never-called one
17:20:22 <TrueBrain> so I am not sure if the original int21 is in place, or something took over ;)
17:20:29 <TrueBrain> ./* 7B8C()....*/ <- dots?
17:20:33 <TrueBrain> ./*!< ?? Something related memory. */ <- related 'to'?
17:22:06 <TrueBrain> then all I can say is: you have commit access ;)
17:23:53 <DorpsGek> SVN: glx (r269) -Add: figured out a few variables
17:25:17 <TrueBrain> so I can't run OpenDUNE on my Mac just like that ... what are other solutions ...
17:26:15 <glx> don't use SDL for opendune :)
17:26:29 <TrueBrain> I am not going to write another layer just yet :p
17:26:36 <TrueBrain> that would take an insane amount of time :)
17:43:40 <TrueBrain> whoho, solved the issues .. kind of :)
17:44:42 <TrueBrain> well .. keyboard input not so much :p
17:47:41 * Xaroth goes try LoL (League of Legends)
17:50:17 <TrueBrain> hmm ... on mouse movement and clicks and stuff the code IS called ..
17:55:31 <TrueBrain> I was about to say .. wut thu fuck
17:55:38 <TrueBrain> but okay ... no clue why it doesn't work ..
17:56:23 <TrueBrain> lets watch the intro :)
17:57:07 <TrueBrain> SDL with his stupid libSDLmain.a
17:57:10 <TrueBrain> worst solution ever ...
17:59:11 <TrueBrain> what is it with the first time run? Can someone remind me? :)
17:59:27 <TrueBrain> k, OSX is supported
18:01:11 <TrueBrain> now I installed xcode .. isn't that an IDE too? :p
18:03:42 <TrueBrain> then where is it hiding :(
18:04:01 <TrueBrain> 28 seconds to compile OpenDUNE
18:04:07 <TrueBrain> the exact same time as my normal PC takes :)
18:04:56 <glx> let me start a VM to find where is xcode
18:07:29 <TrueBrain> I expected it under Applications for some odd reason :p
18:08:46 <DorpsGek> SVN: truebrain (r270) -Add: support for OSX (which mainly consentrate around finding SDL)
18:09:53 * blathijs offers to trade TrueBrain's s for a c
18:10:07 <blathijs> I'll add in a free full-stop as well! :-p
18:11:55 <DorpsGek> SVN: truebrain (r271) [LibEMU] -Add: support for OSX (which mainly concentrate around finding SDL)
18:12:02 <TrueBrain> and that is how blathijs makes itself useful :p :p
18:13:15 <blathijs> You forgot the full stop :-p
18:13:22 * blathijs goes back to doing _other_ useful stuff
18:13:32 <TrueBrain> I thought you were going to make a debian package
18:18:09 <TrueBrain> first I couldn't find XCode on the DVDs .. now I can't find, after installing it via the web, the aplpication :p
18:18:39 <TrueBrain> ah, finally found it :)
18:18:45 <TrueBrain> tnx planetmaker (a bit delayed realisation what you were saying :p)
18:28:28 <TrueBrain> now how to enable this nice Build and Run button ..
18:43:21 <TrueBrain> installing Netbeans :p
18:58:44 <glx> TrueBrain: /Developers/Applications
18:59:42 <glx> I started the VM then gone to eat while it boots
19:03:06 <blathijs> TrueBrain: Hehe, I might think about packaging for Debian when a somewhat more stable release comes
19:03:20 <TrueBrain> well, 1st of November will be the 0.1 release
19:03:25 <TrueBrain> and as far as stability goes: it is stable
19:04:03 <blathijs> TrueBrain: But I'm not so sure about the legal status of what you're doing, somehow it seems more directly related to the original code than what ludde did
19:04:23 <blathijs> Then again, that's probably only because I didn't see the first part of his work, I guess :-)
19:04:29 <TrueBrain> what has that to do with making a package for it? ;)
19:05:02 <blathijs> Nothing, but I was also thinking about uploading to Debian :-)
19:05:21 <TrueBrain> that will be tricky ;)
19:05:48 <TrueBrain> the request is STILL pending by EA
19:14:31 <blathijs> Any clue if someone is actually working on your request? Did they give any feedback at all, yet?
19:15:05 <TrueBrain> one of the client of the company I work for is EA Benelux
19:15:09 <TrueBrain> we made a person request there
19:15:34 <TrueBrain> so I am very sure they are working on it :)
19:16:35 <TrueBrain> their official statement is that they do not own the legal rights (anymore)
19:16:36 <blathijs> Ah, that's helpful :-)
19:16:51 <blathijs> But someone is trying to find out where those rights ended up? "-)
19:17:13 <TrueBrain> that is what my request was about
19:22:39 <TrueBrain> I keep on lossing with H ... :(
19:22:55 <TrueBrain> 7 waves later, and their turrets are still up and running :(
19:23:27 <blathijs> TrueBrain: Are you playing the game? You should be coding! :-p
19:23:51 <glx> he needs to play to get more data
19:23:58 <TrueBrain> blathijs: maybe .. I also need to play :p
19:24:45 <Xaroth> blathijs: for me decrypting this is like finding a lost needle in a stack of a gazillion needles
19:24:55 <TrueBrain> Xaroth: and for us it isn't? :)
19:25:05 <Xaroth> TrueBrain: I wasn't saying that :P
19:26:20 <glx> Xaroth: you really think it's easy to find function/variables usage?
19:26:50 <Xaroth> glx: why do you think i try to not burn myself on that :P
19:27:40 <Xaroth> anyways, this league of legends is actually quite entertaining
19:27:53 <Xaroth> for a game made by ex-blizz/ex-wotc people
19:30:21 <blathijs> TrueBrain: If you'd manage to get a hold of the copyright owners and perhaps get a license from them, you'd still need to replace the game content, I expect? Unless you also get a license for using the Dune setting, which is probably even harder...
19:30:26 <TrueBrain> 4 tanks can't win from 1 turret :(
19:31:07 <TrueBrain> blathijs: the request is 3 fold: 1 side the request to allow decompiling, the other to a distribution license for the gfx/sfx, the other a distribution license for the game itself, the stats and scenarios and stuff
19:31:22 <TrueBrain> the first is by far the most important of course
19:32:57 <blathijs> Xaroth: It looks pretty heavy, I can't even play the trailer smoothly :-p
19:33:11 <blathijs> Xaroth: It does have a nice cartoonish style in rendering, it seems
19:36:25 <Xaroth> blathijs: it's a fork of DotA
19:36:55 <Xaroth> DotA is a WC3 mod, LoL (love the name) is a standalone
19:37:02 <Xaroth> seeing they found WC3 to be limiting
19:37:53 <blathijs> Ah, I think I remember someone saying something like that before, didn't remember it was about LoL
19:38:04 <Xaroth> it was most likely Demigod
19:38:12 <Xaroth> which failed miserably :P
19:38:51 <Xaroth> it had no copy protection, so a day before it launched their servers were already down from the load
19:40:15 <Xaroth> and seeing LoL is free, I couldn't resist trying :P
19:41:15 <TrueBrain> I build a starport before I do a radar ...
19:41:33 <Xaroth> you don't need a radar if you have a massive army :)
19:41:57 <TrueBrain> pff, 240 for a harvester
19:52:20 <blathijs> Ah, you could get simple stuff (that you can build as well) through a starport, right?
19:52:38 <TrueBrain> download trunk, and play it for a bit :p
19:52:49 <blathijs> That's an awesome detail that makes it more of a world and less of game :-)
19:53:05 <blathijs> TrueBrain: I really don't have time for that...
19:53:08 <TrueBrain> it has TONS of those things :)
19:53:15 <TrueBrain> I don't have the time either ... ;)
19:55:14 <blathijs> As soon as I have my diploma (which should be in 1-2 months...), I'll try to free up some time
20:06:53 <TrueBrain> my own tanks damage the turrets the most :p
20:08:32 <TrueBrain> for some reason they don't see my vehicle as enemy
20:10:07 <TrueBrain> it also doesn't repair his buildings
20:11:27 <TrueBrain> A5 is much easier than H5 and O5 btw
20:12:42 <TrueBrain> no rocket launchers against you
20:16:49 <glx> the ? arg for Terminate can be different than 0 but the current decompiled code always call it with 0 so I can't know what it does
20:17:25 <TrueBrain> such functions will be taken over by simpler forms anyway :)
20:18:06 <glx> and I found another empty function :)
20:20:24 <TrueBrain> hmm .. A5 doesn't want to continue :p
20:20:29 <TrueBrain> I got: you ahve completed the mission
20:21:25 <TrueBrain> a retry did work :)
20:21:43 <TrueBrain> he destroyed 1 (!) unit of mine :p
20:24:07 <TrueBrain> I need to write down what normal prices are for units :p
20:25:26 <DorpsGek> SVN: truebrain (r272) [JIT] -Add: mapped another 20 functions (campaign 5, begin of campaign 6)
20:25:47 <DorpsGek> SVN: truebrain (r273) -Update (r272): update decompiled code
20:25:56 <TrueBrain> there ... campaign5 should also be playable
20:26:15 <TrueBrain> uploaded latest savegames too
20:32:24 <TrueBrain> out of the blue, my decompiler segfaults :(
20:33:00 <TrueBrain> lol .. svn-commit.tmp was being read :p
20:33:17 <DorpsGek> SVN: truebrain (r274) -Add: name more functions (glx)
20:34:54 <glx> +01F7:031F:0001:6580,...emu_Empty4,...# Function does absolutely nothing
20:37:28 <TrueBrain> so far I kept it 'variable' too
20:37:36 <TrueBrain> where 'variable' means: I DONT KNOW! :p
20:37:51 <glx> but I know it represents a function
20:37:54 <TrueBrain> and please start with ??, makes it easier to parse later on to make cool stats ;)
20:38:01 <TrueBrain> so add it at the ?? :)
20:39:51 <glx> like the refreshed version ?
20:40:50 <TrueBrain> maybe () behind functionname
20:40:53 <TrueBrain> makes Doxygen resolve it :)
20:42:13 <DorpsGek> SVN: glx (r275) -Add: figured out a few variables
20:44:53 <DorpsGek> SVN: truebrain (r276) -Add: one more (empty) function (glx)
20:50:47 <glx> almost half of 01F7 functions are know
20:55:57 <DorpsGek> SVN: truebrain (r277) -Fix: name the function itself, instead of a subfunction of him
21:01:09 <TrueBrain> a megabig function, which is only called once .. the start of it anyway :p
21:03:24 <TrueBrain> as long as 38F8 is non-zero, the game runs
21:04:32 <glx> so another known variable :)
21:04:42 <TrueBrain> well, what is weird about it, is that it is being set too :p
21:04:47 <TrueBrain> by calling a subfunction
21:05:15 <glx> not as weird as the never set variables checked for some values
21:06:36 <TrueBrain> just guessing values here:
21:06:42 <TrueBrain> 76AC / 76AE: mapsize
21:07:47 <TrueBrain> but the code I am looking at is a bit weird, so very unsure :p
21:09:27 <glx> 76AC and 76AE are never set it seems
21:11:00 <TrueBrain> of course it can be that a scenario load or what ever loads it
21:12:40 <DorpsGek> SVN: truebrain (r278) -Add: identified what is most likely the main gameloop
21:13:54 <TrueBrain> okay, opening random files and trying to figure them out appears useless :p
21:14:28 <TrueBrain> but the fact we found main gameloop makes me really happy :)
21:14:41 <glx> f__01F7_01ED_0024_A432() and f__01F7_0231_0021_40ED() are loops
21:15:16 <glx> with some calls that should be goto ;)
21:15:17 <TrueBrain> which makes me wonder why a label was not used
21:15:32 <TrueBrain> oh, I know .. hmm .. tricky problem :)
21:15:58 <TrueBrain> and it leaves a lovely trail emu_calln :)
21:16:04 <TrueBrain> which is HEAVILY invalid in decompiled code :)
21:17:49 <glx> hmm and patched.c is in the middle of f__01F7_01ED_0024_A432()
21:17:52 <TrueBrain> glx: nice catch :) I will try in a few days to make them gotos again, as this is just silly and consuses the compiler :)
21:18:01 <TrueBrain> yup; I didn't feel like patching up the whole function :p
21:18:07 <TrueBrain> so I made it a partly patch ;)
21:18:39 <glx> but that causes the creation of f__01F7_022D_0003_9E5A() which is indeed a part of f__01F7_01ED_0024_A432()
21:19:49 <TrueBrain> maybe you can patch up the whole function?
21:22:58 <glx> something is weird in f__01F7_20B5_0076_64ED() (in your patch)
21:26:00 <Xaroth> TrueBrain: what was the Id thing that needs to be on top of every file .. /* $Id$ */ ?
21:26:40 <glx> and you need to set svn:keywords Id
21:26:50 <Xaroth> my first attempt at actually putting stuff in
21:26:57 <Xaroth> that needs to be put on each file individually?
21:27:11 <glx> properties are per file yes
21:29:11 <TrueBrain> glx: it is a patch to patch up a nasty thing in Dune2, yes
21:29:37 <TrueBrain> one of the functions doesn't return to the normal path
21:29:40 <TrueBrain> but continues somewhere else
21:29:46 <TrueBrain> some kind of protection I can only guess
21:31:40 <glx> unpatched version looks like valid code
21:32:01 <TrueBrain> * Decompiled function f__01F7_0229_0004_BEF7()
21:32:02 <TrueBrain> * Patched for different return-values in rare cases.
21:32:05 <TrueBrain> the unpatched version does not run
21:32:17 <TrueBrain> /* XXX -- One of the above functions doesn't always return the next
21:32:19 <TrueBrain> * function but some other function. For now we capture this in this
21:32:19 <Xaroth> oh right, unpack still sucked arse
21:32:22 <TrueBrain> I wonder why I write comments :)
21:32:29 <Xaroth> let's NOT try to put that one in :P
21:34:10 <TrueBrain> hmmm .. sometimes I must not WANT to resolve unresolved code :p Ghehe :)
21:35:58 <TrueBrain> hmm ... we can't name overlays yet
21:35:59 <Xaroth> surprise surprise, it doesn't compile :P
21:38:08 <Xaroth> ..\src\emu_tile.c(29) : error C2275: 'tile32' : illegal use of this type as an expression
21:38:22 <Xaroth> I think google and I will have a real close session now..
21:38:32 <TrueBrain> or you can show us what is on that line :)
21:39:22 <Xaroth> lemme try this first, give me 3 minutes to see how hopeless it is :P
21:39:27 <Xaroth> tile32 *tile = (tile32 *)emu_get_memory32(emu_ss, emu_sp, 0x0);
21:39:42 <TrueBrain> make sure you included "include/types.h"
21:40:52 <Xaroth> i went shameless and c/p it from other files :P
21:40:56 <Xaroth> to get the idea behind it
21:41:02 <TrueBrain> but you never copied include/types.h
21:41:13 <TrueBrain> well: #include "include/types.h"
21:41:50 <Xaroth> nop, then it just bitches about it not being able to find it :P
21:42:05 <TrueBrain> just copy a header of any file
21:42:15 <TrueBrain> oh, it is #include "types.h"
21:42:21 <Xaroth> and changed <file>.h into tile.h
21:42:24 <TrueBrain> oh well .. if you would have looked in any file you would have seen ;)
21:42:26 <Xaroth> (and created a tile.h DUH)
21:43:08 <TrueBrain> that really took me too long ....
21:43:23 <TrueBrain> and use memory8 version please :)
21:43:25 <Xaroth> (tile32 *)&emu_get_memory32 i take it?
21:43:38 <TrueBrain> you want the pointer to that memory address, so yes ;)
21:43:55 <Xaroth> 1>..\src\emu_tile.c(29) : error C2275: 'tile32' : illegal use of this type as an expression
21:43:58 <Xaroth> 1> g:\openDUNE\trunk\include\types.h(74) : see declaration of 'tile32'
21:44:08 <TrueBrain> what is your line now?
21:44:17 <Xaroth> tile32 *tile = (tile32 *)&emu_get_memory8(emu_ss, emu_sp, 0x0);
21:45:20 <Xaroth> it then continues to bitch for line 29 and 30 about tile being undeclared
21:45:39 <TrueBrain> you included libemu.h?
21:45:45 <Xaroth> 1>..\src\emu_tile.c(30) : error C2440: 'function' : cannot convert from 'int' to 'tile32'
21:46:07 <Xaroth> <assert.h> <stdio.h> types.h libemu.h global.h tile.h
21:46:39 <glx> nice unneeded code, AX=0x0100, CL=some_variable, CH=0, if (CX<AX) { do something }
21:46:39 <planetmaker> hm... bloody highlight on "assert" :-P
21:46:51 <TrueBrain> planetmaker: why? :p
21:46:55 <glx> why the hell does it need to test that
21:47:01 <planetmaker> server crashes announce themselves that way
21:47:05 <TrueBrain> glx: I wonder that often ;)
21:47:13 <glx> of course CX is less than AX
21:47:19 <TrueBrain> Xaroth: it works when I try it here, so ..
21:47:28 <TrueBrain> glx: the same as: if (ax <= 0xFFFF)
21:47:59 <glx> hmm but it needs to test it because there's a loop
21:51:00 <TrueBrain> declare variables before anything else
21:51:11 <glx> ok I found an array indeed
21:53:22 <Xaroth> 1>..\src\emu_tile.c(75) : error C2231: '.d' : left operand points to 'union', use '->'
21:53:27 <glx> for me it's easier to read
21:53:36 <Xaroth> I take that that's GCC required as well?
21:54:01 <Xaroth> or well, as far as my brain understands this code, yes :P
21:55:00 <Xaroth> TrueBrain: looks good to me
21:55:21 <glx> +,...tile32 *tile = (tile32 *)emu_get_memory32(emu_ss, emu_sp, 0x0);
21:55:54 <glx> indeed you must use tile->d.px
21:56:14 <Xaroth> wewt, it continues now :P
21:57:31 <Xaroth> ========== Build: 1 succeeded, 0 failed
21:58:46 <TrueBrain> (you can put a & before it if you really want the pointer, for what ever reason)
21:59:30 <Xaroth> i don't mind the removal of those tabs
21:59:36 <Xaroth> and the csip thing looks much better :o
22:00:10 <Xaroth> MSVC doesn't like all dem labels though, but I really couldn't care less about that
22:00:36 <TrueBrain> I wonder about which tabs Xaroth is talking, but okay
22:00:39 <TrueBrain> glx: more readable?
22:01:02 <TrueBrain> Xaroth: please remove the 'Called From' entries, they are for your own reference only :)
22:01:19 <TrueBrain> + /* Pop the return CS:IP. */
22:01:43 <TrueBrain> + emu_ax = emu_get_memory16(emu_ss, emu_sp, 0x0);
22:01:45 <TrueBrain> + emu_dx = emu_get_memory16(emu_ss, emu_sp, 0x2);
22:01:54 <TrueBrain> I know this will sound silly, but first cast it to a tile32, then get the values
22:02:16 <glx> TrueBrain: way more readable yes
22:02:34 <DorpsGek> SVN: truebrain (r279) -Add: introduce 2 wrappers to fetch a csip32 and/or a tile32 from memory
22:02:42 <TrueBrain> Xaroth: and you have to alter your tile32 fetches a bit ;)
22:03:24 <Xaroth> I was about to suggest that
22:03:28 <TrueBrain> in the header, emu_ below real please :)
22:03:33 <TrueBrain> no silly whitespaces
22:03:43 <TrueBrain> + tile = (tile32 *)emu_get_memory32(emu_ss, emu_sp, 0x0);
22:03:44 <TrueBrain> + emu_ax = tile->s.y;
22:03:51 <TrueBrain> can you make the: emu_ax = Tile_GetY(tile)?
22:04:01 <TrueBrain> again, silly, I know, but it all has to do with conversion later on :)
22:04:12 <TrueBrain> this makes people use the wrappers over the 'fast' way
22:04:18 <TrueBrain> where the wrappers will help us later a lot :)
22:04:26 <TrueBrain> (as in: increasing map-size)
22:04:55 <TrueBrain> and I miss tons of doxygen comments in tile.c ;) Ghehehe :)
22:05:11 <TrueBrain> Tile_GetPosX can return uint8 I guess
22:05:30 <glx> where should I add a struct I partly know the content ?
22:05:38 <TrueBrain> glx: what does it do?
22:06:26 <glx> dunno, it's used by f__01F7_01ED_0024_A432()
22:06:27 <TrueBrain> Xaroth: and what ist he problem with unpack?
22:06:38 <glx> contains 2 bytes and a csip32
22:06:45 <Xaroth> that I hadn't figured out the 'efficient' way yet
22:06:48 <Xaroth> so i hadn't put it in yet
22:07:02 <Xaroth> don't want to compile/test with half working code :)
22:07:25 <TrueBrain> glx: but the struct is in the 'emu_cs', or where?
22:08:01 <TrueBrain> an array with elements of 2 bytes and a csip32?
22:08:19 <glx> an array of this struct yes
22:08:26 <TrueBrain> k, so add the struct in global.h :)
22:08:51 <TrueBrain> looks a lot like ctors
22:09:19 <Xaroth> har, empty comments for now
22:09:48 <TrueBrain> glx: for now, everything in the 353F area, just put in global.h .. if a substruct is needed, so be it
22:10:11 <TrueBrain> readability before anything else for now I guess :)
22:10:24 <TrueBrain> this is a nasty job as it is ;)
22:10:48 <Xaroth> TrueBrain: when putting in the wrappers, &tile ?
22:10:58 <Xaroth> it seems to moan about it :P
22:11:01 <Xaroth> emu_ax = Tile_GetX(tile);
22:11:23 <TrueBrain> if tile is tile32 *, that won't work
22:11:34 <TrueBrain> as the param is 'tile32'
22:11:51 <TrueBrain> but I would suggest removing the pointers all together now there is an easy wrapper :)
22:12:05 <TrueBrain> (it is faster to copy the content of a 32bit variable, then to fetch his pointer :p)
22:12:07 <Xaroth> then how to solve tile = (tile32 *)&emu_get_memory8(emu_ss, emu_sp, 0x0);
22:12:10 <glx> TrueBrain: your editor added some spaces before tabs in global.h :)
22:12:19 <TrueBrain> [00:02] <DorpsGek> SVN: truebrain (r279) -Add: introduce 2 wrappers to fetch a csip32 and/or a tile32 from memory
22:12:24 <TrueBrain> glx: GRRR :( I hate my editor :(
22:12:43 <TrueBrain> Xaroth: and I showed you the patch which comes with that :p Or run: svn diff -r 278:279
22:12:52 <glx> I'll remove them while at it
22:13:05 <TrueBrain> it should never happen ... but somehow ...
22:13:50 <TrueBrain> hmm .. it appears when I refactor that happens ..
22:13:56 <TrueBrain> same as netbeans tends to add #includes :p
22:14:06 <TrueBrain> Xaroth: got it, how to get a tile32 from memory? :)
22:15:04 <TrueBrain> wow ... I have an assert trigger which is legit ...
22:16:03 <TrueBrain> oh, 'cs/ip' got mixed up
22:16:33 <Xaroth> hah, and it compiles again
22:17:59 <TrueBrain> unneeded newlines at top of emu_tile.c
22:18:39 <DorpsGek> SVN: truebrain (r280) -Fix (r279): wrong sp offset
22:18:45 <Xaroth> how come it doesn't moan about tile.d needing to be tile->d in tile.c and it did in emu_tile o_O
22:19:00 <TrueBrain> if tile is a tile32*, it needs ->
22:19:04 <TrueBrain> if it is a tile32, it needs .
22:19:07 <TrueBrain> pointer vs non-pointer
22:19:27 <TrueBrain> (if they are tile32*)
22:19:34 <TrueBrain> s-> in fact is (*s).
22:19:45 <TrueBrain> but you can overload ->, where you can't overload (*s). in the same way
22:20:05 <Xaroth> makes sense, in some wierd kind of way
22:20:23 <TrueBrain> GetPos[XY] can return uint8, not?
22:20:44 <TrueBrain> the rest looks perfect (minus the missing doxygen of course)
22:20:56 <TrueBrain> \ No newline at end of file
22:21:02 <TrueBrain> svn diff tells you what you need to do too :p
22:21:32 <Xaroth> they can return uint8, yeh
22:22:32 <TrueBrain> k, time for my beautysleep
22:22:34 <TrueBrain> I doubt it will help
22:22:36 <TrueBrain> one can at least try
22:47:36 <Xaroth> I can't really PR-talk into telling him we specifically opted against using his stuff for now.
22:53:52 <Xaroth> I'm off to bed as well
22:54:03 <Xaroth> and whoever might still be lurking here :P
continue to next day ⏵