IRC logs for #opendune on OFTC at 2009-10-27
⏴ go to previous day
00:57:58 <boekabart> TrueBrain: digger works like a charm, I found the place to put the frame-timer - but I keep running into corner cases that havent' been compiled yet. You sure there's no way to statically 'do' digger.com ?
03:27:41 *** boekabart_ has joined #openDune
03:27:42 *** boekabart is now known as Guest537
03:27:42 *** boekabart_ is now known as boekabart
07:21:37 *** Xaroth has joined #openDune
07:21:37 *** ChanServ sets mode: +o Xaroth
07:43:40 *** Xaroth changes topic to "Teaser-2 released || Websites *.opendune.org: www, forum, bugs, wiki, svn || T-5d"
08:19:11 <Xaroth> ssh is somewhat flawed
08:19:23 <Xaroth> my internet was down all night, from around 2am to 7am
08:19:29 <Xaroth> yet my connection at office never dropped
09:31:38 <Xaroth> emu_repne_scasb O_O O_O
09:33:00 <Xaroth> compare string something
09:40:57 *** kyzeus has joined #openDune
09:47:13 <Xaroth> he came, he saw, and he ran off again
10:04:40 *** boekabart has joined #openDune
10:05:03 <boekabart> TrueBrain: did you get my msgs?
10:05:37 <TrueBrain> and again: no, it is not possible :)
10:05:44 <TrueBrain> you can keep asking, but I need to keep replying the same :p
10:05:55 <TrueBrain> you need to run with the JIT attached to map the whole app :) That is the name of the game :)
10:06:06 <TrueBrain> but you can resume crash.bins with the JIT: ./main memory/<name of bin>
10:06:15 <TrueBrain> make sure to rename it from crash.bin to something else, else things go wrong :p
10:08:36 <boekabart> ah, cool. even when I run on win32?
10:09:11 <TrueBrain> win32 can't run the JIT, so no :p
10:09:19 <boekabart> I hacked the SDL_Delay(60) into a emu_pop() where the popped value is the address of the end of the 'inner loop' so that it's playable
10:10:00 <boekabart> yeah, only way to get it to work on linux: it seems that if I put it in the decompiled c and remake main, it doesn't use it?
10:10:04 <boekabart> always jits, or so?
10:10:07 <TrueBrain> btw, you can move functions into the src/ directory, if you keep the @implements and @name, it will, after re-decompiling, not take it with it
10:10:21 <boekabart> i meant: I could use the crash.bin from win32 to resume jit on linux
10:10:46 <TrueBrain> yes, any crash.bin can be used in the JIT (they are on all platforms of identical information
10:10:57 <boekabart> ah - so that's the trick. good to know (I made the 'fire' button (F1) instant-reactivate already, my first game change)
10:11:07 <boekabart> makes finishing the game a lot easier :)
10:11:31 <TrueBrain> but that is the idea, that you move all decompiled/* files to src/*, and make them more readable while doing that :)
10:11:43 <TrueBrain> keep the @name and @implements, and the decompiler considers that good enough
10:12:01 <TrueBrain> if you give the function another name (change @name too), it even renames all the callers to
10:12:41 <boekabart> ah cool. So, changes made in de .c files in decompiled are always 'ignored' ?
10:15:52 <Xaroth> boekabart: and you said TB was making trainers for dune, tsk :P
10:16:47 <Xaroth> too much snowboarding? :P
10:19:42 <Xaroth> the visitor count for bugs.
10:20:05 <boekabart> I wish TrueBrain would get paid to work on the decompiler; the generated code could be SO much more 'optimized' in a 'readablitity' sense...
10:20:18 <TrueBrain> so ... get your boss to pay me :p
10:20:23 <boekabart> especially those NOP jumps are nasty: it's really hard to find real interesting jumps
10:20:56 <boekabart> TrueBrain: I'm sure that when you're done studying, our company would love to have a chat with you :)
10:20:56 <Xaroth> forum: UP870,97% svn: UP481.25%
10:21:01 <Xaroth> we're getting famous :P
10:21:21 <TrueBrain> boekabart: I am afraid I never get done with studying .. boring shit :(
10:21:53 <boekabart> TrueBrain: depends on the definition: I got done at some point... but never got the diploma...
10:22:19 <TrueBrain> I am very afraid I will go the same way ... :(
10:22:40 <boekabart> in our field of work, that matters only for SOME companies - many just look at what you've done and can do
10:23:06 <TrueBrain> well, there is a lot of money involved ... and we all call it: IB-Groep
10:23:22 <boekabart> it's only a problem if you've got nothing to show for it (example: if you've been drinking and partying for 9 years)
10:23:43 <boekabart> I was the last generation paid-by-the-year
10:23:46 <TrueBrain> my CV is longer than most others of my studie, so I am not afraid of that :)
10:24:13 <boekabart> two out of 4 years, I had to pay back.. (actually, still doing that at a whopping 45 euros a month)
10:24:48 <TrueBrain> well, if I can finish my study this year, I have to pay back a few less k .. so I am trying my atmost :)
10:24:52 <TrueBrain> just there are SO MANY OTHER COOL THINGS
10:31:55 <TrueBrain> btw, boekabart, resuming crash.bin is a tricky job, as there will be 'faulty' data
10:32:11 <TrueBrain> I don't really have any way to explain how to detect those ... :p I didn't in all cases :(
10:32:26 <TrueBrain> again it would be possible to solve that, but .. it requires a good rewrite of a few things :)
10:33:04 <TrueBrain> (it has to do that in the static version returns are not recorded, where the JIT does record them .. therefor the return-stack is broken in crash.bin, and the JIT starts throwing random addresses :p)
10:33:29 <TrueBrain> at some point ./toc --static will report errors, it is mostly safe to change the txt files to remove those errors, where you remove the latest addition :p
10:37:05 <boekabart> I can just play in linux (works a lot better if the vm runs on the local host, instead of via RDP on another server :) )
10:37:13 <boekabart> another thing by the way:
10:39:09 <boekabart> I followed the procudure: toc fp fp.exe; make and ./main, pressed E , space, space to get to the 1-2-player/network screen, then exited F10 clean exit from game, back to toc: toc --static fp then to fp, make -> linker errors. 2 functions referenced but missing
10:42:05 <TrueBrain> doesn't happen that often :p
10:42:17 <boekabart> i hadn't seen that before
10:42:33 <TrueBrain> it should detect all start-functions, but it doesn't always :p
10:43:14 <TrueBrain> lot of defined and shit
10:44:06 <TrueBrain> it picked up none of the 0070 (IVT entries)
10:44:06 <boekabart> i guess you could reproduce it easily if you didn't have to many other cool things to do :D
10:45:00 <boekabart> here cs__0070 has :void f__0070_0040_0005_E17B() and void f__0070_00E0_0005_E3FB() implemented
10:46:27 <boekabart> warning: implicit declaration of function âf__0070_0080_0005_E27B => that one (and 1 more) missing when linking
10:46:43 <boekabart> f__0070_0108_0005_E45B is the other
10:51:09 <boekabart> really! what was it?
10:51:28 <TrueBrain> oh, 'calls' and 'far jumps' caused a function to be marked as 'called', but interrupts did not
10:51:39 <boekabart> happens to everyone!
10:52:07 <TrueBrain> a typical one-liner
10:52:15 <TrueBrain> I wish glx uploaded his patch on his dev-space ..
11:10:18 <TrueBrain> you got to love them ;)
11:10:30 <boekabart> yes, and switched with an outp
11:10:44 <TrueBrain> problem with this is, that the current code is in no way prepared for that :)
11:10:52 <TrueBrain> it reads the A0000 buffer once in a while, and that is it :p
11:11:11 <TrueBrain> for EGA you need to push data when OUT 3C4 is called :p
11:11:58 <boekabart> so basically hardware wise they point 0xa0000 to a different piece of the 64k video memory?
11:12:29 <TrueBrain> my initial approach btw was to simply map the 0xa0000 to the video memory, so drawing to the screen was very direct
11:12:42 <boekabart> uhhu not for this mode ;)
11:12:45 <TrueBrain> but it turned out to be impossible, as emu_memory is not always paged
11:12:53 <TrueBrain> even for this mode; then on OUT blabla you just change the mapping
11:13:09 <TrueBrain> well, no .. it needs to combine colours
11:13:12 <TrueBrain> you are right, useless :p
11:13:44 <TrueBrain> so yeah, another solution would be that you make a fake piece of memory, and on OUT blabla you copy the last piece of memory to the right place :p
11:13:44 <boekabart> we can do this : on switch-page, memcpy the first 16384 bytes to the 2nd, 3rd, 4th 16k part of 0xa0000 ...
11:14:03 <TrueBrain> that only works if nobody is using the rest of the 0xa0000 :p
11:14:18 <boekabart> I don't think that's allowed
11:14:44 <TrueBrain> 16 colours .. 4 bytes, right?
11:15:13 <TrueBrain> so from A000:0 to A7D0:0
11:15:21 <TrueBrain> that is acceptable I guess ..
11:15:25 <boekabart> dammit, only 2 pages fit
11:15:30 <TrueBrain> no, that is wrong ..
11:15:33 <TrueBrain> I can't do math :'(
11:15:37 <boekabart> a page is 64k right!?
11:16:18 <boekabart> no, just 1 bit per pixel per page
11:16:38 <TrueBrain> so 4 bits per pixel
11:16:57 <TrueBrain> so yeah, 32k in total is required for the EGA mode 0D
11:17:30 <TrueBrain> well, as long as nothing writes up to A7D0:0, you should be fine
11:17:45 <TrueBrain> and up to B000:0 for 0E
11:17:54 <boekabart> so for those modes, we'll assign A400: to red, A800 to green, AC00
11:17:55 <TrueBrain> then you can indeed just memcpy it on port
11:18:23 <TrueBrain> there is no red, green and blue
11:18:26 <TrueBrain> just 16bit palette values :)
11:18:43 <boekabart> so mode 0x0e won't fit
11:19:00 <TrueBrain> depends .. normally nothing touches the memory up to B800
11:19:01 <boekabart> how about a piece of dedicated video memory for our EGA adapter?
11:19:07 <TrueBrain> but that is better I think
11:19:10 <TrueBrain> avoids any and all problems
11:19:22 <boekabart> B000 is hercules area, B800 CGA, right?
11:19:26 <TrueBrain> then on OUT 3C4, you don't just copy it, you put the bits on the right place
11:19:41 <TrueBrain> B000 is rarely used, and even less in combination with another video mode
11:19:48 <boekabart> Why not directly into SDL then ;)
11:19:59 <TrueBrain> dunno .. possible too I guess
11:20:09 <TrueBrain> but that means moving the drawing routine to another place :)
11:20:26 <boekabart> i'll start with dedicated vidmem
11:20:39 <boekabart> 256 k should be enough for anybody, right?
11:20:45 <TrueBrain> and maybe indeed just copy the planes, and combine it in the video routine
11:21:15 <TrueBrain> I wonder what 3C4 does when 3CE is not set to 5
11:22:38 <boekabart> actually FP first writes 3c4, then 3ce
11:23:02 <TrueBrain> well, not wrong from a hardware point of view
11:23:07 <TrueBrain> OUT are just registers, so to say
11:23:19 <TrueBrain> so lets hope nothing else uses 3C4 :p
11:23:29 <boekabart> it's also allowed to write to >1 page at a time, it seems
11:23:51 <TrueBrain> you need at least 153k of mem for all modes
11:24:19 <TrueBrain> so? Uses the same planar method
11:24:34 <TrueBrain> mode 0x12 is just like 0x0D, just on a higher res
11:24:49 <boekabart> yeah, but vga has 256 k ram
11:24:54 <TrueBrain> it is easy enough to combine them all :)
11:25:36 <TrueBrain> mode 0D till 12 only differ in resolution and amount of planars
11:25:38 <boekabart> so on 3C4 write, look at the OLD mode and blit 0xa000 to all selected pages ?
11:26:06 <TrueBrain> on 3C4 write, look at old mode, and memcpy all selected pages, yes
11:26:21 <TrueBrain> lets keep the blitting in the blitting routine for now .. maybe makes it easier ..
11:26:35 <TrueBrain> (it wouldn't suprise me if there is some OUT to copy one plane to the other
11:27:24 <boekabart> that would be a command, don't think the hardware works that way....
11:27:43 <boekabart> I really think that every 'mem write' was caught and fwded to the selected memory block(s)
11:28:02 <TrueBrain> either way, make something pretty :p
11:28:24 <boekabart> I was thinking a dirty hack, but ok
11:28:39 <TrueBrain> well, with this idea, it should be easy enough to make it pretty :p
11:32:27 <TrueBrain> WHOHO, lets add VESA support :p (SVGA)
11:33:22 <TrueBrain> lucky they only get easier ..
11:35:52 <TrueBrain> I am truly suprised how good my decompiler works :)
11:35:55 <TrueBrain> didn't expect that ;)
11:36:51 <boekabart> huh, fp writes B's and W' to 3ce
11:37:38 <TrueBrain> I am very unsure if a B is extended to a W (so that the higher bits are 0), or that it has another function
11:37:42 *** TinoDidriksen has joined #openDune
11:37:58 <boekabart> let me check the values
11:39:17 <TrueBrain> most are dutch here, so no worries :p
11:39:27 <boekabart> outw 0xFF08, outw 0x0005
11:40:31 <boekabart> actually: interesting sequence there: outb 0x3c4, 0x0F02 (all pages), then 0xff08 and 0x0005 to 3ce
11:40:39 <boekabart> sounds command-ish, no?
11:40:58 <TrueBrain> FF08 sounds like: disable 08
11:41:04 <TrueBrain> so .. what does 3CE do exactly
11:41:10 <TrueBrain> besides: set video mode :p
11:41:18 <TrueBrain> 3CE VGA graphics index
11:41:31 <boekabart> another one here: 3c4: 0x0f02 then to 3ce: 0x0005, 0xFF08, 0x0003
11:42:14 <boekabart> last one: 0x0f02 , then to 3ce: 0x0205, 0xff08, 0x0003
11:42:45 <TrueBrain> 3CE also commands 3CF
11:43:25 <boekabart> what , the high byte?
11:43:42 <TrueBrain> no, I meant it switches things for 3CF
11:43:58 <TrueBrain> static void write_p3ce(Bitu port,Bitu val,Bitu iolen) {
11:44:00 <TrueBrain> gfx(index)=val & 0x0f;
11:44:14 <TrueBrain> so the 0x0205 is just 0x05 :p
11:45:24 <TrueBrain> euh, are you sure the 'b' version is used on 3CE?
11:45:51 <TrueBrain> nevermind, I was looking wrong :p
11:46:13 <boekabart> just once on 3c4 it seems
11:46:53 <TrueBrain> good, that reduces complexity :)
11:47:02 <TrueBrain> so, for 3CE ignore all bits but the lower 4
11:47:02 <boekabart> unless I miss an emu_inc(emu_dx) somewhere :)
11:47:44 <TrueBrain> compilers don't work like that
11:47:48 <TrueBrain> so you will never see such code :)
11:48:13 <TrueBrain> either way, 3CE controls the index to read/write to with other 3CN commands, so you can safely do a & 0x0F over it :)
11:48:23 <TrueBrain> this also tells me I can mix the B and W handlers together :)
11:49:24 <TrueBrain> in all cases so far I only see it zero-extend the B version to W
11:49:31 <TrueBrain> and DOSBox even doesn't differ between them
11:50:48 <TrueBrain> fun fact, 3CE only works in DOSBox when you enable the VGA adapter :p
11:51:08 * boekabart tries FP in dosbox.ega
11:53:10 <TrueBrain> means EGA in DOSBox enables the VGA adapter :p
11:53:17 <TrueBrain> damn, I am getting sick :(
11:53:52 <boekabart> 'tis the season to be illy
11:54:10 <TrueBrain> my neighbour has a flu, possible swineflu (given the symptons) .. my other 2 neighbours are getting sick .. and my head is starting to get a bit too hot for my taste :p
11:54:12 <boekabart> had my babyboy tested for h1n1 this morning...
11:55:30 <TrueBrain> and? Or are results not direct?
11:56:29 <TrueBrain> k, modified ToC a bit to not spit out the 'goto <next label>'
11:56:30 <boekabart> so far he just coughs a bit, no fever yet, so we don't worry too much
11:56:33 <TrueBrain> (although the label itself is still there)
11:56:46 <TrueBrain> but you can better check one too many times ;)
11:56:53 <boekabart> and, is it possible to remove unreffed labels in a next pass or so?
11:57:03 <TrueBrain> with hacks, possible
11:57:16 <TrueBrain> but some real restructing should be done to make that happen in a nice way
11:57:30 <boekabart> I think the goto's gone helps a lot 'understanding' the code
11:57:41 <boekabart> easier to find the loops, i guess.
11:57:41 <TrueBrain> basicly it now adds a label for every 'sub function'
11:57:53 <boekabart> Maybe add a comment after a 'jump back'
11:58:21 <boekabart> those are usually more interesting than the forward ones, right?
11:58:25 <TrueBrain> I wish I could easily add a few passes to analyze register content :)
11:58:33 <TrueBrain> they are a bit the same
11:58:41 <TrueBrain> when you look a while at such code, you notice structures immediatly
11:58:45 <TrueBrain> from fors to whiles to if statements
11:58:48 <boekabart> well BACK indicates loops, FWD indicates IFs
11:58:58 <TrueBrain> FWD can also indicate fors
11:59:18 <TrueBrain> a for first jumps to the check part, then jumps to the middle code, then jumps to the begin to do the add (depending on the compiler), then jumps back to the check
11:59:23 <boekabart> well there always has to be a back at some point
11:59:27 <TrueBrain> other compilers have the add part before the check
11:59:43 <TrueBrain> some other pass should detect such instances
11:59:47 <boekabart> _I_ think a comment for a back jump is useful...
11:59:49 <TrueBrain> but the code is too darn ugly for that :(
12:00:20 <TrueBrain> let me first try to remove unused labels
12:00:35 <TrueBrain> the auto-if-creating also doesn't work over a label
12:00:52 <TrueBrain> k, my 'remove useless gotos' fails :p
12:03:38 <TrueBrain> grrr @ boekabart, you make me want to rewrite stuff :p
12:06:05 <TrueBrain> gotos and labels are now fake, what should be done is that a new AST is created for a whole function, in which labels are a node .. then optimizations can work nicely
12:07:04 * boekabart leaves the internals to you - as a good customer/user, i'll just comment smartly about the usability and results :)
12:07:14 <boekabart> i'm NEVER on that side normally!!
12:11:42 <TrueBrain> hmmm .. removing unused labels .. hmm ..
12:11:57 <TrueBrain> layer violations.. how to solve ... hmm ...
12:12:36 <boekabart> lol: *gfx++ = *gfx++;
12:13:03 <boekabart> *gfx = (*data0 >> 7) & 0x01 | (*data1 >> 6) & 0x02 | (*data2 >> 5) & 0x04 | (*data2 >> 4) & 0x08;
12:13:07 <TrueBrain> nope .. which ++ is done sooner? :)
12:13:22 <boekabart> of course, the RHS is evaluated first
12:13:31 <TrueBrain> so it is unreadable ;)
12:13:45 <TrueBrain> always avoid such statements :)
12:13:51 <TrueBrain> your last line, twice data2?
12:15:32 <TrueBrain> argh, no, this attempt to remove labels and stuff is going nowhere
12:16:02 <TrueBrain> pushed a version which removes unneeded gotos, but removing labels is a bitch, as they are fake :p
12:16:32 <DorpsGek> SVN: truebrain (r429) -Update: update decompiled code (remove unneeded goto-statements)
12:18:38 <TrueBrain> oh bah, I really should be doing shopping now, as I think I won't be able in an hour :p Ghehe :)
12:18:42 <boekabart> so do the backjump comment then
12:19:07 <TrueBrain> with all those labels, you see immediatly when it backjumps ;)
12:21:32 <TrueBrain> problem is that there are several kind of 'goto' thingies, and it is tricky in this code to add such check (which is always correct :p)
12:22:01 <boekabart> but indeed, the less-goto's help a LOT
12:22:11 <TrueBrain> oh, yeah, good point :p
12:22:33 <TrueBrain> maybe I will make a draft-design a bit later for a whole new version of ToC (and really do need a better name :p)
12:22:40 <boekabart> btw I limited the screen update timer to 60 fps, isn't that a decent idea?
12:23:06 <TrueBrain> even 30 fps is fine by me, didn't know that would be easy to do :p
12:23:26 <boekabart> set the pic #2 delay to 16000 usec?
12:23:26 <TrueBrain> show me your patches when I am back:p
12:25:02 <TrueBrain> the update runs as often as it can, and _pic_speed can't be changed (as it needs to be as high as possible :p)
12:25:11 <TrueBrain> but make something pretty, and I will review it ;)
12:52:04 <glx> Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 19 bytes) in /var/www/svn.opendune.org/htdocs/comp.php on line 192 <-- nice
12:53:26 <Xaroth> @calc 134217728 / 1024
12:53:35 <Xaroth> @calc 134217728 / (1024 **2)
12:54:55 <Xaroth> yeh, waaaaaay too much diff data
12:55:30 <TrueBrain> glx: and nothing of any interest :p
12:58:38 <Xaroth> heh, even trunk websvn fails when trying to get a too big of a diff
13:03:48 <TrueBrain> but you can removed the Called From
13:03:52 <TrueBrain> they are there for your own reference
13:10:47 <boekabart> TrueBrain: I've read now, that writing W to 3c4 is like outb'ing al to 3c4, and ah to 3c5
13:11:22 <TrueBrain> well, I guess it can't be a real suprise
13:11:34 <TrueBrain> how does that work with inw? :)
13:12:07 <TrueBrain> you don't have a better source to confirm such info?
13:12:55 <glx> MS is supposed to know DOS ;)
13:15:45 <TrueBrain> boekabart: well, I guess you are right about W being that, as 3CE and 3CF are 'paired' in all documentation I can find ..
13:17:47 <TrueBrain> boekabart: so I will fix that in a moment, that a W to 3CE is given as a B.l to 3CE and as a B.h to 3CF
13:17:59 <TrueBrain> first I have a prio of my dayjob, so back in a flash :)
13:18:02 <boekabart> i'd leave it in 1 call
13:18:40 <TrueBrain> or you can give me your work you have so far, then I integrate that first, before doing this ;)
13:19:33 <boekabart> you wait until I'm happy
13:24:29 <TrueBrain> okay sir, I will go sit on the sideline :p
13:24:57 <boekabart> yeah you do that. libemu doesn't accept key input by the way, as long as there is no SDL window, in win32
13:25:09 <TrueBrain> nope .. no ncurses ;)
13:25:32 <boekabart> what's wrong with kbhit(), getch() ?
13:26:05 <TrueBrain> if you want key input in text-mode, move the whole text mode to SDL :P
13:26:35 <boekabart> is that even possible?
13:28:12 <boekabart> i really think it might be better to hook into the get_memory (0xa000) code...
13:28:48 <TrueBrain> I think that is a really bad idea :)
13:29:15 <boekabart> me too, but it's going to be tricky to get it right, otherwise
13:30:50 <boekabart> there really is no good moment to do the memcpy
13:31:04 <boekabart> plus, it should be a memOR it seems...
13:32:56 <TrueBrain> hmm .. I have a good idea, but I need to try it ..
13:33:01 <TrueBrain> can you send me any working patches you have now?
13:34:35 <boekabart> i can send you this:
13:37:25 <TrueBrain> k, need a few minutes to do this daytime job thingy :p
13:37:34 <boekabart> i need a few more minutes on this
13:40:17 <boekabart> ok:3CE reg 8 means: which of the 8 bits of the coming writes will be affected...
13:40:22 <boekabart> hope that's always FF
13:41:34 <TrueBrain> high res for a live broadcast ..
13:54:08 <TrueBrain> commit if you like, looks fine to me
13:58:22 <Xaroth> er, I think he failed because you put 2 commit messages in 1 commit :P
13:58:46 <glx> not a valid reason as it supports that for openttd
14:28:04 <boekabart> 05 mode 0: write to planes (luckily bitmask (8) always FF here, so doable and working ish)
14:28:56 <boekabart> 05 mode 2: write color to pixels (so, on all planes), select 'subpixels' (which of the 8 behind each byte) with option 8, bitmask
14:29:06 <boekabart> that last one sounds very very hard to do
14:29:21 <boekabart> without trapping all the 0xa000 writes
14:34:13 <TrueBrain> Xaroth: next time if you modify a script call .. do it correct :(
14:34:38 <DorpsGek> boekabart: Commit by truelight :: r430 branches/network/console_cmds.c (2004-10-11 17:45:55 UTC)
14:34:39 <DorpsGek> boekabart: -Fix: [New Network] You can now also set the password to nothing ('*')
14:35:05 <glx> lol that's an openttd commit
14:35:15 <TrueBrain> glx: why is DorpsGek stupid?
14:35:18 <Xaroth> TrueBrain: what script call?
14:35:19 <TrueBrain> at best, I would be stupid
14:35:46 <SmatZ> TrueBrain: one would expect OpenDune commits here ;)
14:36:08 <TrueBrain> yes .. so I am stupid to allow @commit to alias to @openttd commit
14:36:15 <SmatZ> "it's not programmer's mistake, just the compiles misunderstood his intentions"
14:36:40 <glx> and there's no @opendune it seems
14:37:05 <DorpsGek> SVN: glx (r430) [LibEMU]
14:37:05 <DorpsGek> SVN: glx (r430) -Fix:
14:37:05 <DorpsGek> SVN: glx (r430) mapping
14:37:05 <DorpsGek> SVN: glx (r430) backspace
14:37:05 <DorpsGek> SVN: glx (r430) [LibEMU]
14:37:05 <DorpsGek> SVN: glx (r430) -Add:
14:37:05 <DorpsGek> SVN: glx (r430) mapping
14:37:05 <DorpsGek> SVN: glx (r430) delete
14:37:05 <DorpsGek> SVN: glx (r430) insert,
14:37:05 <DorpsGek> SVN: glx (r430) pageup
14:37:05 <DorpsGek> SVN: glx (r430) arrows,
14:37:05 <DorpsGek> SVN: glx (r430) home,
14:37:05 <DorpsGek> SVN: glx (r430) end,
14:37:06 <DorpsGek> SVN: glx (r430) pagedown
14:37:09 <SmatZ> TrueBrain: can the behaivour differ on *openttd* channels and *dune* ?
14:37:32 <glx> somebody totally fucked up the script
14:37:43 <TrueBrain> SmatZ / glx: the SVN plugin Supybot is ugly, and I can't copy/paste it to OpenDUNE without modifying tons of things ..
14:37:55 <TrueBrain> so .. very simple, @openttd commit works, @opendune commit never will :p
14:38:00 <SmatZ> TrueBrain: you got da skillz ;)
14:38:04 <DorpsGek> SVN: glx (r430) [LibEMU] -Fix: mapping of delete and backspace
14:38:04 <DorpsGek> SVN: glx (r430) [LibEMU] -Add: mapping for arrows, insert, home, end, pageup and pagedown
14:38:23 <TrueBrain> Xaroth: you removed my: select 1 line, piece of code
14:38:31 <TrueBrain> and replaced it with one that allows multi-lines
14:38:54 <TrueBrain> you can't just send newlines from one script to the other :p
14:39:01 <TrueBrain> either way .. this fix will do I guess ;)
14:39:07 <Xaroth> depends if it's quoted :P
14:39:45 <TrueBrain> boekabart: I personally rather write good things, then 'hoping' it never uses blabla :) Maybe it works for FirePower, but then something else might break :)
14:40:09 <TrueBrain> boekabart: as I said, I have a nice idea to know when to do memcpy and stuff .. keep 4 pointers which point to memory for each plane
14:40:20 <TrueBrain> on change of plane, you copy the memory to the buffer, and change the pointer to there
14:40:29 <TrueBrain> so at 3C4 call, you make the pointer point to the emu_memory
14:40:36 <TrueBrain> that way, when ever you read, you read the right data
14:40:37 <boekabart> what if you select 0x0F as plane?
14:40:47 <TrueBrain> you point all pointers to emu_memory
14:41:01 <TrueBrain> as that is what you request ;)
14:41:11 <TrueBrain> (or none, depends on what F really means :p)
14:41:18 <boekabart> it doesn't quite work like that
14:41:31 <TrueBrain> any OR and AND you need to do, can be fixed by copying back a plane first
14:42:06 <boekabart> that's what i was planing to do,yes
14:42:20 <TrueBrain> that way, you never have the problem of: when to copy
14:42:25 <TrueBrain> and you don't need to know when writes happen ;)
14:42:31 <boekabart> well but it isn't right
14:42:34 <boekabart> if I set mask to 0x0f
14:42:41 <boekabart> it doesn't mean: all are the same
14:42:49 <boekabart> it means, allchanges (writes) apply to all planes
14:43:12 <TrueBrain> so you memset the a000, put all pointers there
14:43:12 <boekabart> so, pointing the plane mem to memory[] doesn't do that
14:43:56 <TrueBrain> well, only writing the value 0 will then fail
14:44:31 <TrueBrain> k, I can see a few corner cases on which that would fail, yes
14:47:29 <TrueBrain> DOSBox indeed solves it by intercepting memory read/writes
14:47:38 <TrueBrain> I was hoping to avoid that in libemu, as it makes things so unmanagable :(
14:47:48 <TrueBrain> then again, EMS/XMS support would need it anyway
14:48:44 <SmatZ> it would be nice if there was POSIX way to manage OS virtual pages
14:51:09 <TrueBrain> I am gone for a while; enjoy :)
15:37:28 <TrueBrain> k ... then you want to go to the handout of the final paper of a good friend .. you enter the building .. you get the reflex to puke, you run back home .. I am in my bed :p
15:47:29 <Xaroth> something smelled fishy?
15:51:19 *** boekabart has left #openDune
15:52:08 <TrueBrain> no, I am that sick .. cold, hot, hot, cold .. somehow that triggers reflexes on sick people :p
19:12:33 <TrueBrain> SmatZ: do you have a good suggestion to do such memory mapping? Where you can capture read/writes on it, but where you also don't slow down the game a lot?
19:58:44 <TrueBrain> yes, that indeed sounds like a solution that in some universe would result in a possible solution
19:59:25 <TrueBrain> naming a storage scheme as solution for data-access-method .. like suggestions a hamburg when someone asks what to drive home in today :p
19:59:33 <TrueBrain> hamburg = hamburger
20:01:02 <Xaroth> just keeping the conversation entertaining
20:01:19 <TrueBrain> s/entertaining/annoying/ :p
20:01:30 <TrueBrain> I mean .. we could also invite PeterT here for the same effect :)
20:04:35 <Xaroth> ah yeh, sesamestreet, etc :P
20:04:44 <Xaroth> it better not be the swine flu :P
21:43:23 <Xaroth> Is it technically possible to 'embed' files in an app and having it available to not just the app itself, but also to an outside app?
22:06:52 <glx> usually when you embed files in an app they are available only to itself
22:08:59 <glx> I know icons embeded in exe are usable outside the app (for shortcuts for example)
22:09:21 <glx> but maybe it's a special mecanism
continue to next day ⏵