IRC logs for #opendune on OFTC at 2011-04-09
            
02:44:07 *** glx has quit IRC
07:25:47 *** Alberth has joined #openDune
08:16:44 <Alberth> http://forum.opendune.org/viewtopic.php?f=11&t=134 <-- a 0.3 player with a problem :)
09:55:28 <Alberth> http://devs.openttd.org/~alberth/diffs/emu_Unknown_259E_00B1.patch
10:48:41 <Alberth> http://devs.openttd.org/~alberth/diffs/tools_free_wrapper_remove.patch
12:02:21 <TrueBrain> ugh, wish I didn't had to battle matlab :(
12:06:19 <Alberth> are you winning?
12:06:24 <TrueBrain> not really :p
12:08:43 <Alberth> I programmed java/eclipse/EMF a whole week, only to discover friday evening while walking home that the problem is much simpler than I thought
12:10:50 <TrueBrain> ghehe :D
12:10:53 <TrueBrain> that always sucks ...
12:11:33 <TrueBrain> I now have the issue that all my algorithms find a worse solution then shourtest tour, in a TSP problem :p
12:13:27 <TrueBrain> then agian, I am running this on a machine ... they won't like it if they find out I do :)
12:13:30 <TrueBrain> but I have nothing else atm :p
12:13:45 <Alberth> hmm, is matlab of any use for programming such a problem?
12:14:04 <TrueBrain> to program it rapidly and see graphical feedback, yes
12:14:11 <TrueBrain> is for a class about natural algorithms
12:14:35 <Alberth> for a sysop you seem to lack useful machines, lately :)
12:14:47 <TrueBrain> yeah .....
12:16:03 <Alberth> isn't it a property of natural algorithms that they don't always find the really shortest path?
12:16:28 <TrueBrain> but they should give better results then a simple nearest neighbour algorithm :D
12:16:35 <TrueBrain> owh, sorry, I mistyped :p
12:16:40 <TrueBrain> shourtest = nearest neighbour
12:22:07 <Alberth> true :)
12:22:34 *** glx has joined #openDune
12:22:34 *** ChanServ sets mode: +o glx
12:24:07 <glx> hello
12:24:30 <Alberth> hello
12:26:22 <Alberth> awaiting review :)
12:26:22 <Alberth> (11:58:23) Alberth: http://devs.openttd.org/~alberth/diffs/emu_Unknown_259E_00B1.patch
12:26:22 <Alberth> (12:51:35) Alberth: http://devs.openttd.org/~alberth/diffs/tools_free_wrapper_remove.patch
12:26:22 <Alberth> no hurries, I am currently enjoying f__B4DA_0000_002C_B3C2() (some security function)
12:28:13 <glx> tools_free_wrapper_remove seems wrong,
12:28:44 <glx> mainly wrong emu_cs when calling emu_Tools_Free
12:30:32 <Alberth> it should just be a rename of the function, so we can leave it alone until the end?
12:30:40 <Alberth> or perhaps not even touch it at all
12:32:54 <glx> they are in different segment, so a rename may not be enough
12:34:49 <Alberth> I was thinking something like emu_Tools_Free_Wrapper_B520() as new name, so it is clear it is just a wrapper
12:35:04 <Alberth> but maybe that is TMWFTLB
12:35:14 <glx> ha yes you can name it emu_Tools_Free_Wrapper()
12:36:05 <glx> if you name it add it to function_names.txt
12:39:02 <TrueBrain> or also replace the things like: emu_push(emu_cs); emu_push(0x0231); emu_cs = 0x23E1; emu_Tools_Free();
12:39:09 <TrueBrain> so that:
12:39:11 <TrueBrain> emu_push(emu_cs); emu_push(0x0BD4); emu_cs = 0x3520; overlay(0x3520, 0); f__B520_0223_000E_38A3();
12:39:12 <TrueBrain> becomes
12:39:22 <TrueBrain> emu_push(emu_cs); emu_push(0x0BD4); emu_cs = 0x23E1; emu_Tools_Free();
12:39:37 <TrueBrain> but yeah ... maybe just naming is enough :)
12:51:45 <Alberth> ha, computers are so much better at creating variables :D http://www.fpaste.org/gr4o/
12:55:03 <TrueBrain> lol
13:06:34 <Alberth> http://devs.openttd.org/~alberth/diffs/rename_tools_free_wrapper.patch
13:16:54 <TrueBrain> seems one algorithm now does what it should do ...
13:16:55 <TrueBrain> 2 more to go ...
13:16:57 <TrueBrain> meh
14:11:11 <glx> +B520:0223:000E:38A3 emu_Tools_Free_Wrapper # (csip) Forwards the call to emu_Tools_Free() <-- I'd say "stupid wrapper" ;)
14:13:51 <Alberth> that's a quality judgement :p
14:18:28 <Alberth> emu_get_memory8(0x2C6C, emu_di * 8, 0x0); emu_get_memory16(0x2DCE, i * 4, 0x47A); <-- any knowledge what these base addresses are?
14:19:17 <Alberth> 0x2C6C is an array of an array of 8 bytes
14:22:43 <glx> 0x2DCE is g_sprites IIRC
14:23:18 <glx> g_sprites = (csip32 *)&emu_get_memory8(0x2DCE, 0x0, 0x440);
14:23:39 <Alberth> that could be
14:23:59 <glx> @calc 0x47A -0x440
14:23:59 <DorpsGek> glx: An error has occurred and has been logged. Please contact this bot's administrator for more information.
14:24:35 <Alberth> 58, x3a
14:24:49 <glx> so g_sprites[14 + i]
14:26:53 <glx> hmm 14*4 != 58
14:26:57 <glx> weird
14:27:15 <Alberth> it's a cs
15:21:46 <Alberth> http://devs.openttd.org/~alberth/diffs/f__B4DA_000.patch http://devs.openttd.org/~alberth/diffs/f__B4DA_000_-w.patch
15:21:46 <Alberth> same patch, second one ignores white space changes so it may be easier to follow
15:21:46 <Alberth> 2 questions: emu_al = g_houseInfo[unknown].index; /* XXX index is a 16bit value! */ <-- looks wrong due to size, but I see no other translation
15:21:46 <Alberth> there is a subroutine call using data from a fixed address. Can I remove everything but the one call?
15:21:46 <Alberth> Despite the still large number of emu_* calls, I don't really see many more possibilities otherwise, except the finishing touches: a rename, a move to a different file, and a short test.
15:21:47 <Alberth> but first time for dinner, and some other stuff I need to do.
16:20:53 <glx> + emu_ip = emu_get_memory16(0x353F, 0x00, 0x6630); /* XXX 0x04a5 */
16:20:53 <glx> emu_push(emu_cs);
16:20:53 <glx> - emu_cs = emu_get_memory16(emu_es, 0x00, 0x6632);
16:20:53 <glx> + emu_cs = emu_get_memory16(0x353F, 0x00, 0x6632); /* XXX 0x20af */
16:20:53 <glx> it's g_global->variable_6630 and it's always 0x22A604A5
17:51:36 <Alberth> http://devs.openttd.org/~alberth/diffs/f__B4DA_000.patch in case someone is bored :)
17:52:45 <Alberth> fixed the houseinfo puzzle, I had the wrong structure. removed the switch.
18:49:57 <Alberth> http://paste.openttdcoop.org/show/154/ One $Id$ is enough in mouse.c :)
19:12:56 <Alberth> hmm, voices block the whole game :(
19:13:46 <Alberth> 'sound effects' may be a better word
19:23:07 <glx> voices use a lot of cpu yes
19:23:20 <glx> it's because emulator layer
19:24:28 <Alberth> hmm, my harvester is '100% full and awaiting pickup', but it is A2, ie no carry-alls
19:24:51 <Alberth> http://devs.openttd.org/~alberth/diffs/f__2B6C_0137.patch a mouse function
19:47:45 <glx> ha do 22A6:0FAE and 22A6:0FD7 are mouse callbacks
19:47:52 <glx> s/do/so/
19:49:00 <glx> they move write only stuff
19:59:28 <Alberth> like mouse cursors ?
19:59:59 <Alberth> or mouse speed perhaps
20:00:37 <glx> one copies 22A6:0026-22A6:002C to 22A6:0031-22A6:0037
20:01:08 <glx> the other does the reverse
20:01:25 <Alberth> how interesting ;)
20:01:41 <glx> and set 31-37 to 0,40,0,200
20:02:37 <Alberth> could be a mouse box, except for the second 0
20:03:14 <glx> anyway these variables are never read outside these 2 functions
20:04:49 <Alberth> probably because we all use the same mouse interface
20:11:32 <glx> hmm maybe you wrote that somewhere, what is base for B536 ?
20:13:40 <Alberth> cs__b536: 5727
20:41:32 * glx will do some 1DD7
20:41:54 <Alberth> ha ha: Ram Free Error! Press any key to exit to DOS. :)
20:42:12 <glx> I got it some times
20:42:29 <glx> but usually means error in conversion somewhere :)
20:42:44 <Alberth> just after the 'good job done' talk
20:44:20 <Alberth> that would be emu_Unknown_259E_00B1.patch
20:46:49 <Alberth> or the tool-rename patch, but that is less likely :)
20:47:02 <Alberth> good night
20:48:25 *** Alberth has left #openDune
23:54:46 <DorpsGek> SVN: glx (r1469) -Add: C-ified Driver_Voice_0248()