IRC logs for #opendune on OFTC at 2009-10-21
⏴ go to previous day
00:49:55 <proyvind> what was the equation
00:50:12 <proyvind> like the exact one used in DUNE2.EXE :)
02:41:14 <DorpsGek> SVN: glx (r386) -Fix (r385): obiwan for comments alignment
05:31:24 <proyvind> segra's OD2 was interesting
05:31:31 <proyvind> (at least for my part ;)
06:50:14 *** boekabart has joined #openDune
06:50:39 <boekabart> stupid Q: libemu (for msvc) ... where to get it?
07:10:49 <boekabart> cool, win32 debug mode works (but doesn't seem to accept key input? demo keeps running) 50% cpu (1core full), speed seems about OK.
07:10:59 <boekabart> release mode crashes:
07:11:16 <boekabart> Program Termination: jumped to 01F7:1B11, which is not decompiled. The jump was triggered at ..\decompiled\cs__01F7.c:4476 The jump appears to originate from 01F7:1B3A. Please send the file 'memory/crash.bin' to upstream developers.
07:11:29 <boekabart> .. the file doesn't exist (start.bin does)
07:11:49 <nsz> heh crash.bin should exist
07:12:12 <nsz> anyway not every function is decompiled yet
07:12:33 <boekabart> ok, but why does debug mode work then?
07:12:34 <nsz> also 50% cpu is because old games run in busy loop
07:12:54 <boekabart> ah, that explains..
07:13:01 <nsz> debug mode crashes as well
07:13:13 <nsz> there is random numbers involved
07:13:29 <nsz> that function is probably called every 100th run
07:14:00 <nsz> so if you retry release it will crash elsewhere
07:14:46 <boekabart> yes, jumping to the same fn, though
07:15:07 <boekabart> 10ht time it doesn't crash, but lock up
07:15:52 <nsz> are you using svn version?
07:16:43 <boekabart> but, regarding the input ?
07:17:00 <Xaroth> boekabart: for msvc compile jit as debug, and link that to a release compile of opendune
07:17:22 <Xaroth> I made a build myself for some testers, if you want to take the cheap way :P
07:20:51 <Xaroth> TrueBrain: That post of segra explains a lot why he's not responded to any of our topics..
07:23:51 <boekabart> Debug build of libemu is OK wil release build of od
07:24:48 <boekabart> my first guess would be : uninitialised memory. debug inits memory to certain debug values, making the behaviour consistent (if not wrong); release doesn't -> random numbers
07:24:55 <boekabart> but i suppose you did check that...
07:25:08 <Xaroth> I'm still learning C/C++
07:25:21 <Xaroth> I come from a blissful land of C#, where 80% is done for you :P
07:46:23 <boekabart> it's not what I first guessed, it seems: release without optimizations works like a charm
07:46:41 <boekabart> still doesn't react to key presses though
07:47:27 <boekabart> immediately in intro?
07:49:12 <Xaroth> that's the 'forced intro'
07:49:12 <boekabart> you're not at work?
07:49:27 <Xaroth> make a file called 'onetime.dat' (empty) in /data
07:52:19 <boekabart> it's already multiplied by 2 right
08:00:22 <boekabart> works better on my screen.. but shouldn't SDL be able to do that more efficiently than TrueBrain himself? :P
08:04:03 <boekabart> hehe site gives a bad instruction:
08:04:07 <boekabart> "On MSVC please compile a release build. " :)
08:52:56 <TrueBrain> boekabart: update the instructions :) I don't have MSVC you know ;)
08:53:42 <TrueBrain> Xaroth: Segra really should have come forward with his project MUCH sooner
08:54:16 <proyvind> TrueBrain: you feel silly now? ;p
08:54:28 <TrueBrain> nope, not the slightest in fact
08:54:44 <TrueBrain> but it is just a waste .. if he would have come forward with his progress much sooner, things might have been different
08:54:52 <TrueBrain> the penalty you pay for keeping things hidden from the public :)
08:55:03 * proyvind did everything in the open from the start ;)
08:55:24 <proyvind> I was positively surprised that anyone else actually made use of my library :o)
08:55:25 <TrueBrain> to be honest, im not sure if im even going to do anymore work on this or not. kinda over it now so i just put that repository up for anyone who wants the code/history of it
08:55:28 <TrueBrain> That is what you get :p
08:55:32 <TrueBrain> always nice, yes ;)
08:55:58 <proyvind> but using an awfully crappy version of the library though..
08:56:50 <proyvind> making use of much of my stuff
08:56:58 <proyvind> makes it easier for me to pick up on his again :o)
08:57:27 <proyvind> although my approach is totally different..
08:59:25 * proyvind plans on writing a python binding class or fetching data structures from dune2.exe, then fetch the settings from there and use with my already existing python classes :o)
09:01:57 <proyvind> anyone played warzone 2100 before?
09:02:46 <proyvind> it was originally a commercial game
09:02:54 <proyvind> from a company that went belly up before releasing the game
09:03:09 <proyvind> so most of the game was released as free software
09:03:36 <proyvind> what's really cool about it is that you can frequently compose your own units from new components you develop
09:04:16 <proyvind> I'd like to make my unit & structure objects that modularized
09:06:32 <proyvind> at least you have the posibility to put together a few new tanks with the different turrets, tanks etc. in dune 2 already :o)
09:07:55 <proyvind> looks like a drunken elephant tipping over or something ;p
09:11:10 <TrueBrain> yeah, I really find it sad segra comes out with this code at this late stage in his development ...
09:11:19 <TrueBrain> oh well, things in the past don't take return
09:12:13 <TrueBrain> proyvind: and when OpenDUNE grows a bit, we should talk to you to make your library C :p Ghehe :)
09:12:41 <proyvind> TrueBrain: I can make it C-compatible..?
09:13:07 <TrueBrain> and there is the problem of license .. well .. I guess first OpenDUNE has to mature a bit :)
09:13:21 <proyvind> gpl 2.1 vs 3.0 you mean?
09:13:59 <proyvind> I'm okay with you using it under 2 :)
09:14:10 <TrueBrain> and you REALLY should relicense to LGPL :)
09:14:25 <proyvind> don't hold the necessary copyrights.. :/
09:14:26 <TrueBrain> GPL for a library makes the library useless, as it demands the application using the library has to be GPL too :p
09:20:12 <TrueBrain> okay ... now I am going to win with O8 first
09:22:54 <proyvind> TrueBrain: none of the library componenents even started out as with any library in mind ;pp
09:24:06 <TrueBrain> he never reached his destination, because he is STUPID
09:28:38 <TrueBrain> very hard to win from 2 sonic tanks :s
09:30:06 <boekabart> what's this Segra thing you're talking about
09:30:28 <TrueBrain> at a dune 2fan forum
09:31:36 <boekabart> <!--[if IE lte 6]> <![endif] - >
09:33:25 <TrueBrain> StarPort gives me no new units, and I am running low :(
09:35:47 <TrueBrain> my carry-alls no longer do their job correctly
09:35:49 <TrueBrain> takes them FOR EVER
09:38:41 <Xaroth> < TrueBrain> Xaroth: Segra really should have come forward with his project MUCH sooner << yep...
09:42:52 <TrueBrain> stupid starport ... I NEED UNITS!
09:45:21 <boekabart> found... TrueBrain , Sand Flea :)
09:45:29 <boekabart> that's all you are!
09:48:05 <TrueBrain> and then this stupid worm comes to eat my units tooo .........
09:48:34 <boekabart> don't complain. If you don't like it, it's open source so change the code
09:48:35 <Xaroth> I think you're one of few, who actually lost an entire army to sand worms...
09:48:49 <TrueBrain> it really happen too often
09:49:13 <Xaroth> they only eat 2 or 3 units per worm anyhow :P
09:49:21 <TrueBrain> and always those I can't mis
09:50:19 <boekabart> TrueBrain: why the 'manual' 2x scaling, can't SDL do this?
09:50:42 <TrueBrain> I have no idea, so this was the easiest way out
09:50:46 <boekabart> ah no, now I remember, SDL can only do blitting... stupid me, wrote my own scaler for SDLs...
09:51:29 <TrueBrain> LibEMU is just a temporary library
09:51:32 <TrueBrain> it won't survive :)
09:51:44 <boekabart> that's what they all say :) no, I get it
09:51:59 <TrueBrain> it is needed for the DOS emulation :)
09:52:38 <boekabart> libemu and your uncompiler basically could handle any dos exe, right?
09:52:50 <TrueBrain> 16bit real mode, yes
09:53:28 <boekabart> so, it's almost trivial to 'recompile' any dos app to run win32 SDL ...
09:53:46 <boekabart> (win32 being unstable)
09:54:00 <boekabart> Debug mode, crashes all the time
09:54:00 <TrueBrain> the general idea is to make plain C out of it
09:54:05 <TrueBrain> that is MSVC to blame
09:54:28 <boekabart> too much optimization?
09:54:42 <TrueBrain> but I don't know .. it fucks up
09:54:48 <boekabart> since, release -/- optimizations runs, with optimizations it doesn't
09:54:52 <boekabart> (for libEmu that is)
09:55:03 <TrueBrain> but I don't care that much about MSVC :)
09:55:09 <TrueBrain> it is known to be stupid ;)
09:55:23 <Xaroth> Compiling LibEMU as debug build makes it run better than when building Release.
09:55:34 <Xaroth> so I use debug libemu + release opendune
09:55:46 <TrueBrain> we had to make the code C89 before MSVC could compile it as C (and not C++)
09:56:03 <TrueBrain> so lets not use MSVC as standard for anything :)
09:56:49 <TrueBrain> either way, boekabart, compiler there, my tool decompiles any 16bit real DOS application to C, which can be compiled on any platform natively (if they have a compiler compiling C89)
09:57:25 <boekabart> this tool is available?
09:57:36 <TrueBrain> yup, although I need to push the latest version ...
09:57:42 <boekabart> the errors like 'Program Termination: jumped to 22A6:1063, which is not decompiled. The jump was triggered at d:\sandbox\odune\trunk\decompiled\cs__22a6.c:2382 The jump appears to originate from 22A6:1075.' aren't msvc related, right?
09:57:50 <TrueBrain> it is a bit modified to work with Dune2 btw, so it might give problems on other binaries
09:58:03 <TrueBrain> nope, those errors happen, and will happen for a while :) Send over the crash.bin if you want it to be fixed ;)
09:59:56 <TrueBrain> you do need to understand that my decompiler is a 'live' decompiler, it needs to run the application
10:00:09 <TrueBrain> therefor it needs TCC (the compiler) and a JIT, which means linux only for now :)
10:00:09 <boekabart> there's a bug in the win32 version of that emu_call()
10:00:21 <boekabart> it calls pic_suspend() twice, and the second one obviously fails
10:00:52 <TrueBrain> of 'that emu_call()'
10:00:55 <TrueBrain> not really helpful?
10:01:22 <boekabart> void emu_call2(char *filename, int lineno) calls pic_suspend()
10:01:29 <boekabart> first line, 'line 45
10:01:53 <boekabart> bios_unit(7) calls pic_uninit() which calls pic_suspend again
10:02:08 <boekabart> so effectivly, DeleteTimerQueueTimer(NULL, _timer_handle, NULL); is called twice
10:02:32 <boekabart> either it needs a _timer_handle=NULL and an IF there, or it shouldn't be called twice
10:02:41 <TrueBrain> you are absolutely right
10:02:54 <boekabart> apparently setitimer doesn't have this problem
10:03:07 <TrueBrain> setitimer doens't use a pointer
10:03:28 <DorpsGek> SVN: truebrain (r387) [LibEMU] -Fix: don't delete an undefined timer (because pic_suspend() can be called twice in a row) (tnx to boekabart)
10:03:47 <boekabart> we'll see tonight when I can svn up :)
10:04:11 <TrueBrain> - DeleteTimerQueueTimer(NULL, _timer_handle, NULL);
10:04:13 <TrueBrain> + if (_timer_handle != NULL) DeleteTimerQueueTimer(NULL, _timer_handle, NULL);
10:04:14 <TrueBrain> + _timer_handle = NULL;
10:05:57 <TrueBrain> Windows doesn't know any timer that works synchronized .. very annoying :(
10:11:44 <TrueBrain> THAT STUPID SABATEUR WALKED IN A WALL!
10:12:44 <Xaroth> saboteurs aint the smartest of units
10:12:48 <Xaroth> walls are perfect against them :P
10:12:55 <TrueBrain> and that then is your palace attack ...
10:12:57 <TrueBrain> freemen are more usful
10:13:22 <TrueBrain> it can't even blow up a palace :(
10:13:33 <Xaroth> it can, if used properly :P
10:13:39 <TrueBrain> not when on full health
10:13:39 <Xaroth> and it's not that easy to use them properly
10:13:42 <TrueBrain> that is what I meant :)
10:13:48 <Xaroth> then use two saboteurs ;)
10:15:05 <TrueBrain> next weekend I might finish all 9s
10:15:53 <TrueBrain> weird ... H9 and A9 start with 1000 credits .. O9 with 1500
10:16:03 <Xaroth> because ordos are gimped :P
10:16:19 <TrueBrain> 134 new functions .. not bad :)
10:16:55 <DorpsGek> SVN: truebrain (r388) [JIT] -Add: mapped another 134 functions (campaign 8, begin of campaign 9)
10:17:55 <DorpsGek> SVN: truebrain (r389) -Update (r388): update decompiled code
10:18:02 <TrueBrain> there we go, campaign 8 unlocked
11:18:36 *** boekabart has joined #openDune
11:29:11 <boekabart> any hints on mingw?
11:30:35 <TrueBrain> I don't use windows, so I can't help you with any of that :)
11:35:35 <boekabart> url is indeed very very VERY cool
11:45:14 <boekabart> TrueBrain: $ make 2>&1 |grep error src/libtoc/decompiler.cpp:112: error: `uint' was not declared in this scope src/libtoc/decompiler.cpp:112: error: expected `;' before "tLength" src/libtoc/decompiler.cpp:113: error: expected `;' before "lastLength" src/libtoc/decompiler.cpp:119: error: `tLength' was not declared in this scope src/libtoc/decompiler.cpp:119: error: `lastLength' was not declared in this scope
11:45:46 <boekabart> $ gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
11:53:07 <TrueBrain> boekabart: you can't compile toc with windows, you need linux
11:53:14 <TrueBrain> so I never ported it to windows :)
11:53:28 <TrueBrain> I guess you need to add a 'typedef unsigned int uint' to fix that ;)
11:53:43 <TrueBrain> well, I guess the decompiler can work .. it is the JIT that won't (and therefor it is useless :p)
11:53:56 <boekabart> but i'm using gcc ...
11:54:14 <TrueBrain> it is not that :) It is the lack of Windows to do certain library things :)
11:54:25 <TrueBrain> and the fact TCC is not ported to Windows :)
11:55:20 <TrueBrain> but I guess for the decompiler itself you need neither .. so I guess I can cleanup stuff a bit so you can at least make decompiled code from the JIT data of OpenDUNE :)
11:56:58 <TrueBrain> so yeah, you should be able to typedef uint, and at least compile 'toc' and 'libtoc' .. although no glue is there for Windows, so they won't be able to find eachother :)
11:57:56 <boekabart> so you suggest that IF i want to decompile another exe, i should do that in a linux vm?
11:58:13 <TrueBrain> I not only suggest that, I tell you it is the only way with my tool :)
11:58:17 <boekabart> then, the code should compile and run fine-ish on msvc ?
11:58:20 <TrueBrain> or you can just give me the exe, and I can see what I can do for you ;)
11:58:37 <boekabart> .com also supported?
11:58:53 <TrueBrain> the decompiler produces code which can be compiled cleanly with any C89 compiler (like for OpenDUNE)
11:58:57 <TrueBrain> .COM support is also there, yes
11:59:03 <TrueBrain> although COMs are a bit more tricky
11:59:19 <boekabart> truebrain@openttd.org, I suppose?
11:59:26 <TrueBrain> or opendune.org, both are fine
12:00:01 <TrueBrain> k, every tile is 4 bytes long
12:00:05 <TrueBrain> it appears bit-packed
12:00:39 <TrueBrain> at least the 3rd byte is
12:01:46 <TrueBrain> hmm .. layout seems to be: 9 bits, ??, 8bits (of the total of 32bits)
12:05:38 <TrueBrain> 9 bits, 7 bits, ???, 8 bits
12:06:21 <TrueBrain> the 7 bits seems to refer to building-id ..
12:06:36 <boekabart> TrueBrain: smth that needs BasRun.exe won't work, right?
12:06:47 <TrueBrain> boekabart: what do you mean
12:06:52 <TrueBrain> Xaroth: file? No, tile :)
12:07:11 <Xaroth> yes, but what is it related to?
12:15:20 <boekabart> TrueBrain: I have an Exe, that needs BasRun.exe in order to run
12:15:29 <boekabart> probably was written in basic :)
12:17:35 <TrueBrain> ah; if it uses EXEC (an opcode) it won't work
12:17:41 <TrueBrain> if it manually loads the file, it will
12:18:21 <boekabart> what's the entry point in an exe again?
12:18:48 <TrueBrain> defined in the header
12:40:28 <TrueBrain> Xaroth: tiles .. you know .. tiles of the map? :)
12:40:42 <TrueBrain> I am trying to figure out what all bits and bytes do :)
12:41:54 <TrueBrain> ah, no, the last byte refers to the building-id if there is a building .. which happens when on the 3rd byte bit 6 is NOT set .. which is a bit odd :)
12:45:41 <TrueBrain> hehe, digger is part of my test-set :)
12:45:46 <TrueBrain> sadly enough it uses a weird video-mode
12:46:20 <TrueBrain> FP misses data-files it seems
12:47:01 <TrueBrain> and xonix doesn't want to start in DOSBox ...
12:48:01 <TrueBrain> digger uses INT13:02, which I never implemented
12:48:26 <boekabart> you need fp data files to decompile?
12:48:54 <TrueBrain> k, let me explain a bit :) There are 2 types of decompiling (well, there are more, but lets go with 2)
12:49:04 <TrueBrain> 1) you do a static analyses of the code, and base decompiled code on that
12:49:05 <boekabart> I've run xonix in dosbox.. and digger runs only if you put dosbox in true CGA mode
12:49:22 <TrueBrain> 2) you run the code and while running, you record which information comes along
12:49:59 <TrueBrain> 1) is often not possible, as most executables in the old days do self-modifying (for good reasons)
12:50:10 <TrueBrain> nowedays code-segments are protected, and this is no longer possible .. back then it was possible :)
12:50:22 <TrueBrain> also, many executables contain code preventing decompiling in a static way
12:50:29 <TrueBrain> well, memory was limited, so you have to be creative
12:50:45 <TrueBrain> overlays, every level in a file which is loaded on level entry, ...
12:50:59 <TrueBrain> also, UPX, a method to pack your executable, extract at runtime/startup, and run it
12:51:10 <TrueBrain> so my decompiler works via method 2)
12:51:20 <TrueBrain> it starts the application, and maps it while running
12:51:30 <TrueBrain> that is why I have to play Dune2, to map levels :)
12:52:20 <TrueBrain> haha, I know this game :)
12:52:22 <boekabart> re digger: read disk sector is not essential for digger, just for highscore R/W
12:52:27 <boekabart> of course you know it
12:52:57 <TrueBrain> I can't selectively skip things :p It needs some kind of implementation :)
12:53:07 <boekabart> AH = status (see ~INT 13,STATUS~) AL = number of sectors read CF = 0 if successful = 1 if error
12:53:14 <boekabart> so, just return error and 0 read
12:53:38 <boekabart> OR implement virtual floppy support :D
12:53:56 <TrueBrain> FirePower fails on INT21:0C
12:54:17 <TrueBrain> as you can understand it took a while before Dune2 worked ;)
12:54:29 <TrueBrain> the emulator layer is FAR from finished :)
12:54:43 <boekabart> but FP is statically doable?
12:54:54 <TrueBrain> it accepted the initial part, so I guess
12:55:03 <TrueBrain> as long as it doesn't try to do any 32bit memory access, it will be fine
12:55:14 <boekabart> HAHA quite sure it won't
12:55:24 <TrueBrain> 386 already had opcodes for it
12:55:26 <TrueBrain> so don't be too sure
12:55:53 <boekabart> "It was released in 1987"
12:56:05 <TrueBrain> you will be fine, yes :)
12:56:52 <TrueBrain> bah, my normal source for itnerrupt stuff is taken offline :(
12:57:18 <glx> I remember myself using self modifying code for storing scores in TI-85 Z80 asm
12:57:58 <boekabart> ok so - how do I add those missing int's to decomp? (to libemu is quite obvious from what i've seen)
13:02:34 <TrueBrain> k, FP runs with a bit of hacking
13:02:37 <TrueBrain> but misses int10:10:02
13:02:45 <TrueBrain> int10 is one of the most impossible things to implement
13:03:01 <TrueBrain> the reason I am oh-so-happy Dune2 uses 256color mode :)
13:03:15 <TrueBrain> so, not so much I can do there for you at this stage ..
13:03:29 <TrueBrain> in theory it should and will work, but someone would need to implement int10 ...
13:03:58 <TrueBrain> you have all the sources
13:04:19 <TrueBrain> install libtcc (is in any sane distro)
13:04:25 <TrueBrain> tcc-dev sometimes .. or just tcc
13:04:34 <TrueBrain> then 'toc' will compile cleanly
13:04:53 <TrueBrain> then the process is simple .. I will give you a few files, and a few simple scripts, and off you go ;)
13:04:58 <TrueBrain> tcc is a compiler, but very small and simple
13:05:06 <TrueBrain> also, it has a libtcc.a, which allows compiling on-the-fly
13:05:09 <Xaroth> o_O there's TCC for windows :o
13:05:11 <TrueBrain> (what a JIT needs to do .. a lot :p)
13:05:20 <boekabart> is that the cc - command missing I get?
13:05:36 <TrueBrain> tcc is linked to .. it will fail to include tcc.h
13:06:12 <TrueBrain> in the end you run something like: ./toc working fp.exe && cd working && LD_LIBRARY_PATH=".." LD_PRELOAD="libjit.so" ./main 2>run.log
13:06:30 <TrueBrain> which exists very soon, you look at run.log, you find out what is missing/wrong, you fix it in libemu, you run again :)
13:06:35 <TrueBrain> and again and again, till it works :p
13:06:41 <TrueBrain> then you have tons of files in working/txt/*/
13:06:46 <TrueBrain> then: ./toc --static working
13:06:52 <TrueBrain> now you have plain C files in working/decompiled ;)
13:07:08 <TrueBrain> then cd working && make && ./main, and it runs! :)
13:07:14 <TrueBrain> oh, I forgot a 'make' in the above process :p
13:07:45 <TrueBrain> libjit, libtoc and toc are 'dirty' applications .. no cleanup, little checks for missing files/wrong dirs/missing dirs .. the tool is not 'meant' for public (yet)
13:07:52 <TrueBrain> I should clean it up .. I don't feel like it :)
13:08:01 <TrueBrain> maybe something for my thesis project :p
13:08:04 <boekabart> i totally understand
13:08:26 <TrueBrain> so any libemu contributions are very welcome .. and any questions/problems too :)
13:08:50 <TrueBrain> don't expect me to program a lot on libemu for firepower, as I really want to concentrate on OpenDUNE (and I can't handle yet another project :p), but I am more then willing to help you on your way :)
13:10:24 <boekabart> glx: I DID THE SAME THING!!
13:10:24 <TrueBrain> glx: that is only good for OpenDUNE, yes :)
13:10:31 <TrueBrain> for other projects it is very annoying ;)
13:10:41 <TrueBrain> but yes, we can apply that to the /extra/libemu version :) Please do ;)
13:11:40 <boekabart> the makefile (toc) has some ifdef WIN32 stuff
13:11:42 <DorpsGek> SVN: glx (r390) [LibEMU] -Fix: don't show 2 cursors when only 1 is needed (ie disable SDL cursor)
13:11:58 <Xaroth> lol glx i was wondering about that
13:11:59 <boekabart> what 'make' is that meant for?
13:12:04 <TrueBrain> boekabart: I once tried it a bit :)
13:12:13 <TrueBrain> but never finished it
13:13:25 <TrueBrain> as I said, the decompiler itself should in theory work .. the stat-collector (the JIT) will never :)
13:13:36 <TrueBrain> k, I got to go :) Will be back later tonight :)
13:13:49 <glx> JIT uses linux "hack" I guess
13:14:09 <TrueBrain> the latter is avoidable .. the first not so much :)
13:14:16 <TrueBrain> and TCC only works nicely on Linux32bit (not even 64bit)
13:14:20 <TrueBrain> that is the only real limitation :)
13:15:26 <glx> oh I should have changed caption while at it :)
15:29:32 *** ChanServ sets mode: +v Xaroth
15:29:32 *** ChanServ sets mode: +v DorpsGek
15:38:22 <DorpsGek> SVN: glx (r391) -Add: figured out a few variables
15:51:20 <DorpsGek> SVN: glx (r392) -Fix (r391): precise some DuneCfg members
15:54:24 *** Xaroth sets mode: +o TrueBrain
15:57:22 <proyvind> so.. would you guys have actual interest in using my library if I made some C interfaces for it?
15:58:24 <proyvind> (and for your consideration of lua, given any consideration to python as an alternative perhaps? :o)
15:58:39 * proyvind tries figuring out how to better be of benefit to eachother :)
16:00:01 <Xaroth> We already benefit eachother
16:00:08 <Xaroth> We have info, you have info :)
16:00:42 <proyvind> hehe, yeah, sure, but beyond that ;)
16:00:52 <Xaroth> and lua isn't decided yet, that won't be decided until we actually work on it
16:01:26 <proyvind> if you were to go with python, that could certainly bring some nice benefits to both of us :)
16:01:37 *** Xaroth changes topic to "Teaser-2 released || Websites *.opendune.org: www, forum, bugs, wiki, svn || T-11d"
16:01:49 <Xaroth> it all depends on what it can give us, vs what it will cost us :)
16:02:20 <proyvind> yeah, it's a bit heavier perhaps, which might be something more to consider for an ehm.. c project ;)
16:02:48 * proyvind with c++ and using boost already, python comes nearly free in that regard :o)
16:03:01 <glx> proyvind: python and windows ;)
16:03:29 <proyvind> beyond that and myself using it for my engine, my library also comes with python bindings which might make it more useful for game stuff as well :o)
16:03:58 <proyvind> glx: oh, yeah, msvc.. :p
21:07:33 *** Yexo is now known as Guest48
21:10:33 <DorpsGek> SVN: glx (r393) -Fix (r391): some copy/paste errors in the comments
21:19:05 <Xaroth> proyvind: we also have to consider ease of use wrt mod authors
21:19:21 <Xaroth> python can be a bit of a bitch from time to time :P
21:22:28 <proyvind> I'd say that python is more preferable for such than lua
21:23:17 <proyvind> lua is less common, less intuitive and less nice IMO :p
21:24:21 <TrueBrain> proyvind: we want to use LUA for the scripting of units and stuff; this can't be done by Python, as it has a too big of env
21:24:39 <TrueBrain> for LUA you define very specific what is used (which is very little), there is no IO, there is no (random Python thingy)
21:24:44 <TrueBrain> and it is about 3 to 4 times as fast :p
21:25:01 <TrueBrain> Python on the other hand has a massive memory overhead (per VM, we need to start lots of them :p), you can't restrict IO access, etc etc :)
21:25:06 <TrueBrain> so Python is not the man for the job :)
21:25:15 <TrueBrain> (despite the fact I like Python much more than I like LUA :p)
21:27:15 <TrueBrain> for the rest, I would love to use your library as much as possible, but I also really want to keep OpenDUNE C89 .. so maybe we can introduce C89 snippets in your library (or split it in two, and license the library properly :p :p)
21:29:09 <Xaroth> Stickting to what we decide is good :)
21:31:21 <Xaroth> I find it interesting that neither nyer nor fibble posted on segra's topic
21:35:11 <TrueBrain> I am still a bit sad under it ..
21:35:20 <proyvind> TrueBrain: I was thinking about perhaps creating C "interface library" (or whatever to call it) in similar fashion as I've done with SDL
21:35:42 <TrueBrain> if it still requires C++ code to be compiled at some point, it aint C89 :p Ghehe :)
21:35:50 <proyvind> just wrapping c++ as c
21:35:55 <proyvind> you're that die hard?
21:36:05 <TrueBrain> it is just nice to make OpenDUNE as portable as possible
21:36:11 <Xaroth> TrueBrain: you happen to know what causes the error "the system cannot execute the specified program" when trying to run od?
21:36:15 <TrueBrain> as it is such an old game, that is possible :)
21:36:36 <TrueBrain> Xaroth: I need more info (OS, what you try to do exactly, ..)
21:36:56 <Xaroth> and trying to do, run it :P
21:37:05 <Xaroth> or well, it's a mate of mine trying to run it
21:37:14 <Xaroth> i think he's just being dumbass, but we'll find that out this weekend
21:37:35 <TrueBrain> proyvind: either way, I have much interest in integrating such things, but time will tell in what way :)
21:38:12 <TrueBrain> proyvind: at least, I assume you won't be against having a piece of C code in your library with C++ wrappers? :p
21:38:32 <glx> I found 3 functions related to drivers, but they are incomplete ;)
21:42:30 <glx> btw I tried pcspeaker "sound card" with dosbox, it's ugly :)
21:45:11 <proyvind> I didn't have a sound card back then
21:45:32 <proyvind> so playing the intro with pc speaker is really nostalgic :o)
21:45:44 <proyvind> especially the scene with the ornithopter :o)
21:48:01 <TrueBrain> I was going to figure out what are stored in tiles .. but I got lost in some other project :p
21:48:53 <TrueBrain> proyvind: yeah .. just my way of getting to know the code :)
21:50:32 <proyvind> what tiles are you refering to? ICN/MAP?
21:50:43 <TrueBrain> neither; tiles as stored in memory
21:51:14 <TrueBrain> I know it is 32bits, the last 8 are for 'building id' .. the first field is a 9 bit field .. the second a 7 bit .. the next 8 appear flags, each bit something else
21:51:49 <TrueBrain> so I am scanning all places tha tuse the map, which gives me a nice insight in its usage and stuff :)
21:53:08 <glx> I use a similar way to understand what is in 353F ;)
21:53:33 <glx> random search for an offset
22:01:04 <TrueBrain> bit 0x20 and 0x10 seem connected
22:01:11 <TrueBrain> glx: how far are you with the strings?
22:01:50 <glx> .,.../* 42EB() */ PACK uint8 unknown_42EB[0x1D67]; /*!< list of all files. */ <-- I don't want to detail that
22:02:07 <TrueBrain> maybe I can write something simple for that :)
22:02:11 <TrueBrain> there are 14 music drivers?
22:02:28 <glx> yes, but probably not all used
22:02:49 <glx> as there are only 4 choices in setup
22:03:21 <glx> and some choices give the same result in dune.cfg
22:03:51 <TrueBrain> btw, really 1D67 bytes of filenames?
22:04:11 <glx> yes, all .pak and their content
22:04:48 <TrueBrain> I read on fed2k something about it .. I believe it is used
22:04:56 <TrueBrain> as you can't just pack a file in some .pak, it won't find it
22:05:03 <TrueBrain> it really looks at certain points
22:05:14 <TrueBrain> of course that will all change when we are done with it, but for now, it won't :)
22:05:41 <glx> I search for 0x42EB and found nothing, but maybe it's an indirect usage
22:05:44 <TrueBrain> still need to find a nice and elegant way to keep the 'old' ways of doing, and find a way to allow extension :) I don't want TTDp shit, and I don't want OpenTTD shit :p
22:20:55 <TrueBrain> I love it to randomly alter the game :p
22:23:34 <TrueBrain> whoho, no concrete :)
22:23:54 <TrueBrain> B4B8 is critical to correct displaying the map :)
22:24:16 <TrueBrain> in fact, I suspect f__B4B8_0000_001F_3BC3 of being the GenerateMap function :)
22:25:14 <TrueBrain> k, first 2 bytes for sure control the type of tile :)
22:25:18 <TrueBrain> (no real suprise I guess)
22:26:11 <TrueBrain> at 353F:3A50 there is some info array .. maybe about tiles? I dunno ..
22:27:15 <TrueBrain> means there is room for like 10 objects, given the spce avaiable .. the code suggests something completely different ..
22:29:03 <TrueBrain> k, found where tiles are initialized .. always useful :)
22:29:23 * TrueBrain makes some changes other would wonder about :p
22:30:38 <TrueBrain> whoho, black/red chess board tiles :)
22:31:41 <TrueBrain> k, first 9 bits is the spriteID .. no real suprise I guess :)
22:31:54 <TrueBrain> other 7 are related to Fog of War :)
22:46:41 <TrueBrain> at 2E9C: some auxilary data is kept for 'special' fields I guess
22:53:16 <TrueBrain> but there are also the pak-file listings
22:54:18 <TrueBrain> ah, wait, 2E9C:323F
22:54:31 <TrueBrain> which is even more weird, but at least puts it back in logic memory :p
22:56:22 <TrueBrain> k, I now have to stop looking at random places reading random things, and just start somewhere with making it more C like .. if only by adding tons of comments :p
22:59:01 <TrueBrain> but first: good night :)
continue to next day ⏵