IRC logs for #opendune on OFTC at 2011-05-21
            
00:45:39 <DorpsGek> SVN: glx (r1574) -Add: C-ified GUI_FactoryWindow_CreateWidgets() and GUI_FactoryWindow_LoadGraymapTbl()
00:58:31 <DorpsGek> SVN: glx (r1575) -Change: renamed some variables
02:10:25 *** glx has quit IRC
07:16:58 *** Alberth has joined #openDune
12:13:56 *** glx has joined #openDune
12:13:56 *** ChanServ sets mode: +o glx
12:14:25 <glx> hello
13:17:13 <Alberth> wow, compiler is getting smart :) uint8 keyFlags; keyFlags = value & 0xFF00; <-- warning: overflow in implicit constant conversion [-Woverflow]
13:23:11 <glx> missing >> 8 ?
13:31:28 <DorpsGek> SVN: glx (r1576) -Add: C-ified GUI_FactoryWindow_InitVar8BEA()
13:32:11 <Alberth> no, the high byte are flags, which I had as (value >> 8), but since all returns then had to do (keyFlags << 8), I decided to drop the shift, but forgot to change the variable type (even though I thought about that just 15 seconds earlier)
13:54:58 <glx> nice, each time the starport window is open, a new random seed is used
13:58:53 <DorpsGek> SVN: glx (r1577) -Add: C-ified GUI_FactoryWindow_CalculateStarportPrice()
14:08:23 <Alberth> it cannot be random enough :p
14:13:28 <Alberth> glx: http://www.fpaste.org/OCjk/ <-- looks like a crash in GUI_DrawSprite(), revision r1575
14:13:52 <Alberth> when clicking on the select what to build in the construction yard button
14:14:25 <Alberth> only problem is that I was running a converted keyboard input handler, so that may also be a cause
14:14:40 <glx> quite possible
14:15:17 <glx> hmm crash here too
14:15:21 <glx> but seems different
14:21:06 <Alberth> factory window has glitches here http://devs.openttd.org/~alberth/glitchy_factory_gui.png (head, running in debugger)
14:21:21 <glx> seen them yes
14:21:35 <glx> in first missions
14:22:00 <Alberth> yes
14:22:14 <Alberth> atreides gives those glitches, ordos crashes
14:24:08 <Alberth> harkonnen just closes the SDL screen, and then pauses indefinitely
14:24:42 <glx> I have segfault in pic_get_sec()
14:25:22 <Alberth> #0 0x000000000047e8f2 in GUI_DrawSprite (memory=<optimized out>, sprite_csip=<optimized out>, posX=Cannot access memory at address 0x7fff2c20f45c
14:25:46 <Alberth> at src/gui/gui.c:1339
14:25:58 <Alberth> segmentation fault indeed
14:25:59 <glx> the problem is before that :)
14:26:31 <Alberth> if only I could get a longer backtrace :)
14:27:15 <glx> r1573 is broken too
14:27:46 <Alberth> in the debugger, ordos survives :(
14:28:13 <glx> ok r1572 works
14:28:48 <glx> so bug in r1573
14:31:59 <Alberth> always the long function :p
14:32:57 <glx> loc12 = (struct_8BEA *)&emu_get_memory8(emu_dx, emu_ax, 0x0);
14:32:57 <glx> somehow emu_get_memory8(0, 0, 0) doesn't do what I expected :)
14:37:30 <Alberth> GUI_FactoryWindow_Init() line 2813 does g_global->factoryWindowWidgets.s.cs = emu_dx; but it does not save ax/dx, like around 969
14:39:06 <glx> hmm ?
14:39:31 <glx> g_global->factoryWindowWidgets.s.cs = emu_dx;
14:39:31 <glx> g_global->factoryWindowWidgets.s.ip = emu_ax;
14:39:35 <Alberth> never mind
14:39:36 <glx> that's 2813
14:39:57 <glx> the problem was just garbage when it should be NULL
14:40:22 <Alberth> I was wondering about the push/pull at 969, then saw that 2813 doesn't do such things
14:41:29 <glx> looks like useless leftover
14:41:42 <Alberth> yeah, I came to that conclusion too
14:46:40 <DorpsGek> SVN: glx (r1578) -Fix (r1573): NULL pointer was not NULL when it should
14:47:30 <glx> crash fixed :)
14:58:23 <Alberth> quick service :)
14:59:15 <glx> all my tests where done in more advanced saves (with more than 4 buyable items)
15:07:19 <Alberth> I constantly make new clones to work in, and copy the data files from an unplayed set of files.
15:07:32 <Alberth> it gets better code testing :)
15:07:50 <Alberth> (ie you and me doing different things for testing)
15:08:54 <Alberth> hmm, no manual with keys that should work
15:13:40 <glx> http://nyerguds.arsaneus-design.com/dune/Dune%20II%20-%20English.pdf
15:16:18 <Alberth> a real manual :p
15:19:37 <Alberth> I need to do some more testing it seems
15:20:00 <glx> well some keys supposed to work don't
16:57:47 <Alberth> ok, some keys don't work in both versions :)
17:00:45 <Alberth> patch added to #73
17:53:36 <Alberth> 29e8:062a 2d13a: 9a 0d 00 83 23 call 0x2383:0xd <-- bummer, a non-expanded call :(
19:38:06 <Alberth> Hmm, didn't ANSI C use 'void' to denote no arguments? ie shouldn't we use void f__29E8_074D_0066_6E9B(VOID) ?
19:38:32 <Alberth> (uppercase to attract more attention)
19:46:06 <SmatZ> that's certainly more secure
19:47:00 <SmatZ> "int bar(); int foo(int a) { return bar(a); }" is valid code
19:47:15 <SmatZ> and gcc won't warn about it, I think
20:10:34 <TrueBrain> Alberth: should / would / could ;)
20:10:44 <TrueBrain> yes, it is better C; dunno why it didn't happen :p
20:10:53 <TrueBrain> think it was because at first I needed g++ to compile it :D
20:11:20 <Alberth> aka hystery :)
20:11:35 <TrueBrain> and a clear case of: don't care :)
20:12:06 <Alberth> it becomes C++ anyway, eventually :)
20:12:17 <TrueBrain> haha; please no
20:12:42 <Alberth> you're a true C person?
20:13:01 <TrueBrain> lets say I was against C++ till months after OpenTTD became C++ :p
20:13:16 <TrueBrain> the commits from kudr just proved my point why :)
20:13:32 <TrueBrain> happy it is much better these days, but C++ is just asking for unreadable code that 'just works' :p
20:14:21 <Alberth> yes, you need more carefully think what parts of C++ not to use :)
20:15:03 <TrueBrain> think most of misc/ in OpenTTD is still .... not readable :p
20:15:52 <Alberth> I just created Input_GetHistory.patch in #73(?) not sure how useful such code is
20:15:52 <TrueBrain> but I guess it is just the lack of my ability to figure out what overloads what and where :p
20:16:12 * Alberth looks in misc to see what it contains
20:16:22 <TrueBrain> kudr once commits his 'own C++ libs' there
20:16:32 <TrueBrain> in a time I was away for a while .. else I would have raged :p
20:17:21 <Alberth> yeah templates is one of the more powerful features :)
20:17:32 <Alberth> but then again #define in C can be worse :)
20:17:42 <TrueBrain> yup
20:18:05 <TrueBrain> regarding Input, again: naming is more important than converting
20:18:11 <TrueBrain> it will be replaced by SDL? anyway :p
20:18:42 <Alberth> this is playback from history, actually
20:19:00 <TrueBrain> please collect them all in that one thread
20:19:05 <TrueBrain> then we can commit them at once, or not ;)
20:20:40 <Alberth> for me, the trouble is that I can only do naming after doing 70-80 percent of the conversion work :)
20:21:18 <TrueBrain> you know everything in that segment is Input ;) :D
20:21:36 <Alberth> the input looks like it comes from a different place, it uses emu_ax as input parameter
20:21:46 <TrueBrain> its a lib
20:21:58 <TrueBrain> (as far as I know)
20:22:05 <TrueBrain> at least a different compiler it appears
20:22:14 <TrueBrain> rarely pushing cs, but always ip
20:22:20 <TrueBrain> different ways of communication
20:23:08 * Alberth wondered whether they could be static functions originally
20:24:54 <Alberth> most likely I will try to find a different spot tomorrow, I don't like this are very much
20:25:24 <TrueBrain> I am going to test my INI conversion
20:25:26 <TrueBrain> see if they work
20:26:25 <Alberth> my strtok patch broke your code probably :p
20:26:41 <Alberth> I think you can remove the emu function when you are done
20:28:08 <TrueBrain> first leason of developing: don't update while developing :D
20:31:00 <Alberth> not too often at least ;)
20:31:08 <Alberth> good night
20:31:20 <TrueBrain> sleep well
20:31:29 <Alberth> and good luck with your INI experiment :)
20:31:34 <TrueBrain> tnx
20:31:43 *** Alberth has left #openDune
20:31:47 <TrueBrain> seems I need emu_ wrappers, bah :(
20:45:02 <TrueBrain> oeh, almost flawless ... strings are only terminated too soon it seems
20:47:47 <TrueBrain> error in emu_, lol
20:53:10 <TrueBrain> minor bugs ... will fix later :D
22:21:17 <Xaroth|Work> :o
22:21:52 <SmatZ> :x
22:21:56 <Xaroth|Work> :s
22:24:17 <SmatZ> :p
22:24:53 <Xaroth|Work> :b