IRC logs for #opendune on OFTC at 2009-10-15
⏴ go to previous day
00:23:24 <glx> I don't understand what's wrong in cmake output
00:23:32 <glx> CMake Error at src/CMakeLists.txt:52 (INSTALL):
00:23:33 <glx> install Library TARGETS given no DESTINATION!
00:23:33 <glx> CMake Error at src/CMakeLists.txt:61 (INSTALL):
00:23:33 <glx> install Library TARGETS given no DESTINATION!
00:32:57 <proyvind> try commenting it out
00:33:18 <proyvind> that installation stuff probably isn't desired on windows anyways..
00:33:52 <proyvind> or you can try define CMAKE_INSTALL_LIBDIR to a path where you'd like to have the libraries installed..
00:50:10 <glx> CMAKE_INSTALL_LIBDIR is already defined
00:52:41 <proyvind> well, you can prolly' just skip/comment out the installation stuff..
00:52:49 <proyvind> the libraries built fine?
00:53:18 <proyvind> have you built the python bindings as well?
00:53:45 <glx> well libeastwood is not built yet as I still need to pass the configure sterp ;)
00:54:10 <proyvind> well, just comment out line 52 & 61 then :)
00:54:49 <glx> what's format for comments?
00:56:07 <glx> configuring done, generating done
01:00:04 <glx> good start, usleep not defined
01:04:56 <glx> but it should be in an header
01:06:59 <glx> I know usleep doesn't exist in MSVC but in mingw it exists
01:13:56 <glx> ok I fixed some errors, but now it's an error in the code
01:22:29 <glx> should be putU16LE(buf[i]);
01:24:27 <proyvind> hm, you get error on those lines? those are under __BYTE_ORDER == __BIG_ENDIAN..
01:24:35 <proyvind> or was it more that you just spotted it? :o)
01:25:39 <proyvind> but uhr.. you're not on big endian..?
01:25:53 <proyvind> missing define perhaps?
01:26:16 <proyvind> and missing __BYTE_ORDER is pretty much the equal of a missing __BIG_ENDIAN
01:26:58 <proyvind> #ifdef _WIN32\n #define __BYTE_ORDER __LITTLE_ENDIAN\n #endif
01:28:17 <glx> what should be the value of __LITTLE_ENDIAN ?
01:29:05 * glx searches in includes (just in case)
01:29:49 <proyvind> #ifndef __LITTLE_ENDIAN
01:29:49 <proyvind> #define __LITTLE_ENDIAN 1234
01:29:49 <proyvind> #ifndef __BYTE_ORDER
01:29:52 <proyvind> #define __BYTE_ORDER __LITTLE_ENDIAN
01:30:27 <proyvind> (<endian.h> uses 1234 as the value)
01:35:30 * glx doesn't know bzr commands
02:24:00 <glx> ok now it fails on python
02:28:55 <proyvind> but libeastwood & SDL_eastwood both built fine? :o)
02:29:19 <glx> though I needed to add a lib :)
02:29:35 <proyvind> try building the python bindings with 'python setup.py build' if running it from cmake fails
02:29:58 <proyvind> thx for the patch :)
02:30:26 <glx> Traceback (most recent call last):
02:30:26 <glx> File "setup.py", line 23, in <module>
02:30:26 <glx> from setuptools import setup, Extension
02:30:26 <glx> ImportError: No module named setuptools
02:31:14 <proyvind> you need setuptools.. :p
02:34:48 <glx> there's no windows package for py2.6
02:41:45 <glx> but it now fails to compile
02:41:58 <proyvind> my code breaks somewhere?
02:42:01 <proyvind> or setuptools breaks?
02:43:32 <glx> using msvc with gcc flags can't work
02:44:33 <glx> oh it's indeed setup.py :)
02:45:10 <proyvind> ah, the gcc flags in setup.py causes the breakage?
02:45:14 <glx> compile_args = ['-fno-strict-aliasing']
02:45:15 <glx> warnflags = ['-Wall', '-Wextra', '-pedantic', '-Weffc++', '-Wno-long-long']
02:45:15 <glx> compile_args.extend(warnflags)
02:45:15 <glx> link_args = ['-leastwood']
02:45:26 <glx> all this stuff is not valid for msvc
02:46:09 <glx> and msvc can't use libs built with gcc
02:48:02 <proyvind> hmm, and there's no chance of convincing setuptools to use gcc?
02:48:19 <glx> it's not setup tools, it's python
02:48:27 <glx> as python was built with msvc
02:48:31 <proyvind> needs to be built with same as python
02:48:44 <glx> the only way would be to build python myself
02:49:18 <glx> the other way will be to use msvc to build libeastwood
02:50:09 <glx> then the lib will be usable by python (with some changes to setup.py)
02:51:06 <glx> but for that I need to get all required libs for msvc
02:54:04 <glx> welcome to windows world :)
02:54:45 * proyvind is too scared to go to bed now :p
02:58:30 <proyvind> is there some standard function available to check what compiler python was built with?
02:58:41 * proyvind tries figuring out how to deal with in setup.py
03:08:00 <glx> anyway time to sleep for me
12:43:09 <TrueBrain> cool! We just received word from another company that our VAT number is invalid :) After doing business with them for 2 (!) years, they figured out there was a typo in the VAT number
12:48:18 <TrueBrain> whoho, I wrote eye-tracking software :)
12:48:28 <TrueBrain> well .. it tracks eyes, not where eyes are looking at .. that will be the next step :p
12:55:55 <TrueBrain> alternative input device
12:56:10 <TrueBrain> of course I immediatly take something that is over the top :p
12:56:48 <nsz> that is quite alternative
14:36:02 <glx> proyvind: it's really hard to compile libeastwood with MSVC
15:57:09 <TrueBrain> weren;t demos always 64k?
15:57:19 <TrueBrain> well .. 128b of course is better, so I am not complaining ;)
16:01:07 <TrueBrain> and Nyerguds continues on his god-like boat-ride
16:06:12 <glx> [EMU] [ INT21:3D ] Requesting mode '20' which is not completely supported.
16:06:12 <glx> [EMU] [ INT21:3D ] Requesting mode '20' which is not completely supported.
16:06:12 <glx> The setup program must be run first.
16:06:13 <glx> Zuerst muß das Setup-Programm betrieben werden.
16:06:15 <glx> Le programme de configuration doit d'abord être lancé.
16:06:17 <glx> [EMU] INT 0x21 AL 0x4C application termination
16:06:22 <glx> TrueBrain: you see it prints stuff for me
16:06:37 <TrueBrain> glx: I wonder why it doesn't for me :(
16:07:27 <TrueBrain> ah, it does print the Abnormal program termination :p
16:07:44 <glx> hmm this one is related to memory
16:11:55 <DorpsGek> SVN: truebrain (r292) [LibEMU] -Change: compile LibEMU for OpenDUNE without ncurses
16:12:31 <DorpsGek> SVN: truebrain (r293) -Change: compile LibEMU for OpenDUNE without ncurses
16:12:39 <TrueBrain> there .. no longer that annoying thing on my linux box .. :)
16:12:51 <TrueBrain> now what to eat for dinner ..
16:14:48 <TrueBrain> no ncurses for linux :p
16:15:06 <TrueBrain> means you can even see startup errors without piping stderr to a file
16:16:46 <glx> the "setup" message is on stdout btw
16:21:13 <TrueBrain> still no idea what to eat
16:27:51 <TrueBrain> so what shall I do today on OpenDUNE
16:27:55 <TrueBrain> play a bit, or figure things out?
16:29:49 <TrueBrain> so playing it is :)
16:31:31 <glx> f__01F7_05ED_0013_E7F6(), f__01F7_05F0_0010_6415() and f__01F7_064D_0028_3537() are probably some math functions, but I fail to see what function they implement
16:35:13 <TrueBrain> whoho, 560 credits for a carry-all ..
16:48:42 <TrueBrain> I can build both the Infantry Barracks and the WOR .. is that correct? :p
16:57:47 <Xaroth> er, not that I'm aware of
16:57:58 <Xaroth> and rest only had inf iirc
17:13:14 <TrueBrain> well, I have WOR too, as Ordes :)
17:15:34 <TrueBrain> whoho, Rocket Launcher before I can buy them :)
17:15:40 <TrueBrain> stupid mission .. only gives you them via Starport
17:17:36 <Xaroth> hm, dunno if ordos get wor
17:17:56 <TrueBrain> well, I have to play all missions ;)
17:22:41 <TrueBrain> cool, if you order starport stuff before it arrives, it still delivers it :)
17:24:24 <TrueBrain> oh, I got Siege tanks :)
17:24:30 <TrueBrain> I can't build them, but I do have them brought in
17:35:46 <TrueBrain> segfault .. that is bad
17:35:55 <TrueBrain> zzy return at depth 13. Expected 01F7:305C, but got 0007:3281 from 4267:1A17
17:35:58 <TrueBrain> that is terrible ..
17:37:15 <TrueBrain> stupid overlay manager :(
18:19:44 <TrueBrain> [TOC] ERROR: node error: reading outside of memory
18:19:51 <TrueBrain> when saving ending of A6 :(
18:21:31 <TrueBrain> LOL! why does the 'spice harvested by enemy' never adds up?
18:21:40 <TrueBrain> always or exactly the same as I have, or some weird value which is not likely :p
18:21:45 <TrueBrain> (has always been like that)
18:25:25 <DorpsGek> SVN: truebrain (r294) [JIT] -Add: mapped another 86 functions (campaign 6, begin of campaign 7)
18:27:43 <DorpsGek> SVN: truebrain (r295) [JIT] -Fix (r294): somehow the JIT made an error and slipped in an invalid function
18:27:54 <TrueBrain> I love my validation checks :)
18:28:07 <Xaroth> except when they are invalid :P
18:28:18 <TrueBrain> well, they detected this problem
18:28:22 <TrueBrain> so I tihnk they are very valid :)
18:28:57 <DorpsGek> SVN: truebrain (r296) -Update (r294): update decompiled code
18:29:05 <TrueBrain> when generating r296 it warned something was fishy :)
18:29:21 <TrueBrain> k .. MGV code is also programmed in now :)
18:30:54 <TrueBrain> glx: f__01F7_05ED_0013_E7F6() is some kind of 'safety' wrapper to call 05F0
18:31:31 <TrueBrain> it pops the ip, pushes the cs and pushes the ip again
18:40:46 <TrueBrain> adc... what did adc do ... I forgot :)
18:42:49 <TrueBrain> glx: it indeed is a math operation .. :p
18:45:08 <TrueBrain> and the one is the reverse of th eother, or very connected :p
18:55:19 <TrueBrain> the idea is: emu_dx = emu_dx + emu_bx / 16 + emu_cx * 4096
18:56:10 <TrueBrain> yes, it is cs:ip calculation I guess ..
18:56:20 <TrueBrain> emu_dx:emu_ax is the cs:ip pair
18:56:32 <TrueBrain> emu_cx:emu_bx is the cs:ip pair that you want to add to it, but without overflow
18:57:52 <TrueBrain> and it tries to put as much as possible in CS :)
18:57:57 <TrueBrain> > 8176:0000 + 0000:0310
18:58:11 <TrueBrain> > 44AE:0000 + 0003:9380
18:59:49 <TrueBrain> try giving such function a name ... lol :p
19:04:01 <TrueBrain> and the other indeed is 'the reverse'
19:04:12 <TrueBrain> dx:ax - cx:bx, and push as much in ip as possible
19:04:22 <TrueBrain> > 9FFF:0000 - 845A:0000
19:04:27 <TrueBrain> @calc 0x9fff - 0x845a
19:04:56 <TrueBrain> (and cs == ip / 16, so 1BA50 is the address, so 1:BA50 as CS:IP notation)
19:05:16 <TrueBrain> how do you name such functions?
19:08:56 <DorpsGek> SVN: truebrain (r297) -Add: named 3 functions (poor naming, but functions are stupid anyway)
19:08:59 <TrueBrain> there you go glx :)
19:23:12 *** Alberth has joined #openDune
19:24:29 <Alberth> Program Termination: jumped to 06F7:0219, which is not decompiled.
19:24:29 <Alberth> The jump was triggered at decompiled/cs__06F7.c:300
19:24:29 <Alberth> The jump appears to originate from 06F7:0219.
19:25:18 <Alberth> probably something with attacking a harvester
19:26:13 <Alberth> nice progress in the code we already have normal assignments
19:26:22 <TrueBrain> :) That was easy ;)
19:27:16 <Alberth> I get a number of warnings about 'decompiled/cs__B480.c:146: warning: comparison is always true due to limited range of data type' but I assume you are aware of those.
19:27:44 <TrueBrain> it is what is in the code ... a bit stupid, or a decompiler error
19:27:46 <Alberth> next step the computations as a statement?
19:29:36 <Alberth> emu_imuluw(&emu_ax, emu_dx);
19:29:36 <Alberth> emu_addw(&emu_ax, 0x3);
19:29:36 <Alberth> write the latter 2 as assignments too, or possibly even merge them into one statement?
19:29:58 <TrueBrain> the problem is that the latter 2 set flags
19:30:13 <TrueBrain> although I now do track flags, I have no backtrack yet .. so I don't know if the flags are used
19:30:36 <Alberth> 3rd one overwrites the flags of the 2nd one?
19:31:03 <TrueBrain> but that is known at 'addw', not at 'imuluw' yet ;) (for that you need back-tracking)
19:31:15 <TrueBrain> like I could also in theory just replace the emu_dx with 3 :p
19:31:23 <TrueBrain> but that requires register tracking ..
19:32:09 <Alberth> ie basic block analysis and a sort-of decompiling to 'normal' C.
19:32:32 <TrueBrain> you feel like writing it? :p :p
19:32:55 <Alberth> sure, wanna do the windows conversion? :p :p
19:33:27 <Alberth> for some reason everybody says no when I ask that. :p
19:34:02 <TrueBrain> Alberth: but yeah .. those analysis are planned, dunno if it ever happens :p
19:34:17 <Alberth> I should bring it as a more glorious improvement perhaps :)
19:35:20 <TrueBrain> I guess I should first make the decompiler in a form others can also use it :p Ghehehehe :)
19:36:28 <Alberth> I was already wondering when that would happen ;)
19:36:51 <TrueBrain> needs rewrites ... and time ... pffff :p
19:37:01 <Xaroth> but at least I can then game like a madman \o/
19:37:15 <TrueBrain> for that you need the JIT
19:37:16 <Alberth> time is always the problem
19:37:20 <TrueBrain> either way, you can still play the game
19:37:23 <TrueBrain> and report like Alberth does
19:37:26 <TrueBrain> you are just too lazy to do that :p
19:37:56 <Xaroth> I officially hate ms exchange btw
19:38:04 <Alberth> such a friendly channel here :)
19:38:19 <TrueBrain> aren't we always? :)
19:39:26 <Alberth> true, and also nicely on-topic most of the times, and less surfdude's :)
19:40:01 <Alberth> although I'd like to have an openrct :p
19:40:19 <TrueBrain> and OpenDUNE is much more fun!!! :)
19:40:49 <Xaroth> I 100% agree with TB here :P
19:40:55 <Xaroth> RCT is 'fun' .. but no lasting fun
19:43:48 <TrueBrain> Alberth: a tricky crash log
19:45:02 <Alberth> it crashed in a complicated way?
19:45:33 <TrueBrain> the problem is that the backtrace is corrupted .. so when it returns dynamic (in the JIT) it returns to places which are VERY wrong :p
19:47:58 <DorpsGek> SVN: truebrain (r298) [JIT] -Add: 1 more problem found by Alberth
19:48:24 <DorpsGek> SVN: truebrain (r299) -Update (r298): update decompiled code
20:06:04 <Alberth> hmm, unfair. After destroying the opponents harvester he gets a replacement, *and* a carry-all :(
20:06:35 <TrueBrain> well .. the carry-all just gets stucked ..can happen to you too ;)
20:06:48 <TrueBrain> when it is flying while someone requires a carry-all, it will never leave again :)
20:07:09 <TrueBrain> so build a refinery, and have a harvaster returning just when the other one is delivered ;)
20:13:53 <Alberth> hmm, must try that one time
20:14:44 <Alberth> ok, enemy almost destroyed. time to harvest 2700 spice :)
20:22:22 <proyvind> glx: oh, hard to compile with msvc? :/
20:22:48 <glx> I just gave up many tries
20:24:44 <glx> I needed to change some includes, edit cmake stuff, and it still doesn't compile
20:30:47 <glx> as IStream and OStream are used by IOStream
20:32:48 <glx> proyvind: though some changes are valid :)
20:33:06 <glx> but most are just plain hacks
20:41:10 <proyvind> glx: missing tr1/* with msvc?
20:41:19 <proyvind> shared_ptr isn't available otherwise..
20:42:02 <glx> tr1 stuff is available, just in different headers :)
20:42:05 <proyvind> msvc have it in <memory>?
20:42:40 <glx> and it's recent (came in VS2008 SP1)
20:43:18 <glx> btw VS still doesn't support C99 :)
20:52:58 <proyvind> so what are the remaining problems you're having?
20:54:07 <glx> IStream and OStream mainly
20:54:57 <glx> std::istream and std::ostream don't have default constructor
20:55:45 <TrueBrain> glx: the decompiler had a hard time running that file ...
20:55:49 <TrueBrain> something goes terrible wrong
20:55:59 <TrueBrain> Unrecognized graphic mode!
20:57:20 <glx> so 0x98E1 (config data) is related to graphic mode
20:57:22 <TrueBrain> it jumps to 217e:0000, which is not code (but data)
20:57:49 <TrueBrain> but the JIT does it every time ..
20:58:01 <proyvind> glx: ie. IStream() {} trying to call the default constructor then?
20:58:02 <TrueBrain> k, DOSBox crashes too :p
20:58:19 <glx> proyvind: yes but that fails to compile
21:00:46 <glx> trying 2 config changes at the same time is maybe not a good idea
21:00:55 <TrueBrain> the game should never crash like this :p
21:01:00 <TrueBrain> I need to check where it goes wrong ..
21:01:52 <TrueBrain> it looks like the overlay manager which fucks up somehow
21:01:59 <glx> the changes are for cs__B480.c:229 and cs__B480.c:237
21:03:14 <proyvind> + IStream() : std::istream(NULL){}
21:03:18 <proyvind> + OStream() : std::ostream(NULL){};
21:03:24 <TrueBrain> I think ds:86 is corrupted at that point
21:04:14 <TrueBrain> ah, no, it is later .. glx: search for a push of 05DB in cs__217E.c
21:04:31 <TrueBrain> next is a case, which jumps to 04CB only .. but somehow with your cfg it jumps to 0
21:04:34 <TrueBrain> which is invalid :p
21:04:46 <TrueBrain> good chance the 'es' is invalid :p
21:06:48 <DorpsGek> SVN: truebrain (r300) [JIT] -Add: mapped another 4 functions (dune.cfg failures)
21:07:00 <DorpsGek> SVN: truebrain (r301) -Update (r300): update decompiled code
21:07:38 <glx> well they are not dune.cfg failure, just different settings
21:07:38 <TrueBrain> but because of the mentioned problems above, the JIT never reaches there :)
21:07:52 <TrueBrain> sigh ... next time give me the commit message BEFORE I commit :p Ghehe :)
21:08:21 <glx> and one of the changes is probably an invalid value ;)
21:08:47 <TrueBrain> either way .. I have no clue why the static code runs longer than the dynamic code :p Somehow the static code corrects for something ... ;)
21:12:06 <DorpsGek> SVN: truebrain (r302) [JIT] -Add: mapped another function (dune.cfg something)
21:12:32 <DorpsGek> SVN: truebrain (r303) -Update (r302): update decompiled code
21:12:41 <TrueBrain> ghehe :) Found a nice way to bypass the dynamic problem :)
21:12:49 <TrueBrain> the static version now exits cleanly :) NO IDEA why :)
21:12:57 <TrueBrain> DOSBox crashes, JIT crashes, static works .. go figure :p
21:16:03 <glx> yup the code looks better, it prints string_0181 then call emu_Terminate_Normal
21:18:24 <glx> proyvind: yup better, but still fails somewhere else
21:19:23 <proyvind> where does it fail now?
21:20:28 <glx> in EmcFileAssemble.cpp, snprintf undeclared
21:20:59 <glx> oh I know how to solve this one
21:23:14 <glx> ha better, now it fails to link (but I know how to solve that too)
21:27:36 <glx> well I know I must add something in cmake, but I need to find how :)
continue to next day ⏵