IRC logs for #opendune on OFTC at 2009-09-18
⏴ go to previous day
10:02:51 <TrueBrain> Xaroth: I think we need a more simple new frontpage
10:03:07 <TrueBrain> like plain HTML for all I care, but that might not be the easiest to edit
10:36:54 <TrueBrain> k, added a project to bugs.opendune.org, I think it can now be used for real :p
10:37:03 <TrueBrain> jus tI wish you could remove 'priority' and stuff :p
10:37:07 <TrueBrain> or at least alter the values
10:37:29 <TrueBrain> and I wonder if it can trigger a callback to DorpsGek or something :p
11:38:57 <Xaroth> TrueBrain: like the ottd frontpage?
11:39:08 <Xaroth> only 'changing' part on that is the news entries
11:43:01 <Xaroth> ooo, apparently one of the clanpeople actually does C/C++ :o
12:05:22 <TrueBrain> Xaroth: well, openttd.org is a Django website, might be too complicated for now :)
12:05:29 <TrueBrain> I Was more thinking about something simple and efficient
12:06:13 <TrueBrain> I dunno if there is anything out there
12:06:26 <TrueBrain> Redmine simply eats too much memory
12:07:55 <TrueBrain> feeling better btw?
12:09:39 <TrueBrain> either way, downside of HTML is that without some CSS it looks butt ugly
12:09:52 <TrueBrain> Redmine makes it look good ;)
12:10:31 <TrueBrain> so any suggestions for a simple system that does look good? :)
12:32:34 <TrueBrain> this is very wrong ..
12:32:46 <TrueBrain> the 1C is taken over by Dune2, and should never be called via the hard_int
12:33:32 <glx> but it is called for mingw and msvc
12:34:12 <glx> you want the diff I used for the output?
12:35:53 <TrueBrain> this is when you don't move the mouse?
12:37:04 <glx> I let mingw run until the title, and let msvc run for about the same time
12:37:22 <glx> without moving mouse over the window
12:37:26 <TrueBrain> can you get ride of the pointers? They make comparing a bit annoying :)
12:38:32 <glx> I can replace them with callback names yes
12:43:48 <TrueBrain> overal it appears that mingw ticks faster
12:43:54 <TrueBrain> but it is hard to cmpare, as there is no indication of time
12:44:05 <TrueBrain> so you don't know how much they differ in time
12:45:26 <TrueBrain> okay, nevermind all that
12:45:33 <TrueBrain> the rpoblem is simple: SDL_SetPalette is not called enough
12:45:37 <TrueBrain> mingw calls it MUCH more often
12:47:36 <TrueBrain> can you check the value of _gfx_palette_update, and how that related to emu_io_write_3C9?
13:04:15 <TrueBrain> it still is weird that the mouse acts very strange from time to time
13:04:19 <TrueBrain> very consistant too
13:10:12 <glx> there are more calls to emu_io_write_3C9 with mingw
13:10:39 <TrueBrain> hmm ... and if you follow that rabbit into libemu/bios_asm.c, inb?
13:10:47 <TrueBrain> or inw .. dunno which one is used ;)
13:13:31 <TrueBrain> to see if there something strange is going on
13:13:37 <TrueBrain> maybe MSVC extends bytes weird or somethinf
13:14:01 <DorpsGek> SVN: commit (r49) by truebrain - -Add: mapped another 3 functions (general gameplay)
13:14:39 <glx> hmm maybe I should remove my debug stuff and enable emu_debug_int
13:14:55 <TrueBrain> haha, yes :) Forgot thatone was still there
13:15:01 <TrueBrain> that gives a shitload of information :p
13:15:06 <TrueBrain> of which mostly INB for palette animation :)
13:24:30 <glx> hmm it freezes with emu_debug_int
13:24:48 <TrueBrain> it just adds tons of fprintf(stderr) ...
13:27:44 <DorpsGek> SVN: commit (r50) by truebrain - -Move: move trunk/txt to extra/jit/txt, as normally you don't need it
13:28:19 <TrueBrain> there, that should make a bunch of you happy :) nsz: please be adviced about this change; you need to checkout this directory manually now :)
13:45:09 <TrueBrain> i noticed 'svn diff' became REALLY slow :p
13:47:43 <TrueBrain> oh, and one warning: svn update takes for ever for r50 :p
13:48:31 <nsz> for ever is already finished
13:49:25 <TrueBrain> clearly xfs has more problem with it :p
13:51:34 <nsz> ok now i could play for a while before crash
13:51:43 <TrueBrain> it is getting there ;)
13:52:10 <TrueBrain> I haven't had a crash in a while in the menu
13:52:59 <TrueBrain> okay, I think I have located the mouse problem
13:53:06 <nsz> busy loop is still a problem of course..
13:53:20 <nsz> i have to hide/unhide the window to play
13:53:29 <TrueBrain> I don't have such problem
13:53:57 <nsz> ok here i play using my wm's hide/unhide shortcuts
13:54:10 <TrueBrain> if you update libemu, you have a better working version of the mouse :)
13:54:13 <TrueBrain> no more random clicks :)
13:54:32 <TrueBrain> nsz: how do you mean exactly?
13:54:53 <TrueBrain> Xaroth: shall I put libemu in SVN under /extra/libemu for now? Makes it easier to find I guess
13:56:26 <nsz> well it is about 0.1 fps if i view the window
13:56:36 <nsz> and say 10 fps if i hide it
13:57:07 <TrueBrain> well .. it redraws the whole screen every time, so I guess it depends on how SDL handles that ;)
13:57:12 <TrueBrain> here it is fast, almost no CPU
13:57:18 <TrueBrain> only fade in/fade out is slow :p
13:59:23 <TrueBrain> hmm .. maybe libemu should be in src/3rdparty or something
13:59:36 <TrueBrain> on the other hand, I don't expec the API to ever change
14:13:45 <DorpsGek> SVN: commit (r51) by truebrain - [LibEMU] -Add: added LibEMU to the OpenDUNE SVN for easy referencing
14:14:16 <TrueBrain> glx: I made the mingw compile for you a tiny bit easier I hope
14:14:18 <TrueBrain> I now have to execute:
14:14:21 <TrueBrain> LIBS=/usr/i686-mingw32/usr/bin/SDL.dll SDL_INCLUDE=/usr/i686-mingw32/usr/include/SDL CC=i686-mingw32-gcc make WIN32:=1
14:14:25 <TrueBrain> but I think you can do: make WIN32:=1
14:14:36 <TrueBrain> can you also please test if MSVC is still working as expected?
14:21:59 <glx> make WIN32:=1 is not enough :)
14:22:42 <glx> cc: command not found, so I need CC=gcc
14:23:57 <glx> and sdl is in /usr/local/include/SDL
14:24:04 <TrueBrain> the latter I can't help :p
14:24:18 <TrueBrain> as it uses CC .... I can't help you don't have a correct setup CC :p Ghehe :)
14:24:56 <TrueBrain> /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -llibemu
14:25:01 <TrueBrain> hmm .. why is -L. not enough ...
14:25:05 <TrueBrain> libemu.so is in local dir
14:26:49 <glx> hmm you remove project file ?
14:27:03 <TrueBrain> oh ... not there ..
14:27:22 <DorpsGek> SVN: commit (r52) by truebrain - [LibEMU] -Add: also add the MSVC project files
14:28:52 <glx> I can't open msvc with double clic on sln
14:28:58 <DorpsGek> SVN: commit (r53) by truebrain - [LibEMU] -Fix: a few corrections in the Makefile
14:29:53 <glx> just because EOL, I know it's stupid :)
14:31:13 <DorpsGek> SVN: commit (r54) by truebrain - [LibEMU] -Fix: add svn:eol-style and $Id$ to all important files
14:35:13 <DorpsGek> SVN: commit (r55) by truebrain - [LibEMU] -Fix: MSVC project file fix and Makefile fix
14:36:19 <DorpsGek> SVN: commit (r56) by truebrain - -Fix: update Makefile for LibEMU in our SVN. It assumes the result is in the root of this directory
14:36:29 <TrueBrain> can you try trunk too, with the new files?
14:38:50 <TrueBrain> there, 64bit linux works too :)
14:43:38 <TrueBrain> with the weird mouse fixed, the game is good playable here now ...
14:44:55 <glx> lib order matters for mingw :)
14:45:39 <TrueBrain> even more as libemu is done by: libemu.a
14:45:48 <glx> that's a windows limitation I think
14:46:06 <glx> the problem is sdl must be after libemu
14:46:49 <TrueBrain> glx: btw, it did compile here ..
14:47:39 <DorpsGek> SVN: commit (r57) by truebrain - -Fix (r56): some versions of mingw want SDL.dll after libemu.a (glx)
14:49:29 <glx> and I use -lSDL to not need to copy SDL.dll ;)
14:49:37 <TrueBrain> oh, that works too?
14:50:40 <glx> yes it uses libSDL.dll.a as -static is not specified
14:51:28 <DorpsGek> SVN: commit (r58) by truebrain - -Fix (r56): listen to LDFLAGS, and use -lSDL for mingw
14:51:44 <TrueBrain> well, the idea was that it uses SDL.dll yes :)
14:52:02 <glx> and it uses it (I checked with depends)
14:53:17 <TrueBrain> soemtimes the mouse still acts funny
14:54:33 <glx> oh I tried to start a game but I clicked after selecting the house
14:54:57 <TrueBrain> it still does happen ;)
14:55:18 <glx> trying to watch the intro completely again
14:55:25 <TrueBrain> here that works, every time
14:55:31 <TrueBrain> if it fails, send me over your crash.bn
14:55:47 <glx> it fails to create this crash.bin, and only this one
14:55:56 <TrueBrain> darn, I need to add -m32 to attach the JIT .. I will forget this sooooo many time :p
14:56:07 <TrueBrain> then give me the text it produces
14:56:12 <TrueBrain> from where to where the jump failed
14:58:57 <glx> Program Termination: jumped to 1FB5:1661, which is not decompiled.
14:58:57 <glx> The jump was triggered at decompiled/cs__1FB5.c:3723
14:58:57 <glx> The jump appears to originate from 1FB5:163D.
14:59:42 <TrueBrain> LOL! Somehow I hit a bug ... I am done building 2 buildings, and I have 960 credits ...
15:02:39 <TrueBrain> glx: k, I can fix that for you by hand
15:09:08 <DorpsGek> SVN: commit (r59) by truebrain - [JIT] -Add: mapped another 90 functions (general)
15:09:26 <DorpsGek> SVN: commit (r60) by truebrain - -Add (r59): the decompiled code reflecting latest JIT data
15:10:09 <glx> I still don't know why msvc "fails"
15:10:25 <glx> maybe some flags are different
15:10:49 <glx> as it warns a lot about "truncation"
15:10:55 <TrueBrain> yes, uint16 -> uint8
15:11:00 <TrueBrain> I assume it does that via & 0xFF
15:11:12 <TrueBrain> I assume it does that correctly too
15:11:22 <TrueBrain> strangely enough, no gcc gives any warning on that :p
15:11:25 <glx> it also warns for 0xFF -> int8 :)
15:11:41 <TrueBrain> all thoses casts are spot-on, and should be there
15:11:52 <TrueBrain> but adding tons of casts doesn't increase the readability ... not a bit :p
15:13:28 <glx> and I don't know how to output asm like it's done for openttd releases
15:14:05 <TrueBrain> I don't know them ;)
15:14:13 <TrueBrain> is the intro problem now fixed btw?
15:17:16 <glx> Program Termination: jumped to 1FB5:1585, which is not decompiled.
15:17:16 <glx> The jump was triggered at decompiled/cs__1FB5.c:3509
15:17:16 <glx> The jump appears to originate from 1FB5:15AC.
15:17:31 <TrueBrain> you are not going to make this easy, are you? :p :)
15:17:59 <glx> and it segfault when generating the crash.bin
15:18:27 <TrueBrain> this one I can't fix without crash.bin
15:18:32 <TrueBrain> it jumps to an unknown function
15:18:36 <TrueBrain> I don't have enough data to harvest it
15:19:27 <TrueBrain> it still happens at the end of the intro?
15:23:08 <DorpsGek> SVN: commit (r61) by truebrain - [JIT] -Add: mapped another 5 functions (gameplay)
15:23:36 <DorpsGek> SVN: commit (r62) by truebrain - -Add (r61): the decompiled code reflecting latest JIT data
15:24:38 <TrueBrain> downside of 2 dirs .. I can't cross-commit
15:27:07 <glx> well you can cross commit if you have a common root ;)
15:27:25 <TrueBrain> the /extra/jit/txt has to be in /trunk/txt
15:27:29 <TrueBrain> killing that possibility :)
15:27:33 <TrueBrain> or I need to use symlinks
15:27:36 <TrueBrain> nah .. too darn ugly :)
15:28:39 <TrueBrain> when I put my PIC at 5ms, it takes VERY long before I get the first screen :p
15:30:08 <TrueBrain> some things go better with a faster timer, other things much slower :p
15:30:27 <TrueBrain> btw, nsz, your kernel doesn't run at 100Hz I guess
15:30:31 <TrueBrain> which might explain your slowness :)
15:30:48 <TrueBrain> (the timer runs at 50Hz, which is possible with a 100Hz kernel timer, not with a 50Hz or 25Hz :p)
15:32:04 <TrueBrain> glx: fast or slow, I can't get the error you get :(
15:40:43 <TrueBrain> removing an usleep helps ...
15:40:55 <TrueBrain> in return it eats MUCH more CPU :p
15:41:13 <TrueBrain> here it normally doesn't
15:41:18 <TrueBrain> so ... the usleep(0) doesn't work
15:41:22 <TrueBrain> can you try making that usleep(1)?
15:42:33 <TrueBrain> playing at 5 times the normal speed is fun!
15:43:16 <TrueBrain> oh, so try usleep(10)
15:43:24 <TrueBrain> as it really really shouldn't be eating a full core
15:43:54 <TrueBrain> going to run the intro at 5 times slower ... hoping it will then take the route it does for you ..
15:44:06 <TrueBrain> in the meanwhile I guess I should make some food, as this will be a while :p
15:45:29 <TrueBrain> [17:42] <glx> it's already usleep(1)
15:45:31 <TrueBrain> [17:43] <TrueBrain> oh, so try usleep(10)
15:45:32 <TrueBrain> [17:43] <TrueBrain> as it really really shouldn't be eating a full core
15:45:34 <TrueBrain> [17:43] <TrueBrain> going to run the intro at 5 times slower ... hoping it will then take the route it does for you ..
15:45:35 <TrueBrain> [17:44] <TrueBrain> in the meanwhile I guess I should make some food, as this will be a while :p
15:45:37 <TrueBrain> dunno if you got it ;)
15:45:52 <TrueBrain> here at least the usleep(1) makes the game run NOT at 100% CPU, and makes it start VERY slow :p Hehe :)
15:46:08 <TrueBrain> I think I will put the usleep on the timer ... might result in better performance ..
15:47:41 <glx> using bandwidth at max is not good for irc :)
15:48:45 <glx> especially when you notice it too late
15:52:46 <glx> usleep(10) or usleep(1) makes no real difference for me (maybe 1% CPU usage less)
16:00:43 <TrueBrain> that is really weird ...
16:00:47 <TrueBrain> maybe because it is threaded ...
16:00:59 <TrueBrain> maybe it should also block the timer thread for that time ...
16:01:08 <TrueBrain> but I really can't reproduce your calls here ....
16:01:36 <TrueBrain> running at 50 times the normal speed ...
16:02:21 <TrueBrain> that does give cool results :p
16:03:19 <TrueBrain> with 10000 it doesn't want to launch :p
16:04:21 <TrueBrain> glx: maybe a pic_suspend(); usleep(1); pic_resume();
16:06:27 <TrueBrain> well, maybe we should just remove the usleep
16:06:31 <TrueBrain> and let is run at 100% CPU on all platforms
16:07:35 <glx> without usleep(1) it's the same
16:07:59 <glx> maybe usleep does nothing for me
16:08:10 <TrueBrain> well, it makes the main thread sleep
16:08:12 <TrueBrain> not the timer thread
16:08:18 <TrueBrain> whereon linux it does both
16:08:59 <TrueBrain> glx: when does it crash for you now? Still at Evil Haroknnen?
16:09:12 <glx> yes at the end of the animation
16:11:33 <TrueBrain> if I here force that value to something, it crashes :p
16:12:21 <TrueBrain> well .. I compiled in some code ... maybe it fixes it ...
16:12:28 <TrueBrain> a bit dirty how I gathered the info, but oh well
16:12:37 <TrueBrain> it seems it is a check if a file exists
16:14:42 <DorpsGek> SVN: commit (r63) by truebrain - [JIT] -Add: mapped another 107 functions (general, intro, Windows-bugs)
16:15:31 <DorpsGek> SVN: commit (r64) by truebrain - -Fix: set svn:eol-stlye for MSVC project
16:15:41 <DorpsGek> SVN: commit (r65) by truebrain - -Add (r63): the decompiled code reflecting latest JIT data
16:15:48 <TrueBrain> glx: try this please :)
16:16:42 <DorpsGek> SVN: commit (r66) by truebrain - [LibEMU] -Change: remove a usleep(1), and use 100% CPU. It turns out that it is a too big timer-hog, and gives different results for Windows. We need a better way to avoid 100% CPU usage
16:16:53 <TrueBrain> 4 commits in 2 minutes .. whoho :p
16:21:36 <glx> Program Termination: jumped to 261F:0058, which is not decompiled.
16:21:36 <glx> The jump was triggered at decompiled/cs__261F.c:167
16:21:36 <glx> The jump appears to originate from 261F:0053.
16:22:40 * glx will try to fix the crash.bin crash :)
16:34:47 <TrueBrain> also code I really don't have :)
16:34:51 <TrueBrain> and again something that failed to open a file
16:34:58 <TrueBrain> do you have your data dir filled correctly? :p
16:37:03 <glx> yes, I extracted the bzip2 there
16:37:54 <TrueBrain> can you enable the emu_debug_int for mingw? As then you can see which file is giving the problem
16:38:09 <glx> last time I tried it hanged
16:38:24 <TrueBrain> so then we are flying blind ...
16:39:38 <TrueBrain> glx: do you have the file 'onetime.dat'?
16:40:16 <TrueBrain> hmm .. I do access all files with '/' as seperator
16:40:23 <TrueBrain> it btw work via wine
16:40:40 <glx> it works usually on windows too
16:41:19 <TrueBrain> can you validate if that works as expected?
16:45:38 <glx> ,...,...,...printf("access(%s, %d) = %d\n", buf, F_OK, access(buf, F_OK)); <-- I use that, but it should do the same
16:47:22 <glx> access(data/dune2.exe, 0) = 0
16:47:22 <glx> Program Termination: jumped to 261F:0058, which is not decompiled.
16:47:22 <glx> The jump was triggered at decompiled/cs__261F.c:167
16:47:22 <glx> The jump appears to originate from 261F:0053.
16:47:23 <TrueBrain> k, running that version too
16:48:38 <TrueBrain> so he is not to blame ..
16:49:02 <TrueBrain> needle in a haystack ...
16:51:24 <TrueBrain> I am suprised by the amount of files it fails to open :p
16:51:57 <TrueBrain> a bit like: intro5.wsa fails to open, now look in intro.pak for that file too
16:52:11 <TrueBrain> well, it is exactly like that :) Ghehe :)
16:53:40 <TrueBrain> btw, if you want to go through the intro fast, libemu/src/pic.c, in pic_run, usec_delta *= 100; or something :p
16:56:43 <TrueBrain> + emu_cmpws(&emu_get_memory16(emu_ss, emu_bp, -0x2), 0x0);
16:56:44 <TrueBrain> + if (emu_flags.zf) { /* Unresolved jump */ emu_ip = 0x0062; emu_last_cs = 0x261F; emu_last_ip = 0x0091; emu_last_length = 0x0016; emu_last_crc = 0x3265; emu_call(); return; }
16:56:46 <TrueBrain> + emu_cmpws(&emu_get_memory16(emu_ss, emu_bp, -0x2), 0x0);
16:56:47 <TrueBrain> + if (!emu_flags.zf) { f__261F_00A8_000E_768E(); return; }
16:56:58 <TrueBrain> euh ... is it me, or ... either one of that function is always called, not? :)
16:59:19 <TrueBrain> glx: hmm ... it turns out that the 'data' I uploaded triggers this problem yes
17:00:09 <glx> maybe put the md5 somewhere
17:00:22 <TrueBrain> well ... it is a bit weird :)
17:00:31 <TrueBrain> I btw had the problem by start-up directly
17:00:52 <glx> btw I have dune2 files somewhere on a cd
17:01:06 <TrueBrain> it magically has to be the right version
17:01:38 <TrueBrain> either way, now it was simple enough to compile in the missing functions :p
17:02:19 <glx> Program Termination: jumped to 261F:0062, which is not decompiled.
17:02:20 <glx> The jump was triggered at decompiled/cs__261F.c:229
17:02:20 <glx> The jump appears to originate from 261F:0091.
17:03:21 <glx> trying using my data files
17:06:42 <TrueBrain> lol, when I follow that route, I get the error that dune2.exe is not found :p
17:07:59 <TrueBrain> glx: I uploaded a new patch, and a new data package
17:08:13 <glx> doesn't start at all with my files
17:08:27 <TrueBrain> if dune2 only differce a tiny bit, it fails
17:09:56 <DorpsGek> SVN: commit (r67) by truebrain - [JIT] -Add: mapped another 20 functions (missing/wrong files at startup)
17:10:13 <DorpsGek> SVN: commit (r68) by truebrain - -Add (r67): the decompiled code reflecting latest JIT data
17:12:42 <TrueBrain> glx: now I cmoe to think of it .. given the crashlog can also not be generated ... it is like the working directory changed
17:12:48 <TrueBrain> can be some buffer overflow or what ever
17:13:20 <glx> where are the "new" data files?
17:16:53 <DorpsGek> SVN: commit (r69) by truebrain - [LibEMU] -Fix: tell when it failed to open the crashlog for writing
17:21:15 <TrueBrain> so something is just terrible wrong :p
17:21:21 <glx> maybe because the printf ;)
17:21:23 <TrueBrain> and when you click your mouse it does show you the menu?
17:28:53 <DorpsGek> SVN: commit (r70) by truebrain - [LibEMU] -Fix: hardware calls insert 0000:0000 as return address, to avoid stack corruption by 'clever' algorithms
17:30:01 <TrueBrain> that finally fixes all mouse errors :)
17:30:11 <TrueBrain> when an overlay was loaded on the mouse interrupt, corruption was created :p
17:30:35 <TrueBrain> ah, an harvester that arrives brings 7 credits :)
17:30:57 <TrueBrain> touch data/onetime.dat
17:31:13 <Xaroth> TrueBrain: 7 creds per %
17:32:21 <TrueBrain> then it comes with 1% ;)
17:32:32 <TrueBrain> glx: then I don't know what hte problem is, and I don't care :p It works under Linux ...
17:32:35 <TrueBrain> maybe we will find out some day :)
17:33:20 <TrueBrain> still graphical bug somewhere ... (white and red over all the screen)
17:34:39 <TrueBrain> it keeps saying now : Construction complete
17:34:41 <TrueBrain> there are still bugs :p
17:34:56 <TrueBrain> next week I will add some sanity checks to toc, which might be able to capture a few mistakes which slipped in the JIT :p
17:35:10 <glx> Program Termination: jumped to 1FB5:0766, which is not decompiled.
17:35:10 <glx> The jump was triggered at decompiled/cs__1FB5.c:1503
17:35:10 <glx> The jump appears to originate from 1FB5:0760.
17:35:10 <glx> Please send the file 'memory/crash.bin' to upstream developers.
17:35:11 <glx> ERROR: failed to open memory/crash.bin
17:35:17 <glx> at the end of the intro :(
17:35:35 <TrueBrain> beats the crap out of me why it wouldn't be able to open that file for writing
17:35:42 <TrueBrain> my guess is the working directory changed
17:35:52 <glx> does it try to write something in onetime.dat ?
17:36:01 <TrueBrain> when it doesn't exist, it will create it
17:36:12 <TrueBrain> but memory/crash.bin should be writable .. or your permissions are fucked?
17:36:21 <glx> when it doesn't exist it hangs at the end of the intro
17:36:23 <TrueBrain> it needs write access in data/ and memory/ !
17:36:38 <TrueBrain> so if you use NTFS, please check your permissions
17:36:40 <glx> when it exists it crashes
17:37:04 <TrueBrain> there is a good possibility it loops for ever trying to create the file
17:38:07 <glx> hmm seems explorer played with dir read only flag again
17:38:16 <TrueBrain> so that is the problem ;)
17:38:42 <TrueBrain> which means I can also fix it ...
17:40:19 <TrueBrain> hmm ... with only read access it still works here :p
17:41:29 <glx> anyway as it can create memory/crash.bin sometimes, it's not the problem I think
17:42:35 <glx> it only fails at the end of the intro
17:43:26 <TrueBrain> if he indeed can't create onetime.dat, it freezes up
17:43:39 <TrueBrain> the rest of the problems I can't reproduce
17:45:06 <DorpsGek> SVN: commit (r71) by truebrain - [JIT] -Add: mapped another 7 functions (permission errors on writing files)
17:45:26 <DorpsGek> SVN: commit (r72) by truebrain - -Add (r71): the decompiled code reflecting latest JIT data
17:45:59 <TrueBrain> I at least got the one which made it crash in your last crash report :)
17:46:03 <TrueBrain> so maybe it is now all fixed ;)
17:46:35 <TrueBrain> glx: let me know if there still are problems :)
17:46:40 <TrueBrain> I am gone for an hour or so
17:46:43 <TrueBrain> tnx for all this testing btw :)
17:46:47 <glx> added a printf in int21 type 3D
17:47:29 <TrueBrain> well, fopen("memory/crash.bin", "wb") fails too ... which makes me very scared :p
17:47:35 <TrueBrain> even if that isn't always, as you say ... that is just weird! :)
17:47:57 <TrueBrain> btw, 3C is CREATE FILE
17:48:05 <TrueBrain> and 3B is change dir
17:48:13 <TrueBrain> not that we really change the dir in any way
20:09:15 <TrueBrain> and glx, does it now work?
20:10:35 <glx> btw why not use open instead fopen for int21 3C and 3D ?
20:11:03 <TrueBrain> I first did only f functions
20:11:06 <TrueBrain> turned out to not work :p
20:11:10 <TrueBrain> feel free to replace it with open :)
20:11:38 <glx> the harder part is to get info about int21 flags :)
20:11:47 <TrueBrain> all flags are correct
20:12:24 <TrueBrain> but if you have any doubt, just ask, I have a big documentation here :)
20:12:52 <glx> hmm if more than 16 files are open, I fear a problem
20:13:06 <TrueBrain> there are never tha tmany files open for Dune2 :)
20:14:06 <glx> and I don't get why it hangs when I add printfs
20:14:24 <glx> unless it's a timer problem
20:14:30 <TrueBrain> by the fact it all works under Wine, neither do I
20:23:29 <DorpsGek> SVN: commit (r73) by truebrain - [LibEMU] -Fix: protect against invalid file handle access and protect against possible overflow when opening too many files
20:23:36 <TrueBrain> there, that should make you happy ;)
20:35:16 <TrueBrain> whoho, my sanity checks show that everything is as expected :)
20:38:44 <TrueBrain> very funny, I run the timer like 100 times faster
20:38:46 <TrueBrain> some things are faster
20:38:48 <TrueBrain> other things are not :p
20:39:49 <glx> hmm ok now it hangs at the end of intro and close by itself without errors
20:44:07 <TrueBrain> can it be a stack overflow?
20:44:36 <TrueBrain> what does the backtrace say?
20:44:37 <glx> but it may be a stack overflow yes, as the call stack is quite empty
20:44:53 <glx> #0 0x7c91e8e5 in strchr () from C:\WINDOWS\system32\ntdll.dll
20:45:26 <TrueBrain> we don't use strchr :p
20:45:37 <glx> I think all my problems are caused by timers anyway
20:48:48 <TrueBrain> timers are not that consistant
20:49:32 <glx> I think they are not accurate :)
20:49:47 <TrueBrain> would only mean they wait longer
20:50:04 <TrueBrain> but what is odd for me, is that wine works
20:50:19 <TrueBrain> and I know the game hits an infinite loop if it doesn't get the right permission on onetime.dat
20:50:21 <glx> wine works above linux kernel
20:50:23 <TrueBrain> can you make a savegame?
20:50:32 <TrueBrain> I am also suprised making the crash.bin doesn't work from time to time
20:50:40 <TrueBrain> what happens if you make it not in the map memory, but in the root?
20:52:17 <glx> to make a savegame I first need to be able to start a game :)
20:52:55 <TrueBrain> when you click you don't get the menu?
20:53:27 <glx> I get the menu, but if I click to pass the house description it crashes
20:53:39 <TrueBrain> use the keyboard, and try harkonnen
20:55:56 <TrueBrain> I am playing the game at 100 time normal speed .. it shows me a few missing functions ;)
20:56:08 <glx> the red globe stops rotation and after some time it just exit
20:56:37 <glx> stack overflow again I think
20:57:41 <TrueBrain> 4.4.1 here .. but that can't be it
20:57:53 <TrueBrain> it is very strange glx ...
20:57:53 <glx> segfault in strchr again :)
20:58:04 <TrueBrain> try compiling in -O3
20:58:46 <TrueBrain> my mouse keeps acting up .. how annoying :)
20:59:32 <TrueBrain> I played 5 hours and 15 minutes
21:03:01 <TrueBrain> how ever often I play, it keeps finding small things :(
21:03:49 <TrueBrain> I now managed to do it with 4 missing functions ... it is getting better :p
21:07:00 <DorpsGek> SVN: commit (r74) by truebrain - [LibEMU] -Fix: obey mouse region restrictions
21:12:17 <TrueBrain> I love that wine does a better job :)
21:15:58 <TrueBrain> but okay, so either wine allocates more stack, or something is toast
21:17:18 <TrueBrain> gcc -Wl,--stack,16777216 -o file.exe file.c
21:23:47 <TrueBrain> why are other OSes then your own always a pain in the butttttttt :(
21:30:31 <TrueBrain> weird weirder weirderestssts
21:31:21 <glx> anyway I blame the timers
21:31:42 <glx> I think it works in wine because internally it uses linux timers
21:32:01 <TrueBrain> how would that matter?
21:33:03 <TrueBrain> computers are deterministic
21:33:38 <TrueBrain> is there a valgrind or efence for mingw?
21:34:21 <glx> because it's quite impossible to do that on windows
21:34:35 <TrueBrain> they also said RTLD_LAZY is impossible :p
21:34:58 <TrueBrain> it does exactly what dl does on linux
21:35:09 <TrueBrain> well .. people call that a hack too
21:35:11 <TrueBrain> so I guess you are right :p
21:35:17 <TrueBrain> either way ... from the top, this problem
21:35:21 <TrueBrain> when yous tart the game, hit a key
21:35:25 <TrueBrain> and you do nothing in the menu
21:37:22 <TrueBrain> btw, sometimes I need to move my mouse too before it continues :p
21:37:38 <TrueBrain> the end-of-level stuff has that nasty habbit from time to time
21:39:19 <TrueBrain> glx: good .. it is an infinite loop :p
21:39:23 <TrueBrain> when you hit play game
21:39:44 <TrueBrain> sometimes I think there is a memory leak :p
21:39:58 <TrueBrain> I banned all vehicles :p
21:40:03 <TrueBrain> no harvester incoming :p
21:40:12 <TrueBrain> mostly the mouse still acts VERY weird
21:40:16 <glx> infinite loops are not a problem if they use jumps I think
21:40:19 <TrueBrain> it looks like the mouse button stays clicked :(
21:40:25 <TrueBrain> glx: yes, so I wonder what fails and what not
21:44:55 <TrueBrain> how much time before it crashes?
21:45:39 <TrueBrain> I dunno what happened ... but it is BAD! :p
21:47:53 <TrueBrain> weird, I do give all the right codes for the mouse
21:48:02 <TrueBrain> yet ... it somehow .. fucks up ...
21:49:15 <TrueBrain> again all my units just ... well ... are no longer there :p
21:50:00 <TrueBrain> that is a fairly long time
21:50:10 <TrueBrain> so it is something that is slowly growing .. so yes, stack overflow is the most logic
21:50:27 <TrueBrain> if you increase the speed of the pic
21:50:32 <TrueBrain> does it happen faster?
21:51:24 <TrueBrain> and else, does it happen faster if you do in pic.c, usec_delta *= 100;
21:53:22 <glx> hangs a little faster (12s)
21:54:26 <TrueBrain> k .. so possible the timer-thread leaks
21:54:40 <TrueBrain> maybe I miss a close handle somewhere?
21:54:50 <TrueBrain> as it would explain the failure to open files
21:55:12 <TrueBrain> and the fact it works on wine (linux has more file descriptors)
21:55:14 * glx will retry to use SetTimer
21:55:40 <TrueBrain> I will debug the amount of open files
21:57:20 <DorpsGek> SVN: commit (r75) by truebrain - [JIT] -Add: mapped another 89 functions (mostly gameplay)
21:57:41 <DorpsGek> SVN: commit (r76) by truebrain - -Add (r75): the decompiled code reflecting latest JIT data
21:57:49 <TrueBrain> many many many updates, but still .. not fully stable :p
22:00:36 <TrueBrain> glx: in the while () of WaitForSingleObject, can you add:
22:00:37 <TrueBrain> FILE *f = fopen("test.txt", "wb"); printf("%d\n", fileno(f)); fclose(f);
22:00:39 <TrueBrain> and see what it does?
22:00:42 <TrueBrain> wait, I just send you the exe
22:01:18 <glx> thx (I'm toying in this part of the code ;) )
22:01:29 <TrueBrain> yeah, that I could guess, so ;)
22:03:03 <TrueBrain> k, so that is not the issue
22:03:10 <glx> and crashs while the globe rotates
22:03:45 <TrueBrain> so now I will let the globe run for 20+ seconds
22:04:48 <glx> Program received signal SIGSEGV, Segmentation fault.
22:04:48 <glx> [Switching to thread 4272.0x1070]
22:04:48 <glx> 0x006ea377 in pic_windows_thread (arg=0x0) at src/pic.c:80
22:04:48 <glx> 80 src/pic.c: No such file or directory.
22:04:55 <TrueBrain> oh, wine crashes too!!
22:05:23 <TrueBrain> err:ntdll:RtlpWaitForCriticalSection section 0x110054 "heap.c: main process heap section" wait timed out in thread 0015, blocked by 0009, retrying (60 sec)
22:06:01 <glx> so the problem is the timer :)
22:06:50 <TrueBrain> somehow I think it is the stack
22:07:14 <glx> in relation with the timer thread
22:09:14 <TrueBrain> this will be fun to port to OSX :p
22:10:40 <TrueBrain> hmm .. all the time it was doing palette updates ... then that stops ...
22:15:20 <TrueBrain> k, stackoverflow checks turn out negative
22:15:34 <TrueBrain> the timer keeps on ticking
22:15:40 <TrueBrain> the main thread is the one who is not coming back
22:19:18 <TrueBrain> glx: does MSVC also crash? (when you keep moving your mouse :p)
22:20:00 <nsz> does osx use msb first byteorder?
22:20:33 <TrueBrain> oh well, don't know
22:20:37 <TrueBrain> PPC uses other than Intel :p
22:20:55 <nsz> if osx is intel then that's not a problem then
22:21:05 <TrueBrain> latest Apple computers are
22:21:15 <TrueBrain> since .. a few years now :p
22:21:18 <TrueBrain> the PPCs are dying out
22:21:21 <nsz> i don't follow crapple news..
22:22:37 <glx> Program Termination: jumped to 29E8:0663, which is not decompiled.
22:22:37 <glx> The jump was triggered at ..\decompiled\cs__29E8.c:644
22:22:37 <glx> The jump appears to originate from 29E8:065A.
22:22:49 <TrueBrain> don't move your mouse in any special way :p
22:22:56 <glx> while moving mouse with msvc to make the palette animation work
22:23:23 <TrueBrain> I can't manually link them :(
22:23:43 <glx> I have a crash.bin for this one
22:23:47 <TrueBrain> I never tried waiting that long in linux, so lets see ..
22:24:11 <TrueBrain> well, crash.bin from the mouse are a bit useless :(
22:24:40 <TrueBrain> I guess mouse handling will be prio 1 to convert :)
22:26:45 <TrueBrain> under linux it keeps on going and going and going and going and ... :p
22:31:03 <TrueBrain> when I increase usec_delta, it happens faster ...
22:34:58 <TrueBrain> 199 0x006df8dc in opendune (+0x2df8dc) (0x00bcbba8)
22:34:59 <TrueBrain> 200 0x0058bd1c in opendune (+0x18bd1c) (0x00bcbbc8)
22:35:02 <TrueBrain> tons and tons and tons and tons of those :)
22:35:22 <TrueBrain> so I can only guess that mingw gcc doesn't optimize all tail-calls as good as mine linux gcc does
22:36:21 <TrueBrain> in the end, it is a stack problem ;)
22:36:42 <TrueBrain> (I attached a debugger to wine, and aborted when it went crazy)
22:36:58 <TrueBrain> sadly, it doesn't resolve the entries for me
22:37:05 <nsz> grep Unresolved decompiled/*.c |wc -l
22:37:52 <TrueBrain> nsz: ghehe, not bad! :)
22:38:06 <TrueBrain> I guess many can be resolved with a bit smartness
22:38:30 <TrueBrain> (the fact you haven't seen the jump doesn't mean you don't know where it ends up :p)
22:40:07 <TrueBrain> I count 4774 unknown in r29 ..
22:40:09 <TrueBrain> not really going forward ;)
22:40:17 <TrueBrain> new functions tend to intrudoce more of them :p
22:40:25 <TrueBrain> when you mix functions, many are resolved :p
22:41:12 <TrueBrain> glx: is there any way to find out what is at those 2 locations?
22:42:21 <TrueBrain> [00:34] <TrueBrain> 199 0x006df8dc in opendune (+0x2df8dc) (0x00bcbba8)
22:42:22 <TrueBrain> [00:34] <TrueBrain> 200 0x0058bd1c in opendune (+0x18bd1c) (0x00bcbbc8)
22:42:41 <glx> only for msvc builds with corresponding pdb
22:42:56 <glx> maybe it's possible for gcc builds too, but I don't know how
22:44:01 <TrueBrain> but okay .. it for sure is some loop
22:44:33 <TrueBrain> it was to be expected ... the code is really dirty in this :)
22:44:38 <TrueBrain> guess we have to hurry cleaning it up ;)
22:46:24 <TrueBrain> nsz: does the latest version run more smooth for you?
22:46:33 <TrueBrain> glx: I give up on this problem for now; we will revisit it in a few weeks I guess
22:47:31 <TrueBrain> for now, I put that on there :)
23:00:05 <TrueBrain> nsz: it turns out 645 functions would be easy to resolve (as the data is available). Just my code is ugly which gives me these stats ... solving it completely would be even more nasty (layer violations)
23:02:52 <TrueBrain> oh, make that 2842 functions
23:03:11 <TrueBrain> then we have the calls that jump inside known bytecode ... I guess I could try to put all the txt memory entries next to eachother, and run a full static analyser over that :)
23:03:34 <TrueBrain> so making a map of the pieces we know :)
23:06:53 <TrueBrain> either way, time for my bed :)
23:07:00 <TrueBrain> glx: thanks once again
continue to next day ⏵