IRC logs for #opendune on OFTC at 2009-12-11
⏴ go to previous day
00:28:05 *** ChanServ sets mode: +o glx_
00:30:06 *** glx is now known as Guest1171
09:54:28 <TrueBrain> there is no way the above patch works for glx :p
10:04:16 <DorpsGek> SVN: truebrain (r729) -Add: remove the 3EEE functions, as they are stack functions, and always call INT10 (patch by glx)
10:06:57 <TrueBrain> because it contained wrong code
10:07:19 <TrueBrain> he replaced 'bp' with 'sp', but in this case, that is wrong
12:10:18 <DorpsGek> SVN: truebrain (r730) -Add: renamed and named a few functions/variables
13:00:40 <glx> 86 ,...,... assert(!"Invalid video mode call"); <-- not true :)
14:08:08 <TrueBrain> glx: well, your patch was broken :p
14:09:08 <TrueBrain> you should not always replace 'bp' with 'sp' .. it doesn't always turn out for the best ;)
14:09:36 <TrueBrain> but fix the assert text if you like :)
14:12:10 <DorpsGek> SVN: truebrain (r731) -Add: named one more function
14:13:54 <glx> that way if a new function is created (different interrupt) we can get the generated code
14:14:45 <TrueBrain> it never happened before
14:14:52 <TrueBrain> so I really REALLY doubt it will ever happen :p
14:15:42 <TrueBrain> so I rather have it assert, then giving me a crash.bin :)
14:15:53 <TrueBrain> as the crash.bin would make things ... hard!
14:16:17 <TrueBrain> and with an assert, we know exactly where to look :) That is why I went for an assert in this case
14:16:41 <DorpsGek> SVN: truebrain (r732) -Add: named one more function (follow-up on r731)
14:16:51 <TrueBrain> I should learn to look ahead :p Avoids so many commits ..
14:19:46 <TrueBrain> slowly I manage to name all functions in 1A34 :)
15:16:40 <DorpsGek> SVN: glx (r733) -Add: figured out a few variables
15:51:59 <DorpsGek> SVN: glx (r734) -Add: named and C-ified Unit_GetTeam()
17:04:28 <TrueBrain> lol @ fact C function longer than emu_ function was :p
17:04:41 <TrueBrain> rather: emu_ function longer than f__ function was
17:05:04 <TrueBrain> weird that it is only used once ....
17:13:38 <glx> I'm on f__0FE4_0002_0021_D0A9
17:13:47 <glx> I can name it after conversion :)
17:17:05 <glx> and I can name 2 house variables too I think :)
17:49:40 <TrueBrain> I still wonder what variable_09 is exactly ..
17:49:50 <TrueBrain> it is (1 << playerHouseID) for your units
17:49:59 <TrueBrain> or the other way around
17:50:25 <TrueBrain> then Enemy will never be triggered
17:50:37 <glx> well for A1 it's 0xFF for me and 0x00 for ordos
17:51:25 <TrueBrain> it btw is a poor 'sort'
17:51:31 <TrueBrain> with only one iteration
17:51:34 <glx> maybe enemy is triggered for deviated
17:52:02 <TrueBrain> btw, 0x00 should never happen, it should be 0x01
17:52:30 <TrueBrain> s->variable_09 |= 1 << s->houseID;
17:52:32 <TrueBrain> if (s->houseID == g_global->playerHouseID) s->variable_09 |= 0xFF;
17:52:33 <TrueBrain> for structures anyway
17:52:39 <TrueBrain> (but they are shared with units)
17:53:02 <TrueBrain> scenario units have 0x00
17:53:23 <glx> so what I noticed is correct :)
17:53:46 <TrueBrain> still, what the fuck does it do ...
17:57:11 <TrueBrain> as its value just doesn't make sense to me :p
17:58:03 <TrueBrain> but okay .. back to this algorithm: I dunno if you amde it correct, but currently it can do the same unit over and over with the unitCountallied++ thingy :p
17:58:12 <TrueBrain> (if it switches, to be exact)
18:03:19 <glx> true, but I think I did it correctly
18:04:10 <TrueBrain> I believe you; but that makes this a sucky functions :p
18:04:43 <TrueBrain> but this is a fundamental flawed one
18:04:52 <TrueBrain> you can't sort and calculate in the same routine
18:05:03 <TrueBrain> or our idea of the counts is wrong, and it counts something compeltely different :p
18:06:33 <glx> without knowing exactly what variable_09 do it's not easy
18:07:16 <TrueBrain> (I btw assume you spotted the space error too ;))
18:07:58 <TrueBrain> + y2 =Tile_GetY(u2->position);
18:08:25 <TrueBrain> either way: weird function ....
18:09:05 <TrueBrain> either way, I am going to look at the first function in 1A34 .. it is long, and I have no clue what it does :p
18:09:13 <TrueBrain> so I am going to try your method, and C-ify it ;)
18:10:36 <glx> so Unit_Sort() is a good enough name?
18:10:52 <TrueBrain> yeah, sure, will do for now
18:11:13 <TrueBrain> I guess the routine only 'works' if one unit moved
18:12:37 <TrueBrain> glx: and only on Y, which makes it odd again
18:27:36 <TrueBrain> wondering if it needs a XXX
18:27:39 <TrueBrain> or that the ?? is clear enough
18:27:48 <TrueBrain> (my IDE indexes the XXX :p)
18:28:01 <TrueBrain> no, the ?? should be sufficient enough clue :p
18:28:16 <glx> we used ?? for all unsure stuff
18:28:40 <TrueBrain> yeah, but they are most of the time also still variable_
18:28:50 <glx> hmm I should mark the 2 variables "unsure" too :)
18:28:52 <TrueBrain> now we have a fully named function, so there the confusion can be a bit higher
18:29:46 <glx> so XXX for the function and the variables?
18:30:04 <TrueBrain> we have been using that now, I guess at the end a search forit should just result 0
18:30:12 <TrueBrain> but I was mostly wondering if it requires more talk why it is a bit weird
18:30:25 <TrueBrain> and if it needed informationa bout the fact it can only look at one unit for the ++ thingies
18:33:20 <TrueBrain> okay, this function really really is going in a WEIRD direction
18:33:29 <TrueBrain> if (tile.d.ux != 0 || tile.d.uy != 0) {
18:53:31 <DorpsGek> SVN: glx (r735) -Add: named and C-ified Unit_Sort()
18:56:14 <TrueBrain> I think function handles projectiles
18:56:18 <TrueBrain> weird stuff happens
18:57:31 <TrueBrain> oh, I think this covers when a carry-all crashes
18:57:35 <TrueBrain> as what ever unit is below it, it takes with it
18:59:05 <TrueBrain> shot down by enemy turrets
19:04:13 <glx> oh you inverted args for emu_Map_DeviateArea ;)
19:04:21 <TrueBrain> I only give it a quick look
19:04:25 <TrueBrain> it is just meant as hints
19:16:01 <TrueBrain> okay .. a bit sick of this ... a pain in the ass, this function
19:16:07 <TrueBrain> but for sure it handles the projectiles
19:17:22 <TrueBrain> enough for today :)
22:04:34 <glx> hmm ok I know how to convert f__252E_0001_0018_08B3() but I can't name it :)
22:04:51 <glx> same for the other function in this file
22:05:24 <glx> it's something like emu_Tools_GetMemoryBase()
22:05:45 <glx> but I'm not sure about the name
22:21:08 <Xaroth> had a fieldtrip with the office
22:36:56 <TrueBrain> glx: maybe only convert such functions, but keep a name like emu_Unknown_252E_0001
22:37:24 <glx> doesn't help to understand other functions ;)
22:37:50 <Xaroth> no, but a C-ified function is easier to read over quickly and understand than a non-C-ified :P
22:37:58 <Xaroth> so it helps, indirectly
22:38:48 <Xaroth> especially for the asm-impaired
22:38:57 <glx> anyway these 2 functions return CS:0000, with CS taken from an array
22:39:04 <TrueBrain> so yous ay, if we make everything C functions, you can give them names Xaroth? :P
22:39:16 <TrueBrain> euh, wait, 252E .. hmm ..
22:39:33 <Xaroth> but at least i'll know some parts of what they do without getting a headache! :P
22:39:48 <TrueBrain> ah, nevermind, I don't have 252E on record :p
22:39:51 <TrueBrain> the values look too much alike :p
22:40:07 <glx> asm is not hard to read :)
22:40:18 <Xaroth> read no, understand, yes :P
22:40:26 <glx> I used to code in z80 asm for my ti85
22:40:27 <TrueBrain> glx: so either commit the C-ified function, or continue on the next :)
22:40:39 <TrueBrain> Xaroth: assembly is a bit 'reading between the lines'
22:40:47 <TrueBrain> not everything is important .. you just need to get the general feeling
22:41:00 <Xaroth> yeh, I still need to figure out what i can safely ignore :)
22:41:05 <TrueBrain> if I read a compare with a lpf above it, and at offset 0x2, I know it is requesting a 'type'
22:41:08 <glx> the harder part is following local variables ;)
22:41:23 <Xaroth> I'm slowly getting the lpf thing
22:41:34 <TrueBrain> the '->' part in C :)
22:41:59 <TrueBrain> glx: but if you C-ified it, I rather have you commit that in some file like: emu_unknown.c or what ever, then removing it again
22:42:05 <TrueBrain> anything that is done, doesn't need to be done again :)
22:42:42 <glx> not C-ified yet (only in my head)
22:42:48 <TrueBrain> I do that all the time :)
22:43:06 <TrueBrain> I read 5 1A34 functions, I can name 1
22:43:11 <TrueBrain> (while understanding 4)
22:43:22 <TrueBrain> but slowly, because they call eachother a lot, I can guess the others
22:43:44 <glx> anyway emu_unknown.c is a good idea :)
22:43:44 <TrueBrain> I have to say the Tile_ shit is helping _a lot_
22:44:00 <TrueBrain> glx: or maybe src/unknown/emu_252E.c
22:44:24 <glx> hmm yes that way we keep things clear
22:45:14 <glx> any converted function makes the code faster ;)
23:01:42 <TrueBrain> that is one thing that is _very_ sure :)
23:17:29 <TrueBrain> I dont like the comments, but yes, something like that :)
23:18:11 <TrueBrain> and >> 1? That is odd ..
23:18:39 <TrueBrain> should be << 1, or * 2
23:18:55 <TrueBrain> you made it a 2d array
23:19:38 <TrueBrain> still something feels odd
23:19:50 <glx> yup it makes more sense than index |= 1 and index &= 0xFFFE
23:20:28 <TrueBrain> - emu_andw(&emu_cx, 0xF);
23:20:31 <TrueBrain> - emu_andw(&emu_bx, 0xFFFE);
23:20:32 <TrueBrain> - emu_shlw(&emu_bx, 0x1);
23:20:42 <TrueBrain> so: emu_bx = ((emu_cx & 0xF) & 0xFFFE) << 1;
23:20:53 <TrueBrain> so: emu_bx = (emu_cx & 0xE) * 2
23:21:27 <TrueBrain> the 01 does the same, but + 1
23:23:30 <TrueBrain> I guess it gives a begin and end of a range
23:23:39 <TrueBrain> but .. why always an 'odd' value as index
23:23:43 <TrueBrain> (0x3 or 0x5 basicly)
23:24:15 <TrueBrain> the 1B variant is almost never used ..
23:24:31 <glx> the other has 'even' values as index
23:24:38 <TrueBrain> but what I don't get, why make 2 functions if you can do it with one
23:24:52 <TrueBrain> or why not make the index divided by 2, as that is what you do ...
23:25:13 <glx> maybe they used a 1D array
23:25:25 <TrueBrain> even then it wouldn't make sense
23:25:37 <TrueBrain> if you give 0x4 in the 0001 function, it does in fact 0x5
23:26:17 <TrueBrain> yes, but I don't get their intentions
23:26:38 <glx> and if you look at the values in the array it's funnier :)
23:29:10 <TrueBrain> some are still 0x0, I guess these are filled later in the process
23:29:14 <TrueBrain> 0xa000 is video memory
23:29:57 <glx> for a given index, you can call any of the functions and get the same result
23:30:24 <TrueBrain> I would have expected them to give a begin and end ...
23:31:17 <glx> values are set in f__25C4_000E_0019_12FF
23:32:10 <glx> just before emu_GameLoop_Main
23:33:23 <TrueBrain> hmm .. cool .. auto-copy/paste
23:33:36 <TrueBrain> either way, max value seems to be 0x9 in the code, so that would be fine, yes
23:34:21 <TrueBrain> videomemory always goes via the second
23:34:29 <TrueBrain> rest seems to be random
23:34:52 <TrueBrain> possible it is related to XMS/EMS
23:37:22 <TrueBrain> but okay, lets not waste too much time on such low-level we-will-never-use-you functions :p
23:37:27 <TrueBrain> I have no clue why they are equal
23:37:41 <TrueBrain> for sure they are memory maps of some kind
23:38:07 <TrueBrain> so the unknown stuff is just fine (given you added the &0xF :p
23:38:17 <TrueBrain> oh, and the comments
23:38:20 <TrueBrain> they are just silly :p
23:41:28 <glx> I didn't know what to write, so "C-ified" :)
23:41:54 <TrueBrain> C-ified function of f__252E_0001_0018_08B3
23:42:00 <TrueBrain> glx: or something like that :p
23:42:23 <TrueBrain> now it is just stating the obvious :p
continue to next day ⏵
