IRC logs for #opendune on OFTC at 2009-09-30
⏴ go to previous day
01:31:01 *** ChanServ sets mode: +v Yexo_
09:20:59 <TrueBrain> sometimes I love things happening on tt-forums :) It makes me smile :)
09:21:07 <TrueBrain> and fed2k sometimes has useful info :) Also makes me happy :)
10:17:27 *** Xaroth has joined #openDune
10:18:23 <Xaroth> -reticulum.oftc.net- Server Terminating: received signal SIGTERM
10:18:34 <TrueBrain> nope .. in result a massive split
10:18:41 <TrueBrain> IRC is not in any way redundant :)
10:18:57 <Xaroth> the network is, the connections.. aren't :P
10:20:12 <Xaroth> anyways, hopefully today i can spend some dedicated time on opendune
10:20:28 *** ChanServ sets mode: +o Xaroth
11:25:27 <Xaroth> hm, picked a random file to start fiddling with
11:25:42 <Xaroth> ... cs__0C3A is 9000+ lines...
11:27:41 <TrueBrain> LOL! You did pick a nice file :p
11:28:15 * Xaroth goes pick another random file
11:28:29 <TrueBrain> I can't figure out what the first few functions do (well, not 1-2-3 anyway)
11:29:14 * Xaroth sorts on size, then picks again
11:29:34 <TrueBrain> the smallest one are not easy either :p
11:29:43 <Xaroth> oh great, that was the single largest file in /decompiled
11:30:32 <Xaroth> in other words, a pain
11:30:46 <TrueBrain> well, you need entries to figure out what things do
11:30:51 <TrueBrain> like I know of a few that they are file related
11:30:54 <TrueBrain> then it might be doable :p
11:31:32 <Xaroth> true, but it's probably better to rebuild some of the smaller files to make that part easier
11:32:06 <Xaroth> right, cs__B52A isn't that big
11:32:12 <TrueBrain> so you need to find an entry-point somwhere :)
11:32:36 <Xaroth> /* Check if this overlay should be reloaded */
11:32:43 <Xaroth> what does that comment indicate?
11:32:51 <TrueBrain> that the line below is inserted by the decompiler
11:33:02 <TrueBrain> every time an overlay calls something outside its own overlay, it might happen he gets unloaded from memory
11:33:10 <TrueBrain> the next line makes sure it is reloaded
11:33:53 <TrueBrain> when an overlay is no longer using any local variables, it can be removed (Well .. then you can no longer attach the JIT, so not sure about that statement, but okay :p)
11:34:33 <TrueBrain> we need something clever to know what a function does, well, at least an idea
11:34:45 <TrueBrain> as we are working a bit working in the blind here :)
11:35:18 <TrueBrain> english very good is mine
11:37:58 <TrueBrain> either way, the only reason I am still working on the input only, is that I hope that it will show a few places to continue at :p
11:38:14 <TrueBrain> I for example did find the place where you get such a 'hint' in-game, which waits for a mouse-click :p
11:38:56 <Xaroth> well having a subsystem fully rebuilt means you can more clearly see where it's being used in other sections
11:41:17 <TrueBrain> but it sucks it is so hard to find places to start :p
11:41:33 <TrueBrain> I guess you can just start somewhere, and hope to figure out what the fuck that function does :p
11:43:58 <Xaroth> get_memory16( ss, cs, -0x2 )
11:44:13 <TrueBrain> that is invalid in many ways :p
11:45:08 <Xaroth> well, the value of sp, in bp
11:45:10 <TrueBrain> sp can happen too .. less often ;)
11:45:23 <Xaroth> I'm trying to figure out what's going on
11:45:48 <Xaroth> that line is getting the first local var isn't it?
11:45:49 <TrueBrain> min values there are local variables
11:46:03 <TrueBrain> +0x6 is the first parameter
11:46:07 <Xaroth> emu_movw(&emu_get_memory16(emu_ds, 0x00, -0x7303), 0x290);
11:46:15 <TrueBrain> (or +0x4, depending if it is a near of far call :p)
11:46:33 <TrueBrain> @calc 0x10000 - 0x7303
11:46:39 <TrueBrain> I should fix that :p
11:47:13 <Xaroth> local vars, what scope does that mean, class-based or function-based?
11:47:25 <TrueBrain> you can 'assume' that in such cases 'emu_ds' is 0x353F
11:47:43 <TrueBrain> emu_cs are 'class' based (or file-based rather)
11:47:48 <TrueBrain> and emu_ds are global
11:47:57 <TrueBrain> (assuming cs is not assigned to ds, etc etc)
11:48:26 <Xaroth> so that line is basically getting a global var
11:48:34 <Xaroth> or rather, assigning it in this case
11:48:51 <TrueBrain> g_input->variable_8CFD = 0x290 ;)
11:49:03 <TrueBrain> (where g_input of course should be renamed to what ever it is related too :p)
11:49:14 <TrueBrain> maybe we should just make it g_global :p
11:49:56 <TrueBrain> the next few lines are a bit tricky :)
11:50:37 <TrueBrain> you can call a function like: int b = 1; a(b); or int b = 1; a(&b)
11:50:47 <TrueBrain> (by-value and by-reference)
11:51:04 <TrueBrain> push(ds); push(0x8CFD) is a by-reference
11:51:57 <Xaroth> so technically, f__B50B_0608_002C_0256 is being called with a ton of arguments
11:52:13 <TrueBrain> 4, if I count correctly
11:53:03 <Xaroth> emu_movw(&emu_get_memory16(emu_ss, emu_bp, -0x2), 0x0);
11:53:09 <Xaroth> can that be fully replaced
11:53:16 <Xaroth> uint16 local_variable1 = 0x0;
11:53:27 <Xaroth> or can that cause problems outside it's scope
11:53:37 <TrueBrain> in theory, that should be fine
11:53:52 <TrueBrain> sometimes it is abused, so I normally leave it like: emu_get_memory16(emu_ss, emu_bp, -0x2) = 0x0;
11:53:59 <TrueBrain> and when I hav ethe whole function mapped, I replace it with what ever
11:54:16 * Xaroth switches comments around
11:56:08 <Xaroth> too bad there's no easy way of throwing more people at this problem to solve it quickly :P
11:57:09 <TrueBrain> it just takes a lot of time :)
11:58:42 <TrueBrain> in the beginning you will have tons of 'unknowns' :p
11:58:50 <TrueBrain> but sooner or later that will be solved :)
11:58:52 <Xaroth> yeh, hence having more people to throw at it :P
11:58:59 <TrueBrain> for OpenTTD it took several years :p
11:59:32 <Xaroth> emu_push(emu_bp); emu_movw(&emu_bp, TrueBrain);
11:59:38 <Xaroth> there, now there's two of you.
11:59:48 <TrueBrain> but only one is still active :p
12:00:23 <TrueBrain> but you will see it slowly gets momentum
12:00:35 <TrueBrain> at first it is hard to figure things out, but the more you knwo the surrounding, the easier it will get
12:01:01 <Xaroth> but still, we only have one who actually knows what he's doing.. and one who's trying :P
12:02:21 <Xaroth> anyways, time to get a drink, then more trying :P
12:06:18 <Xaroth> emu_push(glx); emu_movw(&glx, TrueBrain); emu_push(Xaroth); emu_movw(&Xaroth, TrueBrain);
12:06:48 <TrueBrain> I am happy you are starting to understand things :p
12:07:20 <Xaroth> now just to get it to work
12:09:39 <TrueBrain> I finally managed to match a piece of code segra posted :p
12:10:34 <TrueBrain> f__0C3A_0049_00D1_D261 is structureCreate, according to segra :)
12:11:25 <TrueBrain> lol, where I had no clue when you started to talk about it, it makes a bit more sense now :p
12:11:29 <Xaroth> g_unknowndata->variable_8CFD = 0x290;
12:11:45 <TrueBrain> creating such structs is a bitch btw :p
12:11:52 <TrueBrain> calculating all the right offsets and shit
12:11:58 <Xaroth> what structs? like InputData?
12:12:07 <Xaroth> meh, i'll deal with that when I get there :P
12:12:42 <Xaroth> typedef struct B50B_Data {
12:12:54 <Xaroth> calling it to the cs for now, until I know what it is
12:13:10 <Xaroth> might need to rename g_unknowndata tho
12:13:35 <TrueBrain> no, that is a bit wrong :)
12:13:45 <TrueBrain> B50B suggests local variables (emu_cs, 0x0 shit)
12:13:59 <TrueBrain> might be better, yes
12:14:19 <Xaroth> until better namings can be made
12:15:07 <Xaroth> emu_movw(&emu_ax.x, emu_bp - 0x2);
12:15:27 <Xaroth> doesn't that make it point towards local var 1/
12:15:51 <TrueBrain> (well, ss:ax does :p)
12:16:19 <TrueBrain> which most likely means that the local variable is sent by-reference to a subfunction
12:16:29 <TrueBrain> making it impossible at this stage to make it a real local variable :p
12:16:52 <TrueBrain> as I said: keep thing how they are in the first time over
12:17:08 <TrueBrain> nothing wrong with that :p
12:17:13 <Xaroth> /* 8CFD */ uint16 variable_8CFD;
12:17:19 <TrueBrain> well, besides the fact you picked the wrong copy/paste ;)
12:17:26 <Xaroth> er, emu_ds is above that
12:17:27 <TrueBrain> it is push(cs), push(ip)
12:17:51 <TrueBrain> that is the reason we for now just attach C-structs around the memory
12:17:56 <TrueBrain> then such pieces of code still work
12:18:00 <TrueBrain> later on of course that needs to be fixed
12:18:25 <TrueBrain> the reason I could optimize most of the input functions, is because they are 'end' functions. In other words: they no longer call another function
12:18:36 <Xaroth> but isn't it 3 arguments then?
12:18:40 <TrueBrain> functions that still call other functions can't get much optimization
12:18:46 <Xaroth> no wait, emu_bp is pushed ofcourse
12:18:53 <TrueBrain> no, that is not given to the function
12:19:04 <TrueBrain> but first there is a push of ax, then a ds:8cfd, then 2 ss
12:19:13 <TrueBrain> (one local, and one parameter)
12:19:33 <Xaroth> push ax, push ds:8cfd, push ss:ax, push ss:ax
12:19:43 <Xaroth> where AX is set differently each time
12:19:52 <TrueBrain> bp+6 and bp-2, if I remember correctly
12:19:59 <Xaroth> the first AX is then a value?
12:20:36 <TrueBrain> emu_movw(&emu_ax.x, 0xE6);
12:21:14 <TrueBrain> for some reason 14 entries are removed from the stack, where there are only pushed 7 ...
12:21:57 <Xaroth> void f__B50B_0608_002C_0256()
12:22:03 <Xaroth> and pushes a lot of stuff
12:22:23 <TrueBrain> LOL! Dah ... 7 WORDS are pushed
12:22:27 <TrueBrain> so 14 BYTES need to be removed
12:22:30 <TrueBrain> nevermind my comment :)
12:22:51 <TrueBrain> (the caller of a function needs to remove the parameters he gave to a function)
12:23:41 <TrueBrain> if you btw check that function, you see he calls a function in 01F7, and does something with the return values
12:24:05 <TrueBrain> which makes 0608 a wrapper around 01F7 function
12:25:19 <Xaroth> so Bla->Call could wrap Something->CallBla
12:25:22 <Xaroth> by doing something like that
12:25:39 <TrueBrain> I have no idea why it would do that ... I am sure it has a good reason :p
12:26:32 <TrueBrain> but he, welcome to my hell :p
12:27:22 <Xaroth> I think I need a simpler thing to start with :P
12:27:39 <TrueBrain> I wish I could point you to one ....
12:28:17 <TrueBrain> emu_movw(&emu_get_memory16(emu_ss, emu_bp, -0x4), emu_ax.x);
12:28:18 <TrueBrain> emu_movw(&emu_ax.x, emu_get_memory16(emu_ss, emu_bp, -0x4));
12:28:50 <TrueBrain> that is sets the local variable is important
12:28:57 <TrueBrain> just the secondline is completely useless
12:30:14 <TrueBrain> f__0C3A_0049_00D1_D261()
12:30:21 <TrueBrain> it is full of emu_lfp
12:30:26 <TrueBrain> but .... the data never changes :p
12:30:39 <TrueBrain> so it looks more complicated then it really is :p
12:31:13 <TrueBrain> I guess that is something you can work on
12:31:28 <TrueBrain> if segra is right, and why wouldn't he be, it is about building a structure
12:31:40 <TrueBrain> then all you need to know is that in the local var bp-0x04 is the pointer to the building
12:31:51 <Xaroth> void f__0C3A_0046_0003_DDBA()
12:31:51 <Xaroth> { f__0C3A_01B4_0006_F7CE(); return;
12:32:04 <TrueBrain> yeah ... assembly logic .. but looks odd in C :P
12:32:18 <TrueBrain> all things I could let the decompiler resolve, but I am not sure that really helps/works ;)
12:32:40 <Xaroth> it shouldn't be the decompiler doing that
12:32:43 <Xaroth> maybe something in the middle
12:32:57 <TrueBrain> haha, yes, we call that the decompiler :p
12:33:16 <TrueBrain> this is the first stage output of the decompiler .. in theory I should write asecond stage, which does optimization of the C code
12:33:58 <TrueBrain> (resolving jumps, unrolling, creating C structs, C ifs, fors, ...
12:34:34 <Xaroth> I'm not seeing LFP in the reference thingie
12:34:38 <TrueBrain> but okay, the 0C3A function reveals a bit about the building structure
12:34:46 <TrueBrain> LFP -> Load Full Pointer
12:35:01 <TrueBrain> emu_lfp(&emu_es, &emu_bx.x, &emu_get_memory16(emu_ss, emu_bp, -0x4)); is nothing else then:
12:35:09 <TrueBrain> emu_es = emu_get_memory16(emu_ss, emu_bp, -0x4);
12:35:12 <TrueBrain> emu_bx.x = emu_get_memory16(emu_ss, emu_bp, -0x6)
12:35:17 <TrueBrain> or the other way around
12:35:20 <TrueBrain> can never remember :p
12:35:50 <TrueBrain> emu_bx.x = emu_get_memory16(emu_ss, emu_bp, -0x4);
12:35:54 <TrueBrain> emu_es = emu_get_memory16(emu_ss, emu_bp, -0x2);
12:36:09 <Xaroth> why is it constantly doing the same then o_O
12:36:10 <TrueBrain> (no the stack is first cs, than ip)
12:36:15 <TrueBrain> well .. I have an idea why
12:36:29 <TrueBrain> in C it would be like: (*building)->type = 1;
12:36:39 <TrueBrain> the (*building) does the lpf, which is normal
12:36:42 <glx> I can't find any emu_jmp* in opendune, that's strange :)
12:37:02 <TrueBrain> glx: they shouldn't be there, so that is a good thing :)
12:37:05 <TrueBrain> it is only used in the JIT :)
12:37:40 <TrueBrain> in the output they are all either resolved, or written in the right form as a emu_call()
12:37:57 <TrueBrain> if (!emu_flags.zf) { /* Unresolved jump */ emu_ip = 0x00B5; emu_last_cs = 0x0C3A; emu_last_ip = 0x0098; emu_last_length = 0x00D1; emu_last_crc = 0xD261; emu_call(); return; }
12:38:01 <TrueBrain> once was a emu_jmp ;)
12:39:17 <TrueBrain> oh, I can't wait till I have my macbook, then I can work on this in class, and in the train, and and and :p
12:39:47 <TrueBrain> it is ordered, so yes :)
12:40:05 <glx> maybe you can help openttd
12:40:26 <TrueBrain> glx: currently, that is a big no. It would need so much convincing a certain person, it is not even funny to start with that
12:40:39 <TrueBrain> I guess it needs a bit of time for him to cool down, to open the way for improvement
12:40:48 <TrueBrain> (no offense meant, just stating facts)
12:41:04 <Xaroth> does his name start with a p? :o
12:44:14 <TrueBrain> hmm .. if I read this code correct, we never did any building with houseid != 0
12:44:22 <TrueBrain> so either segra is wrong, or it is not true :p
12:45:07 <TrueBrain> ah, no, I take that back :)
12:45:11 <TrueBrain> it is just unusual to be called :p
12:45:44 <TrueBrain> look in libemu to read exactly what it does :)
12:45:55 <TrueBrain> I can only guess it does something like: width * height
12:46:02 <TrueBrain> but I am far from sure :)
12:46:07 <Xaroth> IMUL -- Signed Multiply
12:46:15 <TrueBrain> the 'u' means unsigned
12:46:23 <TrueBrain> I believe it is caleld there IUMUL or UIMUL
12:46:43 <Xaroth> MUL -- Unsigned Multiplication of AL or AX
12:47:04 <TrueBrain> open libemu/src/math.c, and look for what it does exactly :p
12:48:00 <Xaroth> int32 res = (int16)emu_ax.x * val;
12:48:00 <TrueBrain> Xaroth: I tihnk the first function (which reaches down to 01B4) of 0C3A is good doable
12:48:16 <Xaroth> f__0C3A_0009_0029_BF94 << working on that one now
12:48:22 <Xaroth> see how far i get until i deadlock myself :P
12:48:34 <TrueBrain> when you don't know how to translate it, leave it
12:48:40 <TrueBrain> as simple as that :)
12:49:06 <Xaroth> param 1 of emu_imuluw isn't used?
12:49:27 <TrueBrain> that was just required to keep things in an equal flow
12:49:33 <Xaroth> yet emu_ax is sent as param 1, and it's used inside the function
12:49:37 <TrueBrain> mul and div are 2 NASTY opcodes
12:50:26 <TrueBrain> ignore the first param, use the second param only
12:50:40 <TrueBrain> what it does is: (signed version of)emu_ax.x times the second param
12:50:48 <TrueBrain> emu_ax gets the lower 8 bits
12:50:55 <TrueBrain> (still sign extended, both)
12:51:33 <TrueBrain> it is a bit annoying that it is stored in 2 registers ..
12:52:01 <TrueBrain> imulw makes more sense :p That just does what it says it does (still signed)
12:52:04 <Xaroth> f__0C3A_0009_0029_BF94 exits to 1082:01E8
12:52:23 <TrueBrain> are we reading the same code? :p
12:52:33 <TrueBrain> it does call that function, yes, but it is a function-call
12:52:37 <TrueBrain> and 1 thing about function-calls
12:52:40 <TrueBrain> they ALWAYS return :)
12:52:50 <TrueBrain> (well .. ignoring overlays, they do for Dune2 in all cases :p)
12:52:56 <TrueBrain> so for Dune2 you can safely assume it always returns :p
12:53:24 <glx> unless it infinitely recurse :)
12:53:25 <Xaroth> stuff pushed on the stack prior to calling, does that need to be cleaned up?
12:53:26 <TrueBrain> jumps .. jumps don't return :)
12:53:35 <TrueBrain> glx: not happing in Dune2 ;) Not with calls anyway ;)
12:53:36 <Xaroth> or should the called function clean up
12:54:02 <Xaroth> stuff is pushed to stack, then a jump is made
12:54:11 <Xaroth> once that returns, is the stuff pushed to stack still on the stack?
12:54:26 <TrueBrain> that you see below: pop(cx); pop(cx)
12:54:37 <TrueBrain> not that it uses the 'cx' value, but it removes the si and bp+0x6 pushed earlier
12:54:47 <Xaroth> emu_push(emu_cs); emu_push(0x0032); emu_cs = 0x1082; f__1082_01E8_0020_FFB9();
12:54:50 <Xaroth> f__0C3A_0032_0017_67B7();
12:54:51 <TrueBrain> as said above: the caller should always clean the params he sent to a function
12:55:23 <Xaroth> hm, dunno why i actually pasted that
12:55:28 <Xaroth> damned rightmouseclickpaste
12:55:48 <TrueBrain> keep track of @implements btw
12:56:01 <TrueBrain> you can of course merge 0C3A:0009 with 0C3A:0032
12:56:07 <TrueBrain> but make sure you move the @implements to the 0009
12:56:11 <Xaroth> copying the commentblocks so I keep track of it
12:56:15 <TrueBrain> (and remove the () behind it, as it is no longer callable)
12:56:34 <TrueBrain> every @implements with a () behind it,means it can call @name with those params
12:56:50 <TrueBrain> see input.c for how it is meant to be used :)
12:57:50 <Xaroth> in 0032 it's using ss:bp -0x2 .. that's -new- localvars right?
12:58:21 <TrueBrain> (or sp, for that matter)
12:58:38 <TrueBrain> remember that even so there are multiple functions in C, it in fact is one big function down to 0Bsomething
12:58:47 <TrueBrain> (and it should become 1 function :p)
12:59:09 <TrueBrain> LOL! TMF just told me Micheal Jackson is not doing that well
12:59:13 <TrueBrain> might be the fact that he is dead
12:59:16 <TrueBrain> but that might just be me ...
12:59:29 <Xaroth> emu_movw(&emu_get_memory16(emu_ss, emu_bp, -0x4), emu_ax.x);
12:59:29 <Xaroth> emu_movw(&emu_ax.x, emu_get_memory16(emu_ss, emu_bp, -0x4));
12:59:33 <TrueBrain> if you re-air a past movie, please ... update such important facts :p
12:59:40 <TrueBrain> Xaroth: didn't I paste that above too? :p
13:01:11 <TrueBrain> btw, function 0032 tells you a few things not clearly visible:
13:01:18 <TrueBrain> so far the ALWAYS jumped to 0049
13:01:25 <TrueBrain> (as the last function is unresolved)
13:01:33 <TrueBrain> and the unresolved function is in fact resolvable
13:01:43 <TrueBrain> (as it jumps to 0C3A:01B4, which you already have)
13:01:58 <TrueBrain> so despite the fact it was never called, you can resolve it by hand
13:02:18 <Xaroth> so what happened after the if, is never 'ran'
13:02:36 <TrueBrain> if ((var1 & var2) != 0) jump 0049
13:02:53 <TrueBrain> so what ever f__1082_01E8_0020_FFB9 does, it always worked
13:02:58 <TrueBrain> I can only guess it was locating memory
13:03:39 <TrueBrain> revisiting lines higher, I can only guess the imul is used to calculated the required memory
13:04:01 <Xaroth> emu_xorw(&emu_dx.x, emu_dx.x);
13:04:20 <TrueBrain> and 1B4 exists the function
13:04:48 <Xaroth> i can manually resolve those calls, right?
13:05:03 <Xaroth> by removing the emu_ip; ; ; ; ; emu_call(); by f_XXXXXXXX()
13:05:23 <Xaroth> now I know what happened to your english
13:05:56 <TrueBrain> so if we assume the 1082 functionreserves memory, the new location is at ax:dx (which makes sense later on)
13:06:07 <TrueBrain> and if for what ever reason both values return 0, it quits
13:06:13 <TrueBrain> (as memory allocation failed)
13:06:33 <TrueBrain> and normally in ax:dx on return is the pointer to the new building struct
13:06:41 <TrueBrain> (Oh, I love this big jigsaw :p)
13:07:33 <TrueBrain> the last part I btw deduced from the fact 01AB sets dx:ax to the same value retrieved from the 1082 function, then exists :p
13:07:46 <TrueBrain> so .. I write down here that 1082 most likely locates memory :p
13:08:06 <TrueBrain> and I think I also find the 'free' function
13:08:24 <Xaroth> f__0C3A_0049_00D1_D261 is huge :o
13:08:31 <TrueBrain> yes, but try translating it
13:08:35 <TrueBrain> it is not as bad as you think
13:08:39 <TrueBrain> it just is nasty to read
13:08:58 <Xaroth> lots of unresolved calls in that
13:09:07 <TrueBrain> only appears that way
13:09:10 <TrueBrain> if you check the next functions
13:09:16 <TrueBrain> which every time contains another 'snapshot' of that function
13:09:20 <TrueBrain> you will notice most do in fact resolve
13:09:36 <TrueBrain> (the part the decompiler could help with too, but doesn't :p)
13:10:37 <TrueBrain> all part of this jigsaw :p
13:11:04 <TrueBrain> the first 5 function went terrible slow for me, but now I understand how to do things, and I found a nice way to do so, it is goes much easier ;)
13:11:32 <TrueBrain> up to f__0C3A_011A_000A_817C is all in fact the function starting at 0049 :p
13:11:44 <TrueBrain> (not including f__0C3A_011A_000A_817C btw :p)
13:12:38 <TrueBrain> I suggest you make a 'Building' struct, with all variables_0008 and shit for now
13:13:01 <TrueBrain> and do something like: Building *b = (Building *)&emu_get_memory8(emu_es, emu_bx.x, 0x0)
13:13:05 <TrueBrain> after the first lfp
13:13:12 <TrueBrain> or use dx:ax at a sooner point :p
13:13:20 <TrueBrain> and name 'b' a bit more sane I guess :) But you get the point ;)
13:13:58 <TrueBrain> either way, I got to go .. I am back late tonight
13:14:13 <TrueBrain> Xaroth: just leave me a patch when you are done with the function, then I will check what you did ;)
13:14:35 <TrueBrain> that what you don't know, just leave the current code, and we will sort that out later :)
14:01:17 <Xaroth> right, this function is confusing as hell
20:20:45 <TrueBrain> Xaroth: in 0049, a lot of lines are no longer needed
20:20:50 <TrueBrain> as es and bx do not change
20:21:12 <TrueBrain> also, emu_ax and stuff is often used as temp register, so you can resolve that too :)
20:22:02 <TrueBrain> and as I said, you can put Building in a struct :)
20:23:10 <TrueBrain> the rest looks relatively nice :) Just you can also resolve the two functions
20:23:24 <TrueBrain> f__0C3A_0095_0085_1C53 <- that just skips the next 3 lines I believe
20:23:29 <TrueBrain> so invert the check, and put those in it ;)
20:27:16 <Xaroth> I'll have a look at it tomorrow, seeing I still don't figure half of what's actually happening..
continue to next day ⏵