IRC logs for #opendune on OFTC at 2009-09-23
⏴ go to previous day
00:34:21 *** PeterT has joined #openDune
07:44:26 <TrueBrain> not any real issue :p
07:44:42 <TrueBrain> in his life, he joined every channel I am on, or ever was
07:45:01 <Xaroth> yes, but did he register on every forum as well?
07:45:03 <TrueBrain> I think he secretly is in love with me
08:07:08 <Xaroth> realised that it was 9:45 and I had a deployment from 9:00 to 10:00 :o
08:07:14 <Xaroth> had to .. speed things up a bit
08:08:45 <Xaroth> small deployment, but we always reserve 1 hour at minimum for them, in case shit hits the fan etc
08:09:04 <TrueBrain> shit all over the place
08:09:24 <Xaroth> going to bump the topic on fed2k
09:34:55 <Xaroth> TrueBrain: got a google account?
09:35:08 <Xaroth> put analytics on all the pages
09:35:26 <Xaroth> except redmine, since we need to replace that anyhow
09:38:03 <TrueBrain> it holds page loading most of the time, it has conditions in their ToS which I found doubtful, at least, ....
09:38:25 <TrueBrain> no googlecode pages
09:38:57 <Xaroth> their new version is quite optimized, it's their old version that hogs pageload
09:39:13 <TrueBrain> I never seen the use of stats like that
09:40:05 <TrueBrain> but okay, I don't care, as lnog as I don't have to work with it :p
09:40:19 <Xaroth> I have.. but then again we resell nedstat...
09:40:59 <TrueBrain> it only bloats a webpage :p
09:43:52 <Xaroth> I'll let it run a few days/weeks, see if it impacts things, I know where things are and how to remove it quick anyhow
09:44:19 <TrueBrain> I just have a very strong personal dislike to anything google related
09:44:38 <TrueBrain> we btw should be putting Powered by Leaseweb on most pages
09:51:52 <TrueBrain> bah, I really have a hard time finding where what happens in an easy way :p
09:55:18 <Xaroth> lack of named variables sucks :)
09:55:56 <TrueBrain> and lack of proper named functions :P
09:59:26 <Xaroth> hm, where to put the powered by
10:04:17 <Xaroth> web.opendune.org is 'active', right?
10:04:38 <TrueBrain> it is only used for CNAME
10:04:41 <TrueBrain> it contains no page
10:08:08 <Xaroth> that ?ecmp=openttd part in the link can be changed to opendune?
10:08:20 <TrueBrain> openttd is their identifier for us ;)
10:10:55 <Xaroth> put the image as used on openttd site on the overall footer for the forum
10:11:18 <Xaroth> at least for the time being, until I can find a proper way to include it
11:54:21 *** ChanServ sets mode: +v Yexo_
11:59:32 <TrueBrain> Xaroth: I made a nice reply too :p
12:03:02 <TrueBrain> I don't like people who say you have to be doing something completely wrong, without asking why it happens in the first place
12:05:21 <TrueBrain> oh, I missed a :p in that sentence
12:14:16 <TrueBrain> @calc 0x29e80 + 0x700e
12:14:57 <TrueBrain> something is weird ...
12:15:04 <TrueBrain> emu_movw(&emu_ax.x, 0x353F);
12:15:06 <TrueBrain> emu_movw(&emu_ds, emu_ax.x);
12:15:07 <TrueBrain> emu_movw(&emu_dx.x, emu_get_memory16(emu_ds, 0x00, 0x700E));
12:15:09 <TrueBrain> emu_movw(&emu_get_memory16(emu_cs, 0x00, 0x1B3), emu_dx.x);
12:15:14 <TrueBrain> this is what normally happens when reading 0x700E (some flag, dunno what it does yet)
12:15:27 <TrueBrain> emu_push(emu_ax.x);
12:15:28 <TrueBrain> emu_movw(&emu_ax.x, emu_get_memory16(emu_ds, 0x00, 0x700E));
12:15:30 <TrueBrain> emu_movw(&emu_get_memory16(emu_cs, 0x00, 0x1B3), emu_ax.x);
12:15:35 <TrueBrain> this reads from a COMPLETELY different location ...
12:15:56 <TrueBrain> first it pushed emu_cs, then pops emu_ds
12:15:59 <TrueBrain> so: emu_ds = emu_cs;
12:16:05 <TrueBrain> (but this is invalid in assembly :p)
12:16:23 <Xaroth> yeh, but at the same time it's using emu_ds to the get_memory
12:16:37 <TrueBrain> but emu_ds has different values, my problem ;)
12:17:09 <Xaroth> it's confusing as fooook :P
12:17:23 <TrueBrain> for all I know it is a bug :p
12:33:05 <TrueBrain> often weird things happen with ds ...
12:33:18 <TrueBrain> like: emu_ds = emu_cs, and then it goes using emu_cs only, and restores emu_ds as value :p
12:35:41 <TrueBrain> okay, I really go with bug in this case .. I just looked (via DOSBox) what is really in tha tpiece of memory, and it can't be related :p
12:50:47 <DorpsGek> SVN: truebrain (r95) -Fix: a 0x3F should have been a 0x7F
12:50:52 <TrueBrain> the mistakes are already started :p
12:56:44 <glx> Xaroth: can you send me your opendune.exe (if it still works) ?
12:57:18 * planetmaker also feels the urge to play this nice game again :-)
12:57:29 <TrueBrain> compile it :p :p :p
12:59:00 <Xaroth> glx: at work atm, but will see what I can do (yay rdp)
12:59:13 <DorpsGek> SVN: truebrain (r96) -Update: MSVC project file update (glx)
13:01:18 <Xaroth> ok, maybe two minutes... slow connection due to torrents :P
13:01:29 <glx> just hl me when it's done ;)
13:02:06 <TrueBrain> I can also smell what a certain var should do, but I can't put my finger on it :p
13:02:14 <TrueBrain> it is also copied to the local space for no clear good reason ...
13:03:21 <Xaroth> glx: er.. done? can't really see but i'm guessing it should be done by now :P
13:04:59 <TrueBrain> hmm .. maybe it is a mask what keys are accepted and which not ...
13:05:15 <glx> something is really weird
13:05:56 <glx> release or debug libemu ?
13:08:17 <Xaroth> TrueBrain: replies on fed2k :P
13:08:30 <glx> ok works with debug libemu
13:08:42 <TrueBrain> Xaroth: I am not even going to reply to that
13:08:52 <TrueBrain> someone who doesn't want to take the effort to look into what we are doing, I refuse to reply to
13:09:40 <Xaroth> glx: so if you compile release opendune with debug libemu, it works as well?
13:10:03 <glx> but release opendune with release libemu fails
13:10:06 <TrueBrain> so, libemu should be compiled in debug mode ...
13:10:26 <Xaroth> maybe stuff runs too fast in release mode?
13:10:47 <glx> or optimisations modify behaviour
13:11:26 <TrueBrain> "beste stuurlui staan aan wal", refering to fed2k .. anyway ... what was I doing :p
13:14:24 <TrueBrain> very cool, netbeans can mass-rename a field in a struct
13:14:27 <TrueBrain> now THAT is useful :)
13:15:20 <TrueBrain> "A 96 bit array, where each active bit says if a key is pressed." <- how to call a variable which does that? :p
13:16:58 <Xaroth> then again, both can do
13:17:23 <Xaroth> glx: where are you from anyhow?
13:18:01 <Xaroth> ipv6 addresses don't have a country tld :P
13:18:02 <glx> oh someone not knowing me :)
13:18:55 <glx> my IPv4 is something.proxad.net, won't help you I guess ;)
13:19:10 <Xaroth> but seeing you're being more than helpful for the cause, it's a bit odd to refer to you as 'that dude with the ipv6 address'
13:21:19 <Xaroth> TrueBrain: you ever done anything in the area of like.. php manuals ? :P
13:22:42 <TrueBrain> for a long time in fact, but the PHP translation system is kind of fucked
13:22:49 <Xaroth> just noticed your name on the list
13:22:49 <TrueBrain> it is hard to keep up-to-date with english
13:22:52 <TrueBrain> (without going insane :p)
13:23:50 <Xaroth> I think I confused the fuck out of nyer
13:24:52 <TrueBrain> I think he now thinks: this is never going to work :p
13:25:04 <Xaroth> and we'll prove him wrong, har har
13:29:49 <DorpsGek> TrueBrain: 110111101110
13:32:07 <TrueBrain> requested: sanity check
13:32:10 <glx> hmm "Run-Time Check Failure #2 - Stack around the variable 'buf' was corrupted." in emu_int21()
13:32:12 <TrueBrain> (names, comments, ..)
13:32:31 <TrueBrain> glx: be on the watchout for any stack overflow, which can kill any variable
13:32:45 <glx> it's nice to be able to run opendune in msvc :)
13:33:27 <glx> ok it's indeed a stack overflow
13:36:46 <TrueBrain> a VERY weird one, as the data doesn't add up
13:37:25 <TrueBrain> line 227 should trigger a crash report and stop
13:37:46 <TrueBrain> line 29 in that file is a return of a check that is clearly not happening
13:38:54 <TrueBrain> but my patch, any comments?
13:39:54 <TrueBrain> I think that is obvious from the patch :p
13:40:44 <TrueBrain> names make sense? ALLOW_NO_CLICK mostly?
13:41:15 <DorpsGek> SVN: truebrain (r97) -Add: figured out what 3 variables do
13:41:26 <glx> it's consistant with other flags
13:41:29 <TrueBrain> glx: I really can't make head or tail from your backtrace .. it looks odd
13:42:45 <TrueBrain> but given that f__1FB5_1B75_000F_53C7 never returns, the code on itself is already a bit fishy :p
13:43:25 <glx> steps used were, start, press '5', press '5', press 'H' :)
13:44:28 <glx> and debug build oveflows immediately
13:44:37 <TrueBrain> I can't get the same backtrace with gcc :p
13:44:46 <TrueBrain> you really need optimizations for OpenDUNE to work ;)
13:45:21 <glx> yes but if libemu is optimised it doesn't work
13:45:45 <TrueBrain> for OpenDUNE, not for LibEMU :p
13:45:59 <TrueBrain> for the latter it really shouldn't matter .. but I am sure it is something silly somewhere hiding :p
13:46:57 <TrueBrain> oh well, at least something to work with ;)
13:47:54 <TrueBrain> Xaroth: btw, about 'tools' to identify ifs, whiles and the shit, he forgets one essential thing: our biggest loop, the main loop, walks over several segments, over several overlays .. it is impossible with any 'tool' to resolve that in one function to resolve the stack problem ;)
13:48:20 <TrueBrain> what I can tell so far is that it is one long chain of actions, where the last entry in the chain jumps back to the first
13:48:37 <TrueBrain> of which glx is now noticing the problems :p
13:49:26 <TrueBrain> (I am still amazed gcc here found a way to optimize that enough to avoid the stack problem :p)
13:50:02 <TrueBrain> one option, to make all function-calls long jumps :p
13:51:07 <glx> ok with more optimisations it hangs now, waiting for the crash
13:52:57 <glx> caused by a stack overflow again
13:53:44 <TrueBrain> and still a VERY odd one :p
13:54:23 <TrueBrain> but okay, 261F is the overlay manager
13:54:26 <TrueBrain> strange things happen there :p
13:55:39 <glx> one of the strange thing is the overlays ;)
13:57:32 <TrueBrain> I really have no clue how it can work here :p
13:57:41 <TrueBrain> there is no logic order in what that function does ...
13:58:22 <glx> overlays are really a nasty thing
13:58:31 <TrueBrain> but most of that should be resolved :)
13:58:40 <TrueBrain> okay ... when I run DOSBox, that piece of code is never called
14:00:04 <TrueBrain> when I add a printf, the function 261F:0062 is never called
14:00:49 <TrueBrain> so what ever happens, that backtrace is faulty :)
14:03:27 <glx> so maybe a threading problem
14:03:51 <TrueBrain> when the second thread runs, like now, the first thread should be locked
14:03:58 <TrueBrain> (if you use the latest libemu, that is)
14:04:36 <TrueBrain> before the timer-thread starts to execute anything, it locks down the main thread
14:05:11 <glx> yes, but I don't know if that really works
14:05:14 <TrueBrain> and other code makes sure the timer-thread never execute twice
14:05:27 <TrueBrain> if not it will fail very often very fast ;)
14:05:48 <TrueBrain> and for sure your results won't be this stable :)
14:06:05 <glx> anyway msvc build hangs like gcc build
14:06:07 <TrueBrain> I can only guess that the backtrace is wrong
14:06:23 <TrueBrain> try gcc for a backtrace?
14:08:28 <glx> Program received signal SIGSEGV, Segmentation fault.
14:08:28 <glx> 0x7c91e8e6 in strchr () from C:\WINDOWS\system32\ntdll.dll
14:08:28 <glx> #0 0x7c91e8e6 in strchr () from C:\WINDOWS\system32\ntdll.dll
14:08:37 <TrueBrain> total corruption, WHOHO
14:09:17 <TrueBrain> it might be that gcc optimized so much here, that my printfs are simply never executed ... I don't know :p
14:09:18 <glx> timer handling is not threaded on linux I guess
14:09:47 <TrueBrain> glx: the chances this is a thread problem are 0.1% in my opinion
14:09:52 <TrueBrain> it is just some big infinite loop
14:10:22 <glx> well the infinite loop is not compiler dependant it seems
14:10:26 <TrueBrain> and the problem with stack overflows, they tend to .. well .. fuck up the stack :p
14:12:33 <TrueBrain> she has a nice voice :)
14:13:57 <TrueBrain> very strange and annoying I can't get my printf to print at the position you report problems glx .. as that code once clearly did execute on either mine or nsz machine :p
14:18:21 <TrueBrain> DoTheSameChangeInShopThenDoTheSameChangeInInventoryForNotChangedDataInInventory
14:18:39 <TrueBrain> yes, you can overdo anything :p
14:18:59 <TrueBrain> Xaroth: enough already :p
14:20:14 <TrueBrain> glx: all I can say is that I guess and hope that in time such issues resolve themselves :p
14:21:20 <TrueBrain> glx: if you really want to be sure about threads, add some prints in the timer thread, and change the #if 1 in libemu.h to #if 0, and alter data_monitor in libemu.c to print which thread is doing the memory read/write
14:21:36 <TrueBrain> memory read/writes are done often enough to give you a good visual about the flow
14:22:11 <TrueBrain> but seen how gdb crashes, I think it is some hell of a nasty stack corruption :p
14:22:24 <TrueBrain> maybe you can abort the program when the planet is running, see where it is then :p
14:25:49 <TrueBrain> but okay, I think we can better revisit this in a few days/weeks, when I did some more converting .. that I at least have a clue about what is going on :p
14:26:08 <TrueBrain> I guess you can add a printf at the lines in the backtrace, and check when they are start to being called
14:26:42 <TrueBrain> (btw, debug mode here, with -O0 -g, crashes too immediatly)
14:37:04 <glx> [EMU] [ INT21:3D ] Requesting mode '20' which is not completely supported.
14:37:04 <glx> [EMU] [ INT21:3D ] Requesting mode '20' which is not completely supported.
14:37:04 <glx> [EMU] MEMORY ACCESS: 0xFFFFE; VALUE: 000000FC
14:37:04 <glx> [EMU] PAST MEMORY ACCESS: 0xFFFFE; VALUE: 000000FC
14:37:58 <glx> (just changed #if 1 to #if 0)
14:50:42 <TrueBrain> glx: yes ..... but that was not what I suggested ;)
14:51:00 <TrueBrain> the data_monitoring normally is for monitoring memory access of certain regions :)
14:51:12 <TrueBrain> in SVN that is the highest piece of memory, because that was the last I debugged :p
14:59:06 <Xaroth> Google [Bot] Wed Sep 23, 2009 1:24 pm Deactivate Edit Delete
14:59:14 <Xaroth> MSN [Bot] Sun Sep 20, 2009 7:05 am Deactivate Edit Delete
16:47:41 <TrueBrain> when I set a bit, I can call that Toggle .. when I switch it off, I call it ... ?
16:47:49 <TrueBrain> like: Input_AllowedToggle and Input_Allowed....
16:51:19 <TrueBrain> this only sets it on, or only sets it off
16:51:43 <TrueBrain> but that looks like it sets all the allowed settings
16:51:50 <TrueBrain> it only switches on what you give, never switches off
16:52:09 <TrueBrain> so when I give it 0x0800, it doesn't touch anything beside that bit
16:52:18 <TrueBrain> Allowed should come first, that for sure
16:52:41 <TrueBrain> AllowSetBit? Reads weird ...
16:53:02 <Xaroth> is it a mouse-only thing or an input-generic?
16:56:23 <TrueBrain> it can set multiple bits :p
16:56:31 <TrueBrain> in fact, it is more like a mask :p
16:56:42 <TrueBrain> grr, naming a function to be clear without spending a lot of letters on it, can be nasty :p
16:56:58 <Xaroth> SetTheAllowBitMaskToACertainValue
16:57:45 <Xaroth> SetAllowBitMask isn't that much letters though
16:57:52 <Xaroth> on the edge of much, but not yet
16:58:06 <TrueBrain> my problem is that in general I dislike having Set in front of functions
16:58:14 <TrueBrain> I personally like having what it is about as first word
16:58:21 <TrueBrain> so sorting from A to Z makes sense :p
16:58:36 <Xaroth> well with Allow it's a bit dodgy
16:58:48 <Xaroth> AllowSetBitMask indicates whether you allow "SetBitMask" or not
16:58:48 <TrueBrain> maybe Filter is a better term in general?
16:59:10 <TrueBrain> Allow_SetBitMask, easy to solve that ambigious :p
16:59:29 <Xaroth> well that would more be
16:59:58 <TrueBrain> but okay, I find the variable 'allowed' confusing
17:01:33 <Xaroth> Flags will be a common occurrance I think
17:01:39 <TrueBrain> you say that a lot, and I still have no clue what you mean with that (shrugs part)
17:01:46 <TrueBrain> I can't find any emotion attached to that action :p
17:02:10 <TrueBrain> if that is what you mean with it, fine by me ;) Tnx :)
17:02:33 <Xaroth> NL: het schouderophalen
17:09:15 <TrueBrain> netbeans is useful for mass renaming :)
17:12:13 <TrueBrain> I wonde rhow often I will keep on uploading stuff to openttd instead of opendune :p
17:14:12 <TrueBrain> in a start of a project I always have a lot of trouble how to name things :p
17:14:20 <TrueBrain> like this Flags_ <- the _ .. I wonder if that is such a good idea
17:14:49 <Xaroth> it improves readability
17:14:53 <Xaroth> we can always rename later.
17:15:06 <TrueBrain> fixed a few naming errors
17:15:17 <Xaroth> I think the importance of being able to tell A from B weighs a tiny bit higher than neatness in naming
17:15:36 <TrueBrain> in my experience, you will never rename later :)
17:16:01 <Xaroth> then we'll have it that name :)
17:31:58 <DorpsGek> SVN: truebrain (r98) -Add: more work on the input; it turns out that g_mouse is in fact g_input
17:35:49 <TrueBrain> Xaroth: please update the wiki with your MSVC howto ;) (a bit more preserving :p)
21:56:24 *** ChanServ sets mode: +v Yexo
22:21:34 *** ChanServ sets mode: +v Yexo_
continue to next day ⏵