IRC logs for #opendune on OFTC at 2010-04-25
⏴ go to previous day
14:31:47 *** ChanServ sets mode: +v Yexo
16:24:10 *** proyvind has joined #openDune
16:26:14 <proyvind> hm, you guys haven't properly "c-ified" code related to unit animations yet, have you?
16:30:15 <proyvind> I'm kinda "c++-ifying" segra's code, finished with anims for structures, but unsure about a couple of details, and have unit animations left, then I should've mostly migrated his code related to reading stuff from dune2.exe to my libeastwood :o)
16:31:10 <proyvind> trying to pick up some hints and stay consistent where I can with you guys as much as I can
16:31:33 * proyvind is very happy with your progress :)
16:36:41 <proyvind> ah, seems like you've got quite a bit nicer overview identifying the emc scripts as well :)
17:04:10 <glx> well most script functions are still unnamed
17:08:01 <proyvind> "nicer" is a more relative term than "nice" ;p
17:19:28 <proyvind> btw. for locations of various structures (ie. GlobalData, UnitInfo etc.), shouldn't there be some better way of locating them from some pointers in the binary, rather than hardcoding cs:ip? (trying to navigate my way through dune2.exe and trying to make things as relative(/version neutral) for the various versions myself..)
17:29:49 <TrueBrain> they are hardcoded in the start.bin anyway
17:29:53 <TrueBrain> so wouldn't differ much :)
17:30:06 <TrueBrain> dune2.exe is only loaded for the overlays
17:32:18 <TrueBrain> bit of a drawback of this method
17:32:23 <proyvind> mind my ignorance, but what kind of a file is start.bin? some sort of dos emu environment?
17:32:39 <TrueBrain> it is a memory dump of just before dune2.exe is executed
17:32:52 <TrueBrain> when you start an app in DOS, the app is loaded in the memory, and various of registers are set
17:32:57 <TrueBrain> glx: dosbox was never used for them :p
17:33:16 <TrueBrain> start.bin is from just after DOS finishes preparing the app, and is ready to jump to the first instruction
17:33:23 <TrueBrain> a result of the decompiler used :)
17:33:49 <TrueBrain> a step we would have to take is to read all that static data from dune2.exe from the right position :)
17:39:21 <proyvind> hm, wouldn't you been able to get most of the required information for doing that just by parsing the dos mz header of dune2,exe? (I have to admit that I *really* lack the insight on a lot of these things, but that's pretty much what I do for much of the same purpose..(?))
17:39:26 <TrueBrain> glx: btw, OpenDUNE should go in freeze mode today :)
17:39:58 <TrueBrain> proyvind: getting the information is relative trivial, but it has to be done, as Dune2 (unmodified) doesn't :p
17:40:16 <TrueBrain> and currently has little prio :)
17:43:06 <proyvind> probably of bigger interest to me just for learning and understanding, getting things relative for the sake of multiple versions is more motivated by educational purposes and quasi-perfectionism ;)
17:43:50 <proyvind> and in a general interest of making stuff as generic as possible :o)
17:44:18 <TrueBrain> currently it simply isn't possible for us :)
17:45:06 <glx> well it seems code starts at 4C00 (= 01F7:0000)
17:45:45 <TrueBrain> glx: forced by decompiler, yes
17:45:48 <proyvind> we have very different takes on the project also
17:46:19 <glx> (CS + 2C9) seems to be right to get the offset in dune2.exe
17:46:43 <TrueBrain> things are rather primitive :)
17:46:44 <glx> of course all jumps in asm need a + 01F7 ;)
17:47:04 <TrueBrain> the main problem with other versions is that the code is slightly different
17:47:11 <TrueBrain> so we should only load the static arrays
17:47:17 <TrueBrain> and even then, it wouldn't 'just work'
17:47:28 <proyvind> _codeSegment = _header.headerSize << 4
17:48:10 <glx> right but I can use this formula to simplify my decompile.sh (objdump wrapper)
17:49:29 <TrueBrain> below 0x3F00, memory is pretty straight-forward
17:50:18 <proyvind> btw. anyone knows about dos mz .exe files with "ZM" as file magic rather than "MZ", are those big endian?
17:50:31 <TrueBrain> proyvind: they should never exist
17:50:35 <TrueBrain> it mostly is a bug in the reader :p
17:50:42 <TrueBrain> ZM means indeed big endian READ, as DOS is always little endian
17:51:04 <TrueBrain> DOS only works on x86
17:51:11 <TrueBrain> there is no other hardware support
17:51:13 <TrueBrain> COFF assumed little endian
17:54:58 <proyvind> I figured that there might've existed big endian .exe binaries out there, with at least ms having ppc port of win nt in the past..
17:55:47 <TrueBrain> MS never supported PPC in any sane and real form
17:55:54 <TrueBrain> so you should never find ZM in the real world :p
17:56:21 <TrueBrain> (of course, depending on how you read the 16bit value :p)
17:56:55 <TrueBrain> but .. should never, doesnt mean it isn't there :p
18:13:57 <proyvind> glx: your decompiler.sh, is it available in the svn tree somewhere?
18:54:06 <glx> and it's just a quick script to resolve unresolved stuff (better use JIT when possible ;) )
continue to next day ⏵