IRC logs for #opendune on OFTC at 2009-11-02
⏴ go to previous day
00:11:36 *** ChanServ sets mode: +v glx_
08:46:17 *** boekabart has joined #openDune
10:25:37 <TrueBrain> I am in another attempt to communicate with my team member ..
10:25:43 <TrueBrain> wonder if he will reply today .....
10:29:26 <boekabart> which one of you doesn't have a mobile phone
10:29:43 <TrueBrain> we both do .. but he is just a lazy ass which things everything will work out by just looking at it
10:34:11 <TrueBrain> I will start texting him again at 1200 ...
10:34:32 <boekabart> isn't calling more efficient in such cases?
10:34:43 <TrueBrain> no, as it means I need to talk to him
10:34:48 <TrueBrain> not in the best mood atm to do that :p
10:35:31 <TrueBrain> boekabart: what did you think of my suggestion to make the SDL in layer1, and let other layers use it? In such way that keyboard and stuff can also work?
10:36:45 <boekabart> I'm afraid I haven't read the whole irc-log: haven't touched my laptop the whole weekend
10:36:59 <TrueBrain> no problem, that was the only question related to LibEMU :p
10:37:26 <boekabart> I'm not really sure what it has to do with layers at all
10:37:47 <TrueBrain> well, in layer2 you get VGA, Keyboard, and modules like that
10:37:50 <boekabart> it is a component shared between a lot of layer 2 and even 3 implementations...
10:37:53 <TrueBrain> they need to communicate with a GUI
10:38:04 <TrueBrain> X11, SDL, ... what ever
10:38:17 <boekabart> so define in l1 an abstract IF around those?
10:38:36 <TrueBrain> this avoids problems of polling and stuff
10:38:46 <TrueBrain> well, in theory it is layer 1.5 of course
10:39:19 <boekabart> well it's a helper to layer 2 and above; unrelated to the layers is my gut feeling, but that's a matter of semantics
10:39:31 <boekabart> and taste and so, so lets not go there
10:39:49 <boekabart> but: i think trying to define this IF at this point is too early
10:39:53 <TrueBrain> we have to put it somewhere ;)
10:40:07 <TrueBrain> and it needs to use layer1 (Timer) for Windows
10:40:36 <TrueBrain> SDL needs to be initialized inside the thread used for the timer
10:40:36 <boekabart> I don't think SDL should use hardware
10:40:44 <TrueBrain> else you can't use SDL from the thread
10:40:56 <TrueBrain> so you can like that part or not, but it is not something solvable ;)
10:41:08 <TrueBrain> all hardware also has to be run from that same thread
10:41:10 <TrueBrain> else SDL calls get lost
10:41:35 <boekabart> libemu is constantly being called from 2 threads?
10:41:43 <TrueBrain> the timer is in one thread, the application in the other
10:42:00 <boekabart> but that timer calls also 'decompiled' code?
10:42:19 <TrueBrain> if you press a key, the timer thread sees that and calls int9, which might be decompiled code, yes
10:42:32 <TrueBrain> the threads are in serial btw, only one of the two is running at any given time
10:42:46 <boekabart> ah, so no multithreading issues
10:43:15 <boekabart> in that case, wouldn't it be better to let the main thread execute the INT code ?
10:43:31 <boekabart> just like a real CPU does it ?
10:43:39 <TrueBrain> SDL doesn't like it
10:43:54 <TrueBrain> SDL can only be attached to one (1) thread
10:43:56 <boekabart> my gut says: all decompiled code should run in 1 thread
10:44:04 <TrueBrain> might be, but that is not an option
10:44:07 <boekabart> and of course, the stuff emulating the hardware can be in another
10:44:28 <TrueBrain> my guts tells me a lot, but we have to deal with reality of software :)
10:44:31 <boekabart> (just like real hardware is doing its thing separately from the cpu)
10:45:39 <TrueBrain> you can't poll SDL information from another thread, you want to poll keyboard events and stuff from the timer thread (you can't do it in the application thread), so all SDL stuff has to be in the timer thread
10:45:55 <boekabart> so: SDL key comes in in the SDL/HW thread, sets some value in a register, raises intterupt 9 -> now thread A, the lbemu one, should interrupt processing the normal code, jump to int9 handler, handle, and return to where it broke
10:46:10 <TrueBrain> hahahah, funny guy :)
10:46:19 <TrueBrain> how on earth do you plan to interrupt the process? :)
10:46:27 <boekabart> how does a CPU do it?
10:46:38 <TrueBrain> the same way as Linux allows it
10:46:41 <boekabart> constantly monitor itnerrupt lines?
10:46:41 <TrueBrain> but we are talking Windows here
10:47:03 <TrueBrain> (linux has setitimer, like most OSes have a version of this)
10:47:05 <boekabart> every libemu call could watch the lines, and act accordingly
10:47:16 <TrueBrain> yeah, that is a good overhead :)
10:47:26 <TrueBrain> sorry, code seperation is one thing, killing the speed of your app .. a whole other :)
10:47:36 <TrueBrain> I rather have SDL using layer1 in that case ;) :)
10:47:41 <boekabart> somehow I think the I/O and memory will be the only interface between SDL and main
10:48:01 <boekabart> EVEN if the ints run in another thread, they shouldn't be calling SDL directly ...
10:48:09 <TrueBrain> it is a really annoying problem, but on Windows it is not possible to execute interrupts int he application thread
10:48:29 <boekabart> how does int9 work now on linux?
10:48:40 <TrueBrain> setitimer aborts current thread, jumps to the hardware handlers
10:48:49 <TrueBrain> which executes the decompiled code
10:48:55 <TrueBrain> which returns, and the application continues
10:48:57 <TrueBrain> like on real hardware
10:49:21 <TrueBrain> on Windows you can't hijack threads like that
10:49:37 <boekabart> debuggers can break them ...
10:49:51 <TrueBrain> that is a completely different story :)
10:50:00 <TrueBrain> the application still is in its own thread btw
10:50:31 <TrueBrain> in debugging you suspend the application thread, and read the current code
10:52:33 <TrueBrain> so given that knowledge, the only simple solution is letting SDL launch in the timer thread, and the rest works out just fine (like it does now)
10:52:46 <TrueBrain> it is a small violation of layers, but something we can live with I guess :)
10:53:15 <TrueBrain> then that module can export a 'screen' pointer, which directly writes on the screen (for CGA and VGA modules)
10:53:27 <TrueBrain> it should have some buffer which records keyboard and mouse input
10:56:25 <boekabart> SDl launches in whatever thread the HW emu creates for updates or so?
10:56:38 <TrueBrain> the timer thread, yes
10:57:19 <boekabart> or let SDL do the timer, also?
10:57:33 <boekabart> not fine enough I suppose
10:57:35 <TrueBrain> (read: fails on Windows)
10:57:48 <TrueBrain> it is really stupid that SDL doesn't share itself over threads
10:57:56 <TrueBrain> can't remember .. we tried a lot to get the Windows timer to work
10:58:02 <TrueBrain> this is the only way that works in a stable way
10:58:24 <TrueBrain> oh, I do remember: the same problem: the timer execute couldn't access SDL stuff
10:59:56 <boekabart> SDL timer_proc can't access SDL... nice :)
11:00:11 <TrueBrain> as I said: really annoying
11:01:03 <TrueBrain> sadly enough, we can hear :p
11:01:23 <boekabart> must be a loud alarm then!
11:02:40 <TrueBrain> but okay, knowing all the shit SDL presents, I think SDL in layer1.5 (or layer1) is the only simple solution :p
11:05:45 <boekabart> hm, doesn't give input...
11:06:21 <boekabart> on all platforms, I think there should be a thread for the HW emu, and a thread where the CPU is running. That's just like HW, right?
11:07:22 <TrueBrain> a CPU doesn't have threads :)
11:07:37 <TrueBrain> threads are all fictive
11:07:39 <boekabart> 1 for the CPU, and 1 for each piece of hardware
11:07:59 <TrueBrain> a piece of hardware can have his own PIC (CPU), but that doesn't really count
11:08:04 <TrueBrain> the communication via the CPU is still serial
11:08:29 <boekabart> yes: bus comms serialize the 'threads'
11:08:46 <TrueBrain> either way, the setitimer solution on linux is the best for LibEMU
11:08:51 <TrueBrain> as that does most what hardware does
11:08:59 <boekabart> but still a VGA adapter is doing his own things, changing the thing it does when the cpu writes smth to it
11:09:03 <TrueBrain> interrupt the current application, does what ever he needs to do (including BIOS and DOS shit), then return
11:09:17 <TrueBrain> VGA has his own GPU (or PIC, depending on the age :p)
11:09:55 <TrueBrain> for LibEMU it is of very little use to put that in his own thread .. well .. expect you would be able to make perfect v-syncs :p
11:10:45 <TrueBrain> (I don't like parallel threads, they only cause problems on dualcores :p)
11:10:54 <boekabart> ok so my suggestion would be, what layer1 could offer for hardware, is what you suggest, a way to say 'I want to be called this often'
11:11:01 <boekabart> (not caring about what thread)
11:11:29 <boekabart> (but with the guarantee that all callbacks come in the same thread)
11:12:07 <TrueBrain> I don't think we should use threads (well, for Windows, but that is something that can't be avoided)
11:12:16 <TrueBrain> threads are not cross platform, and every OS has its own problems
11:12:21 <boekabart> and SDL is called/used in those callbacks, by gfx (doing gfx stuff), by keyboard controller (polling SDL events) ...
11:12:50 <boekabart> but SDL as such, isn't smth that needs to be provided by this layer1 functionality
11:13:08 <TrueBrain> so name it layer 1.5
11:13:15 <TrueBrain> it is used by layer 2
11:13:18 <TrueBrain> it has to use layer 1
11:13:24 <TrueBrain> we just established those 2
11:13:39 <TrueBrain> so name it no-layer :)
11:13:40 <boekabart> module_vga_init() { emu_core_register_hw_callback( vga_callback, 1/60 second); }
11:13:51 <TrueBrain> emu_timer_add, but okay :)
11:14:21 <boekabart> right: but this can only be called by HW's, not by decompiled code directly, right?
11:14:43 <TrueBrain> decompiled code will never ever add a timer, simply because they don't do that
11:14:53 <TrueBrain> (they use int1C for that
11:15:00 <boekabart> code calls the PIC/PIT IO ports, and they PIC/PIT implementation uses this
11:15:25 <TrueBrain> the timer is only used by: VGA, Keyboard, Mouse, Sound ...
11:15:31 <TrueBrain> (the reason the timer is in layer1)
11:16:07 <boekabart> I think I was confused, thinking that the timer was the thing emulating the PIT directly
11:16:20 <TrueBrain> the timer only schedules callbacks
11:16:33 <TrueBrain> it does not implement the 8253 (or 8254)
11:16:38 <TrueBrain> that is a layer2 thingy I guess
11:17:12 <boekabart> only important rule is that only the registered timer callback should access stuff like SDL
11:17:38 <TrueBrain> SDL is only reachable via timer callbacks, yes
11:18:07 <boekabart> and that the timer helper fires all callbacks in 1 thread, being either a dedicated timer thread OR the main thread... but not 1 thread per timer/callback
11:18:29 <TrueBrain> given the SDL restriction, there is only 1 thread for the timer
11:18:51 <TrueBrain> and therefor I suggest to put SDL in layer1
11:18:54 <boekabart> (because i think VGA and keyboard/mouse work indepentently, acting on a different emu_timer?)
11:19:12 <boekabart> what do you mean with 'putting SDL'
11:19:19 <TrueBrain> the VGA you want at 1/60th, I would even go to 1/30th
11:19:20 <boekabart> SDL is put in /usr/lib right?
11:19:32 <TrueBrain> the keyboard and mouse run on '0', meaning: when ever you have time
11:19:49 <TrueBrain> it depends highly on your OS where (lib)SDL.(so|dll) is put
11:20:10 <TrueBrain> we need to put the lowest level of SDL interaction somewhere, in a common place
11:20:10 <boekabart> my point being: what 'code' of SDL do you want to put in layer1?
11:20:16 <boekabart> i have no clue what kind of interface
11:20:18 <TrueBrain> the polling, the window creation, ...
11:20:30 <TrueBrain> you can't leave that to the VGA module, to the keyboard module, etc etc
11:20:39 <TrueBrain> they all use events, and you can only poll events in a linear fashion
11:21:09 <TrueBrain> so it is a bit glue between the real video backend, and the layer2 modules
11:21:19 <TrueBrain> with a good enough API, you can even replace it with X11, GDI, OpenGL, ..
11:21:35 <boekabart> ok, agreed on the importance of such an API
11:21:45 <boekabart> so what will it look like
11:21:56 <TrueBrain> and the API for layer2 can be very simple: a pixel buffer (8bpp for now)
11:22:00 <TrueBrain> and an input buffer
11:22:05 <TrueBrain> maybe seperated in mouse and keyboard
11:22:16 <boekabart> keyboard controller implentation can, instead of emu_timer_add, tell interface to give callback on keyboard events?
11:22:54 <boekabart> I think the keyboard controller should do the buffering
11:22:57 <TrueBrain> possible, but I wouldn't do that
11:23:05 <boekabart> l1.5 should offer the up/down events
11:23:15 <TrueBrain> problem is that you complicate the glue a lot
11:23:27 <TrueBrain> if you just queue the events for keyboard and the ones for mouse, you will be fine
11:24:02 <boekabart> well no: see, l2 + l3 need to offer keyboard input in different ways: as a buffer (l3) but also as up.down events -by scancode- on l2 level...
11:24:18 <boekabart> ah: event buffer, not keyboard buffer
11:24:37 <TrueBrain> well .. if any translation, it is to some intermediate format
11:24:42 <TrueBrain> to make sure GDI, SDL, Allegre, ...
11:24:45 <TrueBrain> output the same code
11:24:59 <boekabart> yes, but still in the DOWN+scancode, UP+scancode format (hardward format)
11:25:28 <boekabart> so keyboard ctrl will, instead of call SDL_PollEvent call pietje.pollKeyboardEvent*()
11:25:49 <TrueBrain> yeah, something of the like
11:25:56 <boekabart> sounds really good...
11:26:08 <TrueBrain> window->PollKeyEvent() I guess?
11:26:13 <TrueBrain> and window->PollMouseEvent
11:26:31 <TrueBrain> where you need one (1) backend which supplies 'window'
11:26:57 <TrueBrain> which means in layer1 you get a file like .. euh .. src/layer1/window.h
11:27:00 <TrueBrain> which defines that struct I guess
11:27:07 <boekabart> screen is a bit more complicated.... palette, buffer... and since vga knows what part of screen was changed, could invalidate only separate rects...
11:27:19 <boekabart> need to almost wrap all SDL video calls
11:27:33 <TrueBrain> pixels and 'SetPalette'
11:27:37 <TrueBrain> the only 2 I use now :p
11:27:51 <TrueBrain> for 8bpp it is very cheap to do a full redraw btw
11:27:51 <boekabart> because now you don't know the changed parts of the screen
11:27:57 <TrueBrain> but you can also export Redraw
11:28:18 <boekabart> and location, yes , l1 for the interface
11:28:58 <TrueBrain> now I first work a bit on OpenDUNE :p
11:42:21 <TrueBrain> line 1300 .. and I skipped a few :p
11:44:38 <boekabart> what are you doing, stepping though a fn?
11:45:14 <TrueBrain> rewriting the scenario load function to plain C
11:45:27 <TrueBrain> well .. that not in the first round, at least making it more readable and less depending on libemu :)
11:46:27 <boekabart> hey, a thought... I see some problems when running stuff like VGA in the same thread as main (or with main suspended): what if an APP (digger) is waiting for VTrace
11:47:02 <boekabart> it'd be nice if the VGA could enable the vtrace when not writing the buffer to SDL
11:47:07 <TrueBrain> you know that 'waiting' for a 16bit app is nothing more than looping around an IO port? :)
11:47:11 <boekabart> but now that might cause a deadlock
11:47:32 <boekabart> TrueBrain: I know, that's why...
11:47:44 <TrueBrain> so it never deadlocks
11:47:52 <TrueBrain> the VGA driver is still called every N msec
11:47:54 <boekabart> if vga in its callback Sets, and resets its flags
11:48:11 <boekabart> then the set won't be noticed by def. in the main 'thread'
11:48:30 <TrueBrain> I hope you understand you didn't make sense? :p
11:49:06 <boekabart> rephrase. say the code is waiting for bit 7 of port 343942 to become set
11:49:29 <boekabart> and this is smth that the hardware 'pulls up' only for a short while every 1/60 seconds
11:49:49 <boekabart> implemented as a set + clear in the callback code
11:49:59 <TrueBrain> that is a bug in the hardware, in such case :)
11:50:14 <TrueBrain> it needs to be aware that setting and clearing a flag within the same callback is useless
11:50:14 <boekabart> but might make it very tricky to do it the right way
11:50:25 <TrueBrain> that is why vsync is faked :p
11:50:36 <TrueBrain> once every 8 calls to the IO port gives a positive vsync :p
11:50:54 <boekabart> '''making it tricky to do it the/a right way '''
11:50:58 <TrueBrain> not really, your point was that it could cause deadlocks ;)
11:51:08 <boekabart> well deadlocks in the CODE not the full app
11:51:11 <TrueBrain> well, it is rather simple: say you do the 1/60th call to vga
11:51:26 <TrueBrain> you know on the old hardware a vsync happens every .. I dunno .. 1/30th?
11:51:37 <TrueBrain> so twice in a second you set the vsync
11:51:52 <TrueBrain> of course an app can miss a few of those due to what ever, but it should at least find one in a while
11:51:59 <TrueBrain> what is fake about it? We are EMULATING :)
11:52:09 <TrueBrain> if the specs say we should give a vsync every 50ms
11:52:12 <TrueBrain> and that is happening
11:52:30 <TrueBrain> the true meaniing of a vsync is long long long gone
11:52:33 <TrueBrain> computers are too darn fast
11:52:57 <TrueBrain> you have to keep in mind that we are not making a 100% emulation layer
11:52:59 <boekabart> I guess my point should be: We should only suspend the 'main thread' when calling an app-registered INT handler
11:52:59 <TrueBrain> just one that is good enough ;)
11:53:19 <TrueBrain> the application thread is suspended when the timer thread is working
11:53:44 <TrueBrain> else you get race conditions, and you don't want to go there :)
11:54:14 <TrueBrain> (btw, the vsync trick I stole from DOSBox)
11:54:33 <boekabart> must be perfect then! :D
11:54:43 <TrueBrain> far from; it just show it is sufficient
11:54:49 <TrueBrain> waiting for vsync is silly on modern hardware
11:55:15 <boekabart> still _the_ way to prevent tearing
11:55:23 <TrueBrain> which doesn't happen via libemu :)
11:55:46 <TrueBrain> it MIGHT happen, but somehow it never does :p
11:56:03 <TrueBrain> I do understand you want to be as close to hardware as possible, but we have to put some limits on it
11:56:28 <TrueBrain> I think 'real' vsync emulating (and hsync for that matter) is just too much :)
11:56:30 <boekabart> ok - i agree as long as we can leave it like now, we should
11:56:56 <boekabart> pulling it up once every /60th second is still doable though
11:57:11 <TrueBrain> exactly :) I dunno the real value for normal vsync
11:57:26 <boekabart> if one would register 2 1/60 timers would the code run between the calls to the 2?
11:57:52 <TrueBrain> there is no promise how timers schedule
11:58:19 <TrueBrain> you get 2 promises: if you put in a 1/60 timer, you get 60 calls per second (which can be right behind eachother without the application running, or really once every 1/60th of a second)
11:58:26 <TrueBrain> and they are always triggered in the timer thread
11:58:49 <boekabart> 0.06 ms out of 16.68 :)
11:59:17 <TrueBrain> the timer calculates the delta between last run and this run, and checks how often the scheduled timers should have been running, and calls them that often
11:59:26 <TrueBrain> except for the 0 timers, they are called once
11:59:35 <TrueBrain> (but always when the timer thread is triggered)
11:59:38 <boekabart> TrueBrain: so if the callback takes >= 1/60 second, this is a deadlock
11:59:45 <TrueBrain> nope, never a deadlock
12:00:01 <TrueBrain> all code is protected not to deadlock
12:00:22 <TrueBrain> (the INT1C of Dune2 takes 160ms to run the first time :p)
12:00:29 <boekabart> I've noticed that after breaking the app debugging, on resume it takes very long to get output again
12:00:47 <boekabart> I guess this is caused by this mechanisM?
12:00:49 <TrueBrain> the video runs on (0) :)
12:00:59 <TrueBrain> if you would make that 1/60th, it will be faster :)
12:01:22 <boekabart> 0 meaning? as ofter an.. possible?
12:01:34 <TrueBrain> [12:59] <TrueBrain> except for the 0 timers, they are called once
12:01:35 <TrueBrain> [12:59] <TrueBrain> (but always when the timer thread is triggered)
12:01:46 <TrueBrain> much much much MUCH easier
12:02:02 <TrueBrain> I can explain the 20 lines of code there, or you can read it :p
12:02:41 <TrueBrain> _timer_run is btw called every _timer_speed msec, or as close as the OS could schedule it
12:09:48 <TrueBrain> oeh, there is also a 'Special' field in MAP, which is not yet decompiled ..
12:11:30 <TrueBrain> how can I get in this function with DOSBox .. hmm ..
12:16:25 <boekabart> Isn't this an idea to build into libEMU: on crash (non compiled function), present the option to send the necessary info (crash.bin) to the devs? (by http post or so)
12:16:39 <TrueBrain> would be very useful yes
12:16:44 <TrueBrain> just ... it requires a httplib :p
12:16:55 <TrueBrain> or at least a network lib :(
12:17:10 <TrueBrain> but yes, if you would be able to make that, it would be VERY useful :)
12:17:30 <boekabart> What I use for http in my hybrid STB / windows app might work
12:17:41 <boekabart> supports winsock and the linux ones
12:17:52 <TrueBrain> it is not really difficult perse, but it is work :)
12:18:00 <TrueBrain> DNS resolve, sockets ...
12:18:19 <boekabart> could even hardcode an ip in it
12:18:41 <TrueBrain> hmm .. with all this work on LibEMU, I now don't hve a working JIT to decompile my missing piece of code :(
12:19:12 <boekabart> I used a simple piece of C (not c++) code as basis... googling...
12:19:29 <TrueBrain> via IP it should be relative easy .. crossplatform is more tricky ..
12:19:36 <boekabart> TrueBrain: you can't hg update to a old rev?
12:21:15 <TrueBrain> either way .. clear enough why it isn't done yet, but adding should just be a matter of doing :)
12:21:25 <boekabart> And I thought osx was like unix...
12:21:34 <TrueBrain> from time to time :)
12:22:15 <TrueBrain> hmmmmmm ... for some reasons it now wants to remove functions from the decompiled files .. weird ..
12:22:45 <boekabart> you deleted some txt files?
12:23:04 <DorpsGek> SVN: truebrain (r438) -Add: a few more comments for a few variables
12:23:25 <TrueBrain> no .. it seems I have a bug somewhere, that implemented functions are not analyzed correctly
12:24:23 <TrueBrain> how about first making SDL, VGA, Keyboard, ... work again in LibEMU? :P
12:47:08 <DorpsGek> SVN: truebrain (r439) [JIT] -Add: there is code which handles Special= under [MAP] section, which is never used in normal scenarios
12:58:06 <TrueBrain> hmm .. a Special makes a Bloom like thingy, but it can't be destroyed :p
13:00:25 <boekabart> AKA unlimited spice source?
13:10:02 <TrueBrain> didn't wait long enough to see that :p
13:12:29 <TrueBrain> damn, customers can be stupid, annoying, and did I say stupid?
13:12:38 <TrueBrain> even having my uncle as customer can be ... argh!
13:12:42 <TrueBrain> why do I bother ......
13:12:50 <TrueBrain> waste of time and energy ...
13:13:09 <boekabart> family as customer sucks always
13:13:25 <TrueBrain> I just told my father, that if it was a normal customer we would have had a very nasty talk ...
13:13:35 <TrueBrain> what they are doing is simply unacceptable (there is NO communication)
13:13:40 <TrueBrain> they miss deadlines
13:13:45 <TrueBrain> they change logos in the middle of the process
13:13:59 <TrueBrain> I asked to give me a FULL text of the Contact page, they gave me: yes, something like this
13:14:20 <boekabart> just don't pay them!
13:14:41 <TrueBrain> it is driving me crazy!!
13:18:41 <boekabart> enable ignore mode?
13:18:55 <TrueBrain> the website should have gone live yesterday :p
13:19:05 <TrueBrain> today I received a new logo (always fun), and no content :p
13:19:19 <boekabart> IF they had done what they promised? their problem, I say?
13:19:32 <TrueBrain> now: it is my uncle :p
13:19:35 <boekabart> and your dedicated time is up now, next chance in 2-3 weeks
13:19:41 <boekabart> ah yes, that part...
13:31:27 <TrueBrain> "i ll be around a computer in 2 h" he said at 11:45 ..
13:32:14 <boekabart> well maybe he's AROUND one
13:38:13 <boekabart> DorpsGek: 12 hex? or 12 dec? :)
13:42:21 <boekabart> DorpsGek: You could have said 12 (0x0C), the question was asked in hex...
13:42:30 <boekabart> ... those bots get smarter by the day ...
13:43:00 <boekabart> @calc 0x30124 - 0x8324
13:43:12 <boekabart> DorpsGek: What did I just ask you?
13:44:40 <DorpsGek> mmm there, there, mmm
13:48:14 <glx> @base 10 16 [calc 0x30124 - 0x8324]
13:48:42 <glx> ask clearly and you get what you want :)
13:49:03 <boekabart> DorpsGek behaves like unix, not like windows 7
13:50:01 <boekabart> and when speaking english, he has TrueBrain's accent
13:50:48 <TrueBrain> I think that is an insult to glx, but okay :)
13:51:13 <TrueBrain> (even more for the fact I was away for thelast 10 minutes :p
13:51:46 * glx didn't play with !say today
13:51:47 <boekabart> but he didn't sound french at all....
13:52:52 <TrueBrain> lol, okay, that was a bit unexpected :)
13:57:09 <glx> a local trigger I have translating to /msg DorpsGek say :)
14:20:18 <TrueBrain> 4 hours later, still no feedback
14:27:48 <SmatZ> [11:29:43] <TrueBrain> we both do .. but he is just a lazy ass which things everything will work out by just looking at it <== I know such people, they are always in team with me :-p
14:27:59 <SmatZ> (not always, but sometimes they are)
14:28:46 <SmatZ> it's always better to do things yourself, if you have time ;)
15:00:00 <TrueBrain> yeah .. but I NEED to work together .. it is part of the course, to teach you that (yeah, I never worked together with othe rpeople you know :p)
15:12:11 *** TinoDidriksen has joined #openDune
15:26:40 <TrueBrain> k, first iteration over Scenario shit done ..
15:29:21 <TrueBrain> function is already down to 2000 lines (and 9 functions instead of 1 :p)
15:31:56 <glx> 01F7:28B8:0024:83C9,...emu_Tools_Memmove,...# (count, from_csip, to_csip)
15:31:56 <glx> 01F7:2947:0014:02B8,...emu_Tools_Memset,...# (count, value, csip)
15:32:05 <glx> I think the param order is inverted
15:32:29 <TrueBrain> no idea how that happened ..
15:36:39 <TrueBrain> glx: do you correct and commit that? :)
15:36:56 <glx> yes, and some more variables :)
15:37:43 * glx hopes I'm not in 'your' area
15:37:53 <TrueBrain> I am only working on B4B5 :)
15:38:23 <glx> ok then (I'm in other B4XX ;) )
15:38:36 <glx> but just chasing variables
15:39:07 <DorpsGek> SVN: truebrain (r440) -Add: figured out a few more variables
15:39:13 <TrueBrain> that is all I have :)
15:41:04 <TrueBrain> hmm .. some functions inside B4B5 are only used by B4B5
15:41:10 <TrueBrain> I replace some of them with native C
15:41:23 <TrueBrain> shall I then keep the functions, or can they just be removed?
15:50:33 <TrueBrain> hmm .. this is weird .. when loading the scenario, one of the parameters of which I suspected was % of hitpoints, is read, then dismissed by information from BuildingInfo array ...
15:57:06 <DorpsGek> SVN: glx (r441) -Fix: incorrect param order for emu_Tools_Mem*
15:57:06 <DorpsGek> SVN: glx (r441) -Add: figured out a few variables
15:59:00 <TrueBrain> damn, difference in offset can sometimes be NASTY
16:00:38 <TrueBrain> the initial animation of a structure that is just built .. how do you call that?
16:01:51 <DorpsGek> SVN: glx (r442) -Fix(r441): variable_8076 is not an array
16:03:42 <DorpsGek> SVN: truebrain (r443) -Add: minor discovery about buildings
16:10:11 <TrueBrain> emu_andw(&emu_di, 0xFFF);
16:10:13 <TrueBrain> emu_cmpw(&emu_di, 0x1000);
16:10:14 <TrueBrain> if ((int16)emu_di < (int16)0x1000) goto l__0944;
16:10:16 <TrueBrain> is it me, or is this silly?
16:10:28 <TrueBrain> short written, it says: ((int16)(emu_di & 0xFFF) < 0x1000)
16:10:34 <TrueBrain> which is always true ...
16:12:25 <glx> but dune2 is full of silly things
16:16:40 <TrueBrain> it also compares sometimes things with tile 0 ... no idea why :p
16:18:10 <TrueBrain> ah, no, not tile 0 .. it just checks if anything changed .. :)
16:19:40 <TrueBrain> I wonder why there is a map at 353F:39EA and at 2E9C:323F
16:21:51 <TrueBrain> src/scenario.c:684: error: called object '511' is not a function
16:22:00 <TrueBrain> emu_ax &= 0x1FF <- missing ';'
16:22:46 <TrueBrain> just 500 more lines to go to finish the second iteration .. then everything is commented and stuff .. then I can commit, and start the third which removes a lot of emu_ shit :p
16:22:57 <TrueBrain> but now first .. some rock climbing :)
16:26:14 *** BoekaBart has joined #openDune
18:25:08 *** blathijs_ has joined #openDune
18:50:23 *** blathijs has joined #openDune
20:49:22 *** BoekaBart has joined #openDune
21:21:04 <Xaroth> half of the room is painted.. might need to add another layers to a few panels
21:23:05 <Xaroth> on that note, time to eat some of that cake, brb
22:44:19 <DorpsGek> SVN: truebrain (r444) -Add: named a few more functions (glx)
22:47:38 <TrueBrain> Char/"tiny int" comes on 1B, meaning
22:47:40 <TrueBrain> - Signed values (usually represented in 2's Complement) have a range of -256...255
22:47:41 <TrueBrain> - Unsigned values vary from 0 to 511
22:47:45 <TrueBrain> sometimes I read things on forums, which just BLOWS MY MIND!
22:47:48 <TrueBrain> we reinvented the byte?
22:48:33 <Xaroth> then closed the tab.. simply because it was just tooooooo stupid :/
22:49:03 <BoekaBart> 9 bit isn't even that tiny
22:49:17 <BoekaBart> especially for a byte, that's huge :)
22:49:38 <Xaroth> then going on how they'complement' eachother
22:49:44 <Xaroth> it's called signed and unsigned...
22:50:10 <Xaroth> not to mention that you can't go to 511 with an uint8 :P
22:51:45 <TrueBrain> Xaroth: two complements is a method of calculation
22:51:50 <TrueBrain> (next to one-complements)
22:52:01 <Xaroth> yeh, but he's talking about 1b vars
22:52:08 <Xaroth> 1 byte can't count to 511 :P
22:52:24 <TrueBrain> and 512 is a very logic value, as it is the first value which 'overflows' in such case
22:52:38 <TrueBrain> but okay .. I will look up repair cost, maybe I can give a more likely explanation :p
22:53:38 <TrueBrain> I vote for renaming building to structure .. who is with me? :)
22:54:09 <Xaroth> looks better than Building->Build :)
23:07:09 <TrueBrain> ha, just invented buildings that can't be destroyed ;)
23:16:59 <TrueBrain> did you know that repairing goes slower after campaign 3?
23:32:21 <TrueBrain> hmm .. tricky function.. lets think out loud:
23:32:34 <TrueBrain> 2 values .. the hp of the building and value '2'
23:32:49 <TrueBrain> the hp is put in a 32bit value, and shifted to the left with 8
23:33:25 <TrueBrain> if value < 256 (so original < 16), then it is divided by the '2', and given as result
23:33:50 <TrueBrain> so 2, becomes 32, becomes 16 as answer ...
23:34:10 <TrueBrain> so 4, becomes 128, becomes 64 as answer ...
23:34:35 <TrueBrain> NO idea what that value means :p
23:35:48 <TrueBrain> euh, shift of 4 btw, not 8
23:36:04 <TrueBrain> no, 16 .. lol .. so my math is a bit wrong somewhere ..
23:36:26 <TrueBrain> 2 comes in .. multiplied with 256, so 512 .. divided by 2, so 256, yes, that makes more sense
23:36:49 <TrueBrain> 4 comes in .. multiplied with 256, so 2048 .. divided by 2, so 1024 ... hmm .. not what I expected
23:37:03 <TrueBrain> oh, maybe I should not mix up the parameter-order ...
23:38:27 <TrueBrain> ah, yes, the hp is not multiplied with 256, but the '2' value ie
23:41:27 <DorpsGek> TrueBrain: 1.43016759777
23:41:32 <DorpsGek> TrueBrain: 0.69921875
23:41:52 <TrueBrain> ah, so it is a 32bit divide with the value multiplied by 256
23:46:30 <TrueBrain> @calc 2 / 1000 * 256
23:52:42 <TrueBrain> "PS: I like to take this opportunity to underline it has absolutely nothing to do with signed values. All values are unsigned in this question."
23:52:45 <TrueBrain> hihi, I had to reply like that :)
23:56:18 <TrueBrain> @calc 2 / 400 * 256
23:56:20 <TrueBrain> @calc 2 / 500 * 256
23:56:36 <TrueBrain> @calc 2 / 256 * 256
23:57:53 * glx is trying to find an indication for some buffer sizes, like 0x9882, 0x9939, 0x998E
23:58:00 <TrueBrain> very unfair method of calculating what you have to pay for repair is used ...
23:58:07 <TrueBrain> always the hard job ;)
23:58:32 <TrueBrain> "PPS: this method used is _very_ unfair. A strucuture with 257hp cost as much to repair for the same amount of damage as a structure of 512hp (if they would have cost the same price)."
23:58:39 <glx> for now I have 0x5F, 0x51 and 0x61
23:58:56 <glx> ie free space before next variable ;)
23:59:33 <TrueBrain> for scenario I had a variable I had to look VERY closely at where it was ...
23:59:39 <glx> sprintf uses an internal 0x50 buffer IIRC
continue to next day ⏵