IRC logs for #opendune on OFTC at 2011-04-22
⏴ go to previous day
06:59:54 *** Alberth has joined #openDune
10:20:09 <Xaroth|Work> ! Alberth lives :P
10:21:22 <Alberth> I got distracted by some openttd troubles :)
10:22:58 <Xaroth|Work> <3 for the patches :)
10:26:04 <TrueBrain> can't you use memmove for emu_Tools_Memcopy?
10:27:19 <TrueBrain> think it is safe to move the progres = 0 outside the loop :D
10:28:19 <Xaroth|Work> TrueBrain: bug 43, I think that is an emulation issue?
10:28:25 <Xaroth|Work> well, not really an issue
10:29:33 <TrueBrain> #63 is still wayyyyy to raw
10:30:29 <TrueBrain> but I guess that is native to the WSA bla ...
10:30:41 <TrueBrain> Alberth: can you make #61 and #63, so that the C part is not in emu_ ?
10:30:47 <TrueBrain> and keep the emu_ function only as wrapper?
10:31:42 <TrueBrain> we atm have some functions where C is in the emu_ wrappers, but it is a real bitch later on, as it turns out now ... so it would be much better if that was splitted, into a part that handled the reading and converting to the emu-world, and the part that executes the real function :)
10:33:27 <Alberth> that should be doable :)
10:36:40 <TrueBrain> hmm, those things ...
10:36:48 <TrueBrain> be _very_ careful with mouse shit .. I tried to convert it once
10:36:51 <TrueBrain> the game was unplayable :p
10:37:40 <Alberth> you created a 0.4 branch, right? :)
10:37:42 <TrueBrain> but yeah, Alberth, even there, please split it in emu_ and C :)
10:37:48 <TrueBrain> not yet, not yet ...
10:40:47 <Alberth> yeah, one too many patches in the queue :(
10:46:01 <Alberth> C function and emu_ function can be in the same file?
10:48:42 <Alberth> hmm, stupid tracker, why can I not add a note while uploading a new version?
10:49:06 <TrueBrain> no, C function and emu_ are split
10:49:47 <TrueBrain> the only huge exception is WSA atm, but that is because there were some serious problems there :D Hope I can fix that soon, with your patch, as I think that is the last WSA usage :p
10:51:52 <Alberth> ah, now I understand why I added that extra patch in the queue, it needs the previous patch :)
11:04:32 <Alberth> I get new warnings from the new gcc :)
11:37:45 <Alberth> #64, f__24D0_000D_3.patch split into C and emu_ now
11:42:10 <Alberth> (12:27:15) TrueBrain: + progress = 0x0; <-- I disagree, I think the purpose is that you want to detect whether some data[i] got changed in the loop
11:45:56 <TrueBrain> do { progres = 0; (..) } while (progress == 0), was the loop, not?
11:48:46 <Alberth> Mine has "while(progress != 0);"
11:49:01 <TrueBrain> owh, then I misread :)
11:49:06 <TrueBrain> so they used inverse logic ... meh
11:49:17 <TrueBrain> something to rewrite I guess; but okay, nevermind then :)
11:49:21 <Alberth> do .. while() has inverse logic :)
11:54:39 <Alberth> void emu_Unknown_259E_00B1() <-- where should I put the C variant of that? src/unknown only has 'emu_XXXX.c' files
11:56:12 <TrueBrain> true; I believe they have their C function in there
11:56:27 <TrueBrain> no clue why tbh, but yaeh, go with that ...
11:56:48 <TrueBrain> as long as they are splitted ... for unknowns I guess that is sufficient ..
11:57:23 <TrueBrain> I don't always like how we solved things, but I am also too lazy to fix things :D
12:06:08 <Alberth> sure splitting is a good idea with 259E_00B1? the emulated local array "uint8 data[0x300]" will make a huge mess (additional parameter, not callable from non-emu funcs)
12:07:08 <TrueBrain> you can just still use the emu_sp trick for all I care :p
12:07:26 <TrueBrain> it is just about getting the parameters reading away from it, so callers of that function can remove their emu_ stuff
12:08:15 <TrueBrain> so basically, between those two lines:
12:08:16 <TrueBrain> + unknown = (int16)emu_get_memory16(emu_ss, emu_sp, 8);
12:08:19 <TrueBrain> + ptr2data = emu_get_memorycsip(ptr2);
12:08:22 <TrueBrain> add a function header, and done :p
12:09:49 <TrueBrain> with the only intend that you can convert functions using this function easier :)
12:15:12 <TrueBrain> Xaroth|Work: suggestions what to do with release cycle? I can't apply Alberth's patches, as we want a (semi)stable release .. but all known bugs are handled, and the game appears to be as stable as it can be ..
12:15:16 <TrueBrain> so we an just release now
12:16:34 <Alberth> unfortunately you cannot blame April 1st for releasing early :)
12:16:43 <TrueBrain> we are not OpenTTD :p
12:19:15 <Xaroth|Work> or we can just apply the patch
12:19:32 <Alberth> Xaroth|Work: I would not recommend that :)
12:19:39 <TrueBrain> Xaroth|Work: if that makes the release unstable .....
12:19:43 <Xaroth|Work> not -that- confident of your work, Alberth? :P
12:19:47 <TrueBrain> it mostly takes a week or something before people report problems
12:19:48 <Xaroth|Work> TrueBrain: branch
12:19:57 <TrueBrain> well, a branch seems so useless
12:20:03 <TrueBrain> what do you expect that the coming week gives you?
12:20:08 <TrueBrain> any bug report of any form?
12:20:31 <TrueBrain> question for you too glx:
12:20:34 <Xaroth|Work> but releasing early is.. well.. meh :p
12:20:41 <TrueBrain> [14:15] <TrueBrain> Xaroth|Work: suggestions what to do with release cycle? I can't apply Alberth's patches, as we want a (semi)stable release .. but all known bugs are handled, and the game appears to be as stable as it can be ..
12:20:43 <TrueBrain> [14:15] <TrueBrain> so we an just release now
12:20:44 <TrueBrain> [14:15] <TrueBrain> or we can branch
12:21:19 <glx> releasing may help to get new bugs
12:22:16 <glx> <@Xaroth|Work> but releasing early is.. well.. meh :p <-- we're very far from the initial planning ;)
12:22:25 <Alberth> no need to commit by me any more, I mostly stopped as 5 patches floating around in the channel did not work, npow I can drop them in the tracker
12:22:25 <TrueBrain> all my tests work, I can play the game fine, and OSX compiles too ...
12:22:38 <Xaroth|Work> but at least get the 4 non-ack'ed and non-feature items in the bugtracker dealt with :P
12:22:47 <Xaroth|Work> and non-patch ones
12:22:51 <TrueBrain> Xaroth|Work: name one?
12:22:58 <Xaroth|Work> 40, 41, 43 and 56
12:23:20 <TrueBrain> owh, those first 3 are handled
12:23:27 <Xaroth|Work> they still show as new :)
12:23:35 <TrueBrain> because there is no status for them
12:23:50 <glx> and 56 is probably due to libemu
12:24:00 <Alberth> if you just mark them as 'ready for commit' would be fine
12:24:36 <Xaroth|Work> I'll add a category for the ready for commit stuff
12:25:22 <glx> 44.1 is "fixed" (wrong libemu version), 44.2 is usual freezes
12:25:54 <Alberth> Xaroth|Work: I would just want to know what is finished, a simple comment would suffice
12:26:03 <TrueBrain> I have no problem closing bugs etc, if it annoys Xaroth|Work :D
12:26:32 <Xaroth|Work> well if you want to release early because there are no more known bugs, and there are open bugs in the bugtracker
12:26:36 <Xaroth|Work> something is off :P
12:26:44 <TrueBrain> those bugs were there before 0.2
12:26:53 <TrueBrain> in that idea, we can never release :p
12:27:10 <glx> and all freezes are caused by libemu
12:27:24 <Xaroth|Work> right, i see nothing that can block early release anymore :)
12:27:42 <TrueBrain> 'early' as in: 1 week before planned, while there is nothing we would do in that week :p
12:28:26 <Xaroth|Work> well the idea behind it was solid, we just knew it wouldn't work like that until 0.something
12:30:29 <TrueBrain> happy now Xaroth|Work? :)
12:30:56 <TrueBrain> anyone else has problems with us releasing now? :)
12:31:29 <TrueBrain> guess I need to remember how we did it ...
12:33:40 <glx> I know I must use debug libemu
12:34:01 <DorpsGek> SVN: truebrain (r1472) -Add: prepare for 0.4 release
12:34:58 <TrueBrain> lol, I get authorization failure :D
12:35:43 <TrueBrain> svn copy svn://svn.opendune.org/trunk svn://svn.opendune.org/tags/0.4
12:36:04 <DorpsGek> SVN: truebrain (r1473) -Release: 0.4
12:36:27 <DorpsGek> SVN: truebrain (r1474) -Add: bump version for trunk
12:36:35 <TrueBrain> glx: can you compile 0.4 for me?
12:39:01 <TrueBrain> hmm .. I wonder if I have the correct dune.cfg now .. hm ..
12:39:04 * TrueBrain makes a clean checkout
12:39:20 <Alberth> #61 is broken, it seems :(
12:39:34 <TrueBrain> the reason we don't include it in 0.4 :D
12:39:48 <glx> Avertissement 3 warning C4700: variable locale 'currentRow' non initialisée utilisée d:\developpement\opendune\0.4\src\map.c 1794
12:40:14 <TrueBrain> how did that happen?
12:41:17 <TrueBrain> valid, but not important to us
12:41:55 <TrueBrain> with j == 0, previousMap is never used, so what-ever garbage is on the stack, it is never read
12:41:59 <TrueBrain> but yeah, it needs a memset :)
12:42:08 <TrueBrain> please fix for 0.5, but lets continue release :)
12:43:54 <glx> ha trunk debug doesn't warn
12:44:37 <TrueBrain> to strip or not to strip?
12:45:21 <TrueBrain> saves so much space ...
12:45:34 <glx> now time to remember what to put in the zip
12:45:43 <TrueBrain> but also loses debug information
12:45:47 <glx> or I just give you the exe
12:46:07 <TrueBrain> I have scripts to fix the rest
12:48:05 <TrueBrain> mpu_als is giving me a hard time in static compile ...
12:48:16 <TrueBrain> tons of: /prog/opendune/libemu/src/mpu_alsa.c:136: undefined reference to `snd_midi_event_reset_encode'
12:51:43 <TrueBrain> no SDL.dll updates glx?
12:51:47 <TrueBrain> (can I copy the 0.3 one?)
12:52:32 <TrueBrain> now I need to figure out why I don't have 32bit libs for mpu ..
12:54:51 <TrueBrain> oops, the 0.3 source contains my .svn files ...
12:54:59 <TrueBrain> that is a bit bad :D
12:55:15 <TrueBrain> I should remove them ..
12:55:26 <glx> you did the same last time IIRC
12:55:37 <TrueBrain> but I don't hink I corrected it or something ...
12:57:50 <glx> oh I have SDL 1.2.14.0 dll but I compiled with 1.2.13 ;)
12:59:07 <glx> but SDL dll version is not that important (not like ICU ;) )
12:59:27 <glx> we use very common SDL stuff
13:01:25 <TrueBrain> corrected 0.3 source files ..
13:01:28 <TrueBrain> now ... 32bit linux ... hmm ...
13:02:33 <TrueBrain> weird that 64bit did work ..
13:04:17 <TrueBrain> Alberth: you run linux?
13:04:38 <TrueBrain> (don't forget the data folder!)
13:08:44 <TrueBrain> (for the binary and everything :))
13:09:41 <TrueBrain> Xaroth|Work: I updated mantis to include 0.5. Was there anything else?
13:09:51 <TrueBrain> and would you mind writing a nice story on the frontpage for the release?
13:14:47 <TrueBrain> (mostly as I have no clue how to login :D)
13:24:10 <Alberth> zsh: floating point exception (core dumped) ./opendune except the core dump disappeared :(
13:24:59 <planetmaker> seems fine, TrueBrain
13:28:02 <Alberth> no, after selecting a house
13:28:23 <Alberth> I have installed more sdl stuff, and are retrying
13:28:35 <TrueBrain> else, run gdb over it
13:29:00 <Alberth> but now I also have sound during the intro
13:30:22 <TrueBrain> meh; runs fine here. But it has a huge list as deps ... bit sad :(
13:30:23 <Alberth> 32 bit works, but I did not have sound, most likely because I am missing some stuff somewhere
13:31:14 <Alberth> amd 64 bit works here too now
13:32:48 <Alberth> 32 bit finds midi: "Found MIDI output: Midi Through Port-0" :)
13:40:29 <planetmaker> the constant sound can even be annoying ;-) "harkonnen unit destroyed" "Atreides unit approaching" "Base under attack" "Vehicle Repaired" "Orders confirmed" bla blah ;-)
13:40:40 <planetmaker> I wonder if I ever played it with sounds enabled ;-)
13:42:41 <Alberth> the sound causes the whole application do stop for a while
13:44:44 <Alberth> especially placing a concrete slab is nasty here
14:13:36 <TrueBrain> it is far from perfect, yeah
14:13:40 <TrueBrain> I dislike playing with it
14:14:56 <Alberth> I had a CPU load running, and the load drops to 0 for some time, it seems that it is waiting for something
14:15:10 <TrueBrain> syncing with sound and game, yes
14:15:17 <TrueBrain> but that is not really done in an efficient way :(
14:15:33 <Alberth> interestingly, if you give units an order, it keeps working without problems
14:29:44 <glx> <Alberth> 32 bit finds midi: "Found MIDI output: Midi Through Port-0" :)
14:30:37 <glx> yeah sound is handled via IRQ in libemu
14:31:19 <Xaroth|Work> heh at 'almost' :P
14:31:37 <glx> it rarely starts on windows
14:32:09 <Alberth> we 'just' need to do a bit more conversion :)
14:32:49 <glx> yeah for now I just the decompiled driver and implemented required stuff in libemu
14:33:48 <glx> ans IIRC there are sync with video in audio
14:34:22 <Xaroth|Work> well 'back in the day' they were innovative
14:34:34 <Xaroth|Work> most of their ingame cinematics is proper lip sync
14:34:40 <glx> anyway it seems win32 release works, as I see no complaints
14:35:17 <glx> <@Xaroth|Work> most of their ingame cinematics is proper lip sync <-- natively yes, via libemu some text of the emperor is repeated in the intro :)
14:35:45 <Alberth> sound in linux is always a bit of a problem
14:35:49 <glx> there are no rules of engagment and no set territories and no set territories
14:36:17 <Alberth> he is just making sure you get that part :)
14:36:44 <glx> it's just the sound played faster than the video
14:37:47 <glx> timing issues due to libemu (as always)
14:38:27 <TrueBrain> I didn;t feel timing simulation would be a good thing ;)
14:39:06 <glx> anyway for a game running in a while (true) without sleep()
14:44:19 <TrueBrain> glx: lol; I would have done a memset :D
14:44:22 <TrueBrain> but this works too, yes
14:44:57 <glx> I'll use a memset, seems cleaner and future proof
14:50:17 <DorpsGek> SVN: glx (r1475) -Fix (r1356): possible use of an uninitialised variable (didn't happen but better safe than sorry)
14:50:52 <glx> well it happened but was harmless
20:33:07 *** TrueBrain has joined #openDune
21:12:56 *** DorpsGek sets mode: +o TrueBrain
21:13:06 *** DorpsGek sets mode: -o TrueBrain
continue to next day ⏵