IRC logs for #opendune on OFTC at 2010-02-12
⏴ go to previous day
00:06:09 <DorpsGek> SVN: glx (r885) [JIT] -Add: mapped another 25 functions (unresolved calls/jumps in f__AB00_1CEE_0015_5BCF())
00:07:12 <DorpsGek> SVN: glx (r886) -Update (r885): update decompiled code
09:24:06 *** TrueBrain has joined #openDune
09:24:22 <Xaroth|Work> another thing pro-erlang for you, tb :P
09:24:37 <Xaroth|Work> and I happened to get there through some django site
09:24:55 <TrueBrain> fucking machine had gone offline :(
09:25:04 <TrueBrain> like it was never one
09:26:20 <TrueBrain> and I think Nyer finally got the point .. he is still bitching about it, and not really respecting it, but at least he got it
09:26:30 <Xaroth|Work> haven't even read his reply yet
09:27:55 <TrueBrain> when did my client drop?
09:28:04 <Xaroth|Work> 06:39 [TrueBrain [~patric@145.118.72.132] quits (Ping timeout: 480 seconds
09:29:05 <TrueBrain> worst part always is that you lost all your PM logs :p
09:30:47 <Xaroth|Work> check /tmp/truebrain.log for our log at least
09:36:53 <Xaroth|Work> nothing in syslog regarding the crash? :o
09:37:31 *** Xaroth|Work sets mode: +o TrueBrain
13:08:48 <TrueBrain> glx: be advices: Dune2 seems to access sound files differently through the pak loader. Be careful :)
13:09:23 <TrueBrain> (As in: if you finally got some sound, but it is garbage, revert my PAK work, and somehow fix XMS/EMS, en see if that helps ;))
13:09:44 <Xaroth|Work> and somehow fix XMS/EMS << heh at that bit
13:09:52 <glx> well I know there's a pointer to sound data in Driver struct
13:10:10 <TrueBrain> glx: it seems, if I get the information MrFlibble feeds me is right, that it completely ignores the file listing
13:10:20 <TrueBrain> and just assumes voices start at a certain location
13:10:38 <glx> voices need XME/EMS anyway ;)
13:10:51 <TrueBrain> but changing the PAK seems to cause sound corruption
13:10:59 <TrueBrain> so just be aware of such possible errors/problems :)
13:11:10 <glx> so for now it's magically disabled even if we enable it
13:11:28 <glx> (and not because config.c ;) )
13:11:44 <TrueBrain> if you want me to trace it down, let me know :) For now I try to stay away from sound, so we don't work on the same thing ;)
13:12:14 <glx> I'm C-ifiying MPU_Interrupt
13:13:33 <glx> ,...if (emu_get_memory16(0x44AF, 0x00, 0x1316) != 0) return;
13:13:33 <glx> ,...emu_get_memory16(0x44AF, 0x00, 0x1316)++;
13:14:17 <glx> and many interrupt can trigger while it runs it
13:14:27 <TrueBrain> static bool locked = false; if (locked) return; locked = true; (..) locked = false;
13:36:04 <glx> ,...emu_subw(&emu_ax, 0x64);
13:36:04 <glx> ,...if ((emu_flags.sf != emu_flags.of)) goto l__1D94;
13:36:36 <glx> sf is easy to know, but of is a pain
13:37:39 <glx> hmm sub is like cmp indeed, just the result is "returned"
13:38:26 <Xaroth|Work> if ((emu_ax -= 0x64) something something
13:40:09 <Xaroth|Work> like 'something something' is actual C :P
13:40:24 <TrueBrain> #define something ;
13:40:57 <TrueBrain> printf("%d\n", SIX * NINE);
13:41:02 <glx> hmm ok it's if ((int16)emu_ax < 0) ...
13:42:14 <TrueBrain> Douglas Adams for the win
13:44:40 <glx> oh it's a for loop indeed
13:47:39 <Xaroth|Work> db_table = "fetcher_cache"
14:18:03 <glx> ,...emu_subw(&emu_get_memory16(emu_ds, emu_bx + emu_si, 0x188), 0x1);
14:18:04 <glx> ,...emu_sbbw(&emu_get_memory16(emu_ds, emu_bx + emu_si, 0x1C8), 0x0);
14:18:16 <glx> 32bit sub on non real 32bit value ?
14:18:51 <TrueBrain> that indeed is very weird
14:19:24 <TrueBrain> can also be a very cheap way to substract another var
14:19:44 <TrueBrain> a -= (b - 1) ? 0 : 1
14:20:13 <glx> I keep the emu_s* for now
15:06:59 <glx> arrrrrg, all this jumps are nasty
16:02:34 <DorpsGek> SVN: truebrain (r887) -Documentation: document a @return value
16:03:25 <TrueBrain> weird .. a function that first checks if 2 units are enemies
16:03:31 <TrueBrain> then checks if the two units are the same
16:03:37 <TrueBrain> but .. they can't be enemies AND the same
16:25:28 <TrueBrain> whoho, traced a specific bit for MrFlibble :)
16:25:30 <TrueBrain> even managed to name it ;)
16:34:38 <TrueBrain> let me C-ify the function now first .. as I know what it does anyway :p
18:01:56 <glx> hmm I have some kind of infinite loop (it at least looks like it)
18:12:35 <glx> (forgot a line, and "=" in a test is wrong
18:18:45 <TrueBrain> runniing toc gives a big patch :p
18:19:55 <TrueBrain> updating 'txt' can be useful :)
18:20:47 <glx> hmm with my patch I trigger an unresolved jump
18:21:18 <glx> too easy to make a mistake
18:21:55 <TrueBrain> maybe something to get your attention of it?
18:23:50 <TrueBrain> reload, this time it compiles :p
18:26:29 <TrueBrain> okay ... proof-reading yours is near to impossible
18:27:09 <glx> and some parts are used in different places
18:29:58 <TrueBrain> okay ... my function finds a value which indicates how important a target is
18:31:29 <TrueBrain> also by normal units
18:31:34 <TrueBrain> if an enemy approaches
18:31:42 <TrueBrain> the moment they start to shoot at it :p
18:31:46 <TrueBrain> but how to call such a function?
18:32:07 <TrueBrain> planetmaker: you are good at this :p
18:33:56 <TrueBrain> or how do you write that word
18:34:15 <TrueBrain> GetTargetTreatLevel?
18:39:12 <TrueBrain> nah, I like treat-level :)
18:39:57 <planetmaker> Unit_GetTargetImportance or Priority or Value are all good :-)
18:40:36 <planetmaker> because the higher the points the higher priority you assign on its destruction
18:41:11 <planetmaker> The value is ambigeous. Monetary? Tactical? Strategical? For you? For enemy?
18:41:26 <planetmaker> Treat... must be a Dutch-ism :-P
18:41:37 <TrueBrain> how do you write it?
18:42:06 <planetmaker> what do you judge by that function? I guess the order in which you want to attack targets, right?
18:42:18 <planetmaker> then priority is fine.
18:42:22 <TrueBrain> the highest value gets attacked
18:42:28 <planetmaker> the biggest threat not necessarily has highest priority
18:42:59 <TrueBrain> fun remark about this function: if YOUR unit is outside the map, it will attack a target, if the TARGET unit is outside the map, you won't attack it :p
18:43:26 <glx> how can you be outside the map ?
18:43:42 <TrueBrain> and the other flying thing
18:43:56 <planetmaker> vice versa would make more sense
18:44:26 <planetmaker> if your target is outside the map: still attack. If you're outside of the map, you cannot do a thing as you're comfortable in the carry-all's chair
18:45:54 <TrueBrain> glx: any comments on the patch? Or shall I just commit :p
18:46:15 <glx> my mind is not able to read any patch ;)
18:47:32 <TrueBrain> what is very strange to me, is that even things outside your shooting range can get priority
18:47:46 <TrueBrain> that might explain why turrents point towards an enemy before it is in its range
18:47:50 <planetmaker> TrueBrain: that makes even sense
18:48:24 <planetmaker> yeah. Like those cases etc. You may choose to ignore a nasty foot solder and treat the big tank just out of range first
18:48:27 <glx> pointing takes time, so the sooner the better
18:49:45 <TrueBrain> if (distance != 0) priority = (priority / distance) + 1;
18:49:53 <TrueBrain> I would have expected a exponential thingy here
18:50:01 <TrueBrain> priority * 100 / distance / distance
18:50:07 <TrueBrain> would have made more sense in my opinion :p
18:51:21 <planetmaker> that's not exponential ;-)
18:52:00 <planetmaker> besides I would not necessarily have a too strong decay. I guess that's something which needs rather play testing than theoretical discussion ;-)
18:52:35 <planetmaker> Could way later even be made an option: AI uses target priorisation formula a....f
18:57:52 <TrueBrain> okay, now first I am going to try to make all those bitflags a bit more sane, as this is annoying
18:58:01 <TrueBrain> 2 choices: either name the bits and use & with them
18:58:04 <TrueBrain> or make them bitfields
18:58:20 <TrueBrain> so: unit->flags.hasPriority
18:58:28 <TrueBrain> or unit->flags & UNIT_FLAGS_HAS_PRIORITY
18:59:53 <DorpsGek> SVN: truebrain (r888) -Add: C-ified Unit_GetTargetPriority()
19:23:20 <DorpsGek> TrueBrain: 1111111011111111
19:28:47 <TrueBrain> something like this?
19:28:50 <TrueBrain> glx: does MSVC like it?
19:32:12 <TrueBrain> planetmaker: do you have input on the naming (see unit.h)
19:32:20 <TrueBrain> I wonder if we should make it: isUsed, or used
19:32:23 <TrueBrain> byScenario or scenario
19:47:43 <TrueBrain> was afraid of that :)
19:47:56 <planetmaker> hm... I guess it's a matter of convention whether to use IsProperty or Property for a var name ;-)
19:48:42 <planetmaker> Might be better to go without the "is"
19:48:52 <TrueBrain> glx: if you change the uint32s to uint16s?
19:48:54 <planetmaker> then you can introduce boolean functions
19:49:21 <TrueBrain> tons of wrappers ...
19:50:25 <planetmaker> also it would then - for consistency's sake - have to be IsInTransport and alike
19:57:42 <TrueBrain> glx: but uint16 a:1 is not C89 :p
19:57:46 <TrueBrain> planetmaker: hmm ...
19:57:56 <TrueBrain> but 'transport' and 'scenario' is not the most clear name
19:59:16 <TrueBrain> glx: so I think I will make a #define which is uint32 in MSVC, and uint16 in GCC :p
20:00:10 <planetmaker> TrueBrain: My arguement was to leave those names :-) But to use "used" and "Allocated" instead of "IsUsed" and "IsAllocated"
20:01:45 <planetmaker> That gives you the option to define n helper functions: IsUsed(unitID) IsAllocated(unitID) IsInTransport(unitID) etc
20:04:16 <TrueBrain> glx: but you like the layout like this?
20:08:07 <glx> it's easier to read now :)
20:09:27 <TrueBrain> now to fix it for all compilers ......
20:10:12 <TrueBrain> warning: type of bit-field 'unknown_8000' is a GCC extension
20:10:16 <TrueBrain> if only I could mute that warning ..
20:13:10 <TrueBrain> glx: how does this work?
20:14:20 <TrueBrain> src/driver.c:49: warning: pointer targets in passing argument 1 of 'strcasecmp' differ in signedness
20:14:55 <DorpsGek> SVN: truebrain (r889) -Fix: mute GCC warning
20:19:51 <TrueBrain> (does it also run? :p)
20:32:59 <glx> mingw compiled without warning
20:35:45 <TrueBrain> then now I will convert all of them before committing
21:15:59 <DorpsGek> TrueBrain: 1001111111111111
21:18:03 *** Xaroth has joined #openDune
21:18:03 *** ChanServ sets mode: +o Xaroth
21:18:28 <Xaroth> finally intarwebs again
21:25:28 <glx> strange I have running difference even at the begining of the function
21:26:16 <TrueBrain> (h->flags & (0x0002 | 0x0008)) == 0x0008 <- strange, I have some weird line
21:26:25 <TrueBrain> owh, yes, I understand
21:26:31 <TrueBrain> glx: that is weird ... check and check again?
21:30:02 <glx> it's really the begining of the function
21:32:18 <TrueBrain> yup, most likely timing
21:32:22 <TrueBrain> as I can't see any obvious error
21:32:28 <TrueBrain> walk line by line from begin of function?
21:33:08 <glx> but as it's an interrupt function, a timing issue is the most probable thing
21:41:10 <TrueBrain> that should be most of them
21:41:20 <TrueBrain> now I need to double check my own work :p Ghehe :)
21:44:18 <TrueBrain> yes, it seems to be all correct
21:44:33 <TrueBrain> so, one last time, glx, can you test it in MSVC? :)
21:46:43 <TrueBrain> makes lot of things much more readable ;)
22:10:22 <DorpsGek> SVN: truebrain (r890) -Codechange: make the bitfields in bit-structs, so we can name each bit, and make the code much more readable
22:10:42 <TrueBrain> still map.h to do, but that is secondary :p
22:13:14 <TrueBrain> yeah ... this is nice :)
22:50:51 <TrueBrain> good idea / bad idea?
22:51:54 <planetmaker> looks like a readability enhancement
22:52:42 <TrueBrain> makes sense, right?
22:53:26 <TrueBrain> 344 if (tile->flags == 0 && (g_map[i] & 0x8000) == 0 && g_map[i] == tile->spriteID) continue;
22:53:27 <TrueBrain> 344 if (!tile->isUnveiled && !tile->hasStructure && !tile->hasUnit && !tile->flag_08 && !tile->flag_10 && (g_map[i] & 0x8000) == 0 && g_map[i] == tile->spriteID) continue;
22:53:42 <TrueBrain> this is the ugly part .. but because it is already a bit-struct, I can't make another bit-struct (of size 5) inside it .. so I have no general access :(
22:55:16 <TrueBrain> tiles are always visible
22:55:25 <TrueBrain> just not always unveiled
22:55:58 <TrueBrain> FoW would aos be a name, but ...
22:56:02 <TrueBrain> that might be confusing for some ;)
22:56:14 <planetmaker> nah, unveiled is fine then
22:57:07 <TrueBrain> glx: what do you think? Better?
22:57:15 <TrueBrain> or do you have better suggestions? (please say yes :))
22:57:24 <TrueBrain> (I am not all too happy with this solution :p)
23:10:54 <glx> if it's ugly only there it should be ok
23:11:32 <TrueBrain> I dont expect other places
23:12:12 <glx> an ugly lines is a little cost for an increase readability
23:20:24 <DorpsGek> SVN: truebrain (r891) -Codechange: make the Tile flags also in bitfields for easy access
continue to next day ⏵