IRC logs for #opendune on OFTC at 2011-08-03
⏴ go to previous day
00:00:09 <TrueBrain> mostly, I see subtitles, which gives me the idea it failed :D
00:00:56 <TrueBrain> I use subversion one
00:01:14 <TrueBrain> I just tripple checked that :P
00:01:20 <TrueBrain> it did work this morning ... ffs
00:01:52 <glx> anything in the notification zone ?
00:03:05 <glx> maybe not related to opendune
00:03:15 <TrueBrain> I use it a lot during the day :)
00:03:41 <TrueBrain> sounds inits with index 7
00:04:31 <glx> well it could but we don't check it
00:04:47 <TrueBrain> nothing in error log
00:04:51 <TrueBrain> so midiOutOpen succeeds
00:05:34 <TrueBrain> at least, pointer is valid etc
00:06:35 <glx> so you should have a mixer in the notification sone
00:10:18 <TrueBrain> it is just mean to me :(
00:10:58 <glx> hmm I disabled music and sound in game config
00:11:21 <glx> but no voice and no text either
00:12:24 <glx> that can explain the no music problem
00:12:35 <glx> but not the voice failure to start
00:12:54 <TrueBrain> my sounds was bit too loud
00:13:10 <TrueBrain> okay ... problem was: ingame settings, had sound/music disabled
00:13:15 <glx> ha you saw it move in the mixer ?
00:13:33 <TrueBrain> voices still don't work
00:14:29 <TrueBrain> it goes in with index 1
00:14:31 <TrueBrain> comes out with index 0
00:15:34 <glx> you have MSVC :) put break points in DSP_Init to see when it fails
00:15:42 <TrueBrain> SDL_GetAudioStatus fails
00:16:36 <TrueBrain> works if I remove that line
00:16:48 <glx> it's 2 for me when init works
00:17:17 <glx> I mean the return value ;)
00:17:27 <TrueBrain> yeah, 0 here obvious
00:17:30 <TrueBrain> as .. well .. it fails :P
00:18:55 <glx> DSP_SetTimeConst() should have call SDL_AudioOpen() which goes paused, and status should be 2 in this case
00:19:39 <TrueBrain> SDL_OpenAudio returns -1
00:20:11 <glx> but nothing changed in this area IIRC
00:21:55 <TrueBrain> 251 is the first value which works
00:22:19 <TrueBrain> I guess with 252+ the delay is too high for it
00:22:48 <TrueBrain> so any value between 0 and 251 is fine
00:23:53 <DorpsGek> SVN: truebrain (r2291) -Fix: my Windows doesn't like long delays in MIDI, so lets use a very short to test if MIDI works. And yes, me, Windows? Me MSVC? Scary shit ..
00:23:56 <TrueBrain> had to do that commit :D
00:24:08 <TrueBrain> tested it on linux that it still failed ;)
00:24:21 <glx> anyway it will close and reopen on first voice file
00:24:58 <TrueBrain> so there ... OpenDUNE is now officially a working project
00:25:04 <TrueBrain> now everyone can make their insane patches
00:25:32 <glx> hmm maybe linux doesn't like dune2 freq
00:25:34 <TrueBrain> still a lot to do, cleanup wise
00:26:04 <TrueBrain> soon I will diff the VOCs MrFlibble made and original has
00:26:08 <TrueBrain> see if I can find anything
00:26:30 <TrueBrain> voices work really well now
00:26:32 <glx> on linux try fixing the freq to 11025, 22050 or 44100
00:26:33 <TrueBrain> very well times here
00:26:42 <TrueBrain> I have no audio on linux
00:26:47 <TrueBrain> ALSA can't find card 0 :p
00:27:06 <TrueBrain> totally unrelated to OpenDUNE :)
00:28:12 <TrueBrain> so yeah, now it is a matter of naming functions, removing layers (input), moving updaterect etc levels higher
00:28:20 <TrueBrain> implement Windows GDI :P
00:28:35 <TrueBrain> I suggest we also make a better config file
00:28:56 <TrueBrain> I am still in doubt if we shoul go the TTDp way, by having switching for additional stuff
00:29:10 <TrueBrain> hmm .. we can do some in the ini I guess
00:29:18 <TrueBrain> but TTDp is such a farm of settings
00:29:30 <TrueBrain> but yeah, an ini file as config where we can put stuff would be nice
00:29:36 <TrueBrain> a configure would be nice too
00:29:59 <TrueBrain> music/driver/sound should go in a sound dir
00:30:14 <TrueBrain> dsp.c should be dsp_sdl.c
00:30:51 <glx> I'll change mpu_init to do the same as voices
00:31:05 <glx> ie disable driver on failure to init
00:31:34 <TrueBrain> we did enough for today
00:31:36 <TrueBrain> really nice work :)
00:31:43 <TrueBrain> I am off to bed; night :)
07:43:39 *** Alberth has joined #openDune
07:43:39 *** ChanServ sets mode: +o Alberth
07:48:03 <Alberth> TrueBrain: you forgot to copy all the comments out of g_global, it seems
10:14:49 <TrueBrain> all of them, yes :P
10:24:33 <TrueBrain> but yeah, concratz to you too Alberth, finally we are ride of libemu, and we can now normally start doing stuff, in a decent matter :D
10:24:48 <TrueBrain> sadly, still a lot to do, but at least it now feels managable :)
10:25:33 <Alberth> and congratulations back of course, you did a marvelous job on the malloc and wsa stuff, and probably much more I don't even know :)
10:26:01 <TrueBrain> the left leg needs the right to walk ;)
10:27:26 <TrueBrain> I am just so happy we can now jus tnormally modify the code :)
10:27:54 <TrueBrain> think I will spend a bit in a moment moving files around, although I really do not want to :P
10:28:58 <TrueBrain> as then again, variables are all over the place
10:29:19 <TrueBrain> yesterday at a point I just added them to the first file I had open, as I really wanted it done more than doing it all nice and shiny
10:29:24 <TrueBrain> some vars are confusing :P
10:32:23 <Alberth> so today you pay the bill for doing that ;)
10:33:19 <TrueBrain> not really :pTons of functions are in the wrong place too ...
10:33:23 <TrueBrain> no real surprise :)
10:33:28 <TrueBrain> and we still have 2 unknown files :p
10:33:49 <TrueBrain> but! libemu is gone, voices work pretty well and pretty stable (at least on Windows :p)
12:04:37 <Alberth> hello, and congratulations to you too
12:06:10 <planetmaker> oh... libemu is gone? Congratz, folks. Good job :-)
12:24:06 <glx> need a linux compile check ;)
12:24:48 <TrueBrain> compiles, runs, segfaults :P
12:24:52 <Alberth> it also needs some doxygen comments :)
12:26:29 <TrueBrain> well, indirectly of course
12:26:33 <TrueBrain> as the buffers are never allocated
12:26:58 <glx> you compiled without alsa ?
12:27:15 <TrueBrain> Driver_Sound_Play is called, which doesn't fail
12:28:04 <TrueBrain> it checks g_gameConfig.sounds
12:28:11 <TrueBrain> it should also check g_config.soundDrv
12:29:18 <glx> (check init before allocating drivers)
12:30:08 <TrueBrain> Driver_Music_Play is still called
12:31:17 <TrueBrain> why not test this yourself, by using mpu_none?
12:31:17 <glx> ok I reproduce it easily (forced driver failure ;) )
12:31:38 <TrueBrain> btw, update your SVN :P
12:32:21 <TrueBrain> then why do I get a fuzzy ..
12:35:19 <glx> oh driver->index is never 0xFFFF
12:36:44 <glx> hmm better merge sound and music first
12:42:05 <TrueBrain> doesn't crash and compiles
12:42:40 <glx> with correct driver->index it's ok ;)
12:46:59 <TrueBrain> seems the pathfinder prefers going to the end point via a direct route where possible, ignoring the landscape type
12:47:09 <TrueBrain> but it has the ability to use the landscape type to find faster routes or something
12:48:11 <TrueBrain> euh ... atm we have Script_Unit_<name> for both static functions and callable functions
12:48:17 <TrueBrain> I Somehow find that a bit hard to differentiate
12:48:24 <TrueBrain> suggestions for naming to differ between the two?
12:48:35 <TrueBrain> well, there are not that many
12:48:39 <TrueBrain> seems they are all related to pathfinding
12:48:51 <TrueBrain> so Script_Unit_Pathfind_name or something will do
12:48:59 <TrueBrain> maybe I put it in a different file
13:05:19 <DorpsGek> SVN: glx (r2292) -Add: detect sound/music problems at init
13:06:13 <TrueBrain> I am trying to understand this pathfinder, but it has some weird shit
13:06:43 <TrueBrain> it feels like it is converted wrong or something :p It is that weird :)
13:07:26 <glx> that explains why it can't find some paths ?
13:07:42 <TrueBrain> you have a start and end tile
13:07:46 <TrueBrain> it starts at the start (duh)
13:07:57 <TrueBrain> it finds the direction of the end tile, and moves 1 tile towards it
13:07:59 <glx> like when you move to (-1, -1) and it doesn't ?
13:08:04 <TrueBrain> if you can access it, it adds it to the list
13:08:13 <TrueBrain> and this is repeated
13:08:20 <TrueBrain> so if there is a direct route, nothing fancy happens
13:08:33 <TrueBrain> when at any point it cannot find this route, it does the following:
13:08:44 <TrueBrain> it keeps walking the line till it finds a tile it can access
13:08:55 <TrueBrain> then it backtraces from there back to the tile where you lost the track
13:08:58 <TrueBrain> and it tries to connect the two
13:09:17 <TrueBrain> if it does, it adds that route, and it continues from that point
13:09:23 <TrueBrain> so far, the algorithm makes perfect sense
13:09:33 <TrueBrain> the weird stuff happens next
13:09:40 <TrueBrain> in case it cannot connect the two positions
13:09:53 <TrueBrain> it sees if the new position connects via a direct path to the end position
13:10:10 <TrueBrain> if it does, it drops out most of the loops, and it ends
13:10:35 <glx> it often fails with no reason for me ;)
13:10:57 <TrueBrain> so if it cannot connect the two points, it just bails
13:11:11 <glx> when I can see there is a path
13:11:30 <TrueBrain> well, maybe that does make sense, if you can't connect those two points, all is lost, so give up I guess
13:11:37 <TrueBrain> but then why does it still try to connect the rest, I don't get
13:12:16 <TrueBrain> no, that part makes no sense :P
13:12:23 <TrueBrain> it just leaves a gap in the route then
13:23:18 <TrueBrain> ugh, it is more close to dead-mans-walk what it does
13:23:58 <TrueBrain> Dijkstra already wrote down his algorithms in 1991, not?
13:24:20 <TrueBrain> (I am joking, as he did in the 50s :p)
13:25:47 <glx> but indeed dune2 goes in line without trying to go around obstacles
13:25:57 <TrueBrain> okay, what this subalgorithm does:
13:26:03 <TrueBrain> it knows these two points it wants to connect
13:26:15 <TrueBrain> it starts at the one you can reach for sure
13:26:24 <TrueBrain> then it does the algorithm twice
13:26:32 <TrueBrain> one time it looks clockwise, the other time counterclockwise
13:27:05 <TrueBrain> so say it was going up, and it lost the track there
13:27:09 <TrueBrain> then 5 tiles later it finds it again
13:27:24 <TrueBrain> now it first looks top-right
13:27:28 <TrueBrain> then right, etc of the tile
13:27:31 <TrueBrain> see if the tile is free
13:27:40 <TrueBrain> if so, it goes there
13:28:10 <TrueBrain> it goes 3 directions back, then search again from the tile
13:28:13 <Alberth> dijkstra is no good for seas of sand
13:28:23 <TrueBrain> and it tries to find it like that ...
13:28:43 <Alberth> no, see ship path finding in OpenTTD :p
13:28:59 <TrueBrain> Alberth: that has to do that OpenTTD want to be perfect :)
13:29:16 <TrueBrain> see my A* shit in NewAI pathfinding
13:29:29 <TrueBrain> it looked for a path over 2048x2048 maps :p
13:29:38 <TrueBrain> well, I think more a problem of OpenTTD is that the path is not stored
13:29:46 <TrueBrain> so searching with A* on sea every tick, is maybe a bit much :P
13:29:57 <TrueBrain> Dune2, surprisingly, caches the route
13:30:12 <Alberth> imo that makes very good sense
13:30:40 <TrueBrain> and I have shown in OpenTTD that when you use A* you can make a very good road builder over very big maps :P
13:30:53 <TrueBrain> just important to keep the H score overestimated .. so it won't be perfect :)
13:31:14 <TrueBrain> on a 64x64 map .. you can completely resolve it in a very short time :P
13:31:43 <TrueBrain> anyway, glx, this is most likely why it can't find simple routes ... it does a modified dead-mans-walk
13:31:48 <Alberth> yeah, should be no problem on a modern desktop, or even mobile
13:32:06 <TrueBrain> it searches VERY local
13:33:03 <TrueBrain> and there are bugs .. either due to conversion, or real bugs ...
13:33:09 <TrueBrain> I wonder if I want to find out
13:34:15 <Alberth> do a meta find-out :)
13:35:50 <TrueBrain> very tempted to just implement an A*
13:36:12 <TrueBrain> wrote one for something else a few days ago .. in C++ thou .. was so much easier than the one I wrote for OpenTTD ...
13:36:23 <TrueBrain> no fiddling with writing a Binary Heap or a Queue or something
13:36:43 <Alberth> STL does have its uses :)
13:37:33 <TrueBrain> so I have 2 things that make little sense, ignoring the type of algorithm used
13:37:36 <glx> except STL implementation is compiler dependant :)
13:37:43 <TrueBrain> 1 I suspect is a conversion bug
13:37:52 <glx> for iterators it can be fun ;)
13:37:59 <TrueBrain> for () { score = GetScore(); }
13:38:02 <TrueBrain> instead of score +=
13:38:21 <TrueBrain> the other is this piece of code that looks for the end tile in case it cannot connect the two points, that I can't make sense of ...
13:39:29 <TrueBrain> I think it is meant to reduce CPU load
13:39:47 <TrueBrain> something like: in case you can't find a route to me now, and I can find a route to the end, it is unlikely you can find a route to any of the tiles between us
13:39:54 <Alberth> I do know dune2 had its pathfinding problems, but I don't remember it being so broken as in this conversion
13:40:11 <TrueBrain> start the original and try it?
13:40:19 <TrueBrain> I would love to have a savegame where you can clearly see they differ
13:40:46 <Alberth> pretty much anything where the shortest route is around the bottom
13:41:07 <TrueBrain> would you be able to supply me with a savegame?
13:41:14 <TrueBrain> (if possible, one tested in DOSBox first, but I can do that myself)
13:41:34 <TrueBrain> just put two units on the map, and tell me which to move to the other to see weird stuff
13:46:15 <TrueBrain> the algorithm is pretty clever tbh, with very little CPU usage I would guess
13:46:26 <TrueBrain> it just tries to stay as close as possible to the direct line between start and end
13:48:37 <Alberth> only tried in opendune
13:51:18 <TrueBrain> weird ordos btw, these atreides :D:P
13:52:25 <Alberth> they are self-deviated
13:52:27 <TrueBrain> okay, and what am I looking at that is weird?
13:53:17 <Alberth> you think going along the top is not weird?
13:53:56 <Alberth> other simple experiments, like 2 units above each other, then move the top one to just below the bottom one
13:54:30 <TrueBrain> sorry, I do not see what you mean .. but okay .. (in the scen1.jpg)
13:54:45 <TrueBrain> and OpenDUNE just crashed :(
13:57:35 <TrueBrain> k, the latter is confirmed to be OpenDUNE, not Dune2
13:58:12 <glx> so conversion error somewhere
13:58:29 <TrueBrain> no clue why it is not getting it
13:59:03 <TrueBrain> Music_Player, Driver_Sound_LoadFile, Drivers_GenerateFilename, File_Exists, _File_Open
13:59:08 <TrueBrain> nothing that locks SDL, as far as I know :P
13:59:39 <TrueBrain> but consistently it hangs here when I get shot at
13:59:45 <glx> hmm I did this conversion IIRC
14:00:20 <TrueBrain> I will look into it
14:00:21 <glx> I have hangs in file_open sometimes too
14:01:14 <TrueBrain> we have locks everywhere to avoid problems
14:02:24 <TrueBrain> so what is locking SDL
14:02:42 <TrueBrain> it is freaking libc
14:02:53 <TrueBrain> File_Open does fopen, which does malloc()
14:03:00 <TrueBrain> SDL_UpdateRect does XReply which does free()
14:03:07 <TrueBrain> and you can't do free() while doing malloc()
14:03:25 <TrueBrain> but isn't that always true for multithread applications?
14:04:46 <TrueBrain> there are 2 threads
14:04:51 <TrueBrain> and giving time to the other
14:04:55 <TrueBrain> which wants to do free()
14:07:59 <TrueBrain> so yeah, indeed, you should never free() in an interrupt
14:08:02 <TrueBrain> but ... SDL is doing it
14:09:18 <TrueBrain> so disabling the PIC during malloc is the only 'solution'
14:09:22 <TrueBrain> and that is a bitch, as there are many places :P
14:16:15 <TrueBrain> xreply frees the event
14:23:19 <TrueBrain> pretty smart, it smooths the route at the end
14:24:05 <Alberth> making it look pretty :)
14:25:18 <DorpsGek> SVN: truebrain (r2293) -Codechange: named and pretified the Pathfinder code a bit
14:28:02 <DorpsGek> SVN: truebrain (r2294) -Fix (r1324): failure in conversion, should be += of course :)
14:29:44 <TrueBrain> I see it was optional which score function to use
14:29:52 <TrueBrain> explains why the max is as possible value :)
14:31:07 <DorpsGek> SVN: truebrain (r2295) -Codechange: just as much you can no longer pick your score function, the max allowed score is also silly to have as parameter
14:31:19 <TrueBrain> I should stop writing epistols in my commit messages :P
14:51:01 <TrueBrain> voices make the game hang a lot on linux
14:52:53 <DorpsGek> SVN: truebrain (r2296) -Fix (r1324): conversion error; the amount of loops are mind blowing
14:52:58 <TrueBrain> at least fixed part of your problem Alberth
14:53:06 <TrueBrain> but now I udnerstand what this piece of code is suppose to do
14:54:34 <Alberth> one problem down, one problem to go :)
14:55:21 <TrueBrain> it for some reason picks a less optimal route
14:55:49 <DorpsGek> SVN: truebrain (r2297) -Codechange (r2296): reworded the code a bit to be easier to read
14:56:13 <TrueBrain> but I was right about the pieces of code. It reasons: if you cannot connect A to B, and B leads to dst, there is no point in checking any tile between B and dst
15:08:52 <DorpsGek> SVN: truebrain (r2298) -Fix: >>= 8 is sign-extended on an int16, not zero-extended as required
15:08:59 <TrueBrain> now that was very unexpected :D
15:09:23 <DorpsGek> SVN: truebrain (r2299) -Codechange: some documentation on Pathfinder_Smoothen
15:09:26 <TrueBrain> still not 100% there
15:13:32 <TrueBrain> the score returned was negative in many cases
15:13:41 <TrueBrain> making the pathfinder think some routes were really good
15:13:45 <TrueBrain> over other much better routes :p
15:15:29 <TrueBrain> not sure what goes wrong now
15:15:37 <TrueBrain> it takes a longer route, dunno who causes it
15:16:11 <TrueBrain> the route found before smoothing is enjoyable :P
16:04:00 <TrueBrain> owh, yeah, I was fixing the pathfinder :P
16:24:48 <TrueBrain> I don't understand why this one case fails
16:38:51 <DorpsGek> SVN: truebrain (r2300) -Codechange: some better comments for the pathfinder
16:45:19 <DorpsGek> SVN: truebrain (r2301) -Fix (r2297): forgot to update a variable on continue
16:45:27 <TrueBrain> pathfinder works again as it should, as far as I can tell
16:45:35 <TrueBrain> Alberth / glx: if you can find any weird things, please let me know :)
16:59:59 *** planetmaker has joined #openDune
16:59:59 *** ChanServ sets mode: +v planetmaker
17:07:51 <TrueBrain> posted about the PF
17:29:39 <glx> foundCounterclockwise used uninitialised (runtime failure check)
17:31:13 * glx is trying to fix another deadlock in dsp
17:31:15 <DorpsGek> SVN: truebrain (r2302) -Fix: compilers complaining about uninitialized values
17:46:22 <glx> when it's not in DSP, it's free vs _File_Open
17:57:40 <TrueBrain> yeah, we need to get ride of UpdateRect in the timer I guess
17:59:36 <TrueBrain> or load everything in the memory from the start :P
18:00:00 <glx> ok I think I fixed the DSP_SetTimeConst deadlock
18:02:00 <glx> start a new game with harkonnens, send a quad in right bottom corner, deadlock after "warning"
18:06:12 <TrueBrain> I btw don't see why windows deadlocks on fopen
18:06:16 <TrueBrain> I would like to see that backtrace
18:06:22 <TrueBrain> I understand linux does in the X11 driver
18:06:29 <TrueBrain> but windows doesn't have that :P
18:10:31 <TrueBrain> I am reading about malloc/free, how it is done .. malloc can never block
18:10:34 <TrueBrain> but free sadly enough can
18:10:37 <TrueBrain> which is amusing :P
18:25:47 <TrueBrain> segfaults on my other machine
18:25:59 <TrueBrain> MPU_SetVolume called with data=NULL
18:26:51 <TrueBrain> might be my patch I guess ...
18:30:01 <TrueBrain> #0 MPU_SetVolume (index=0, volume=0, arg0C=2000) at src/mt32mpu.c:884
18:30:03 <TrueBrain> #1 0x000000000041faeb in GameLoop_GameIntroAnimationMenu ()
18:30:04 <TrueBrain> at src/opendune.c:1885
18:30:06 <TrueBrain> #2 0x00000000004207e5 in GameLoop_Main (argc=<value optimized out>,
18:30:07 <TrueBrain> argv=<value optimized out>) at src/opendune.c:2168
18:31:09 <TrueBrain> sound is 0, voice is 1
18:33:26 <DorpsGek> SVN: truebrain (r2303) -Fix: if we depend on index being 0xFFFF if driver is not initialized, make sure we set it in all cases by default, allowing it to change later
18:34:37 <DorpsGek> SVN: truebrain (r2304) -Add: hide the countless deadlocks because of malloc/free mutex by disabling the timer when doing file operations (the most likely cause of the deadlock). WARNING: this is hiding the problem, not solving!
18:34:43 <TrueBrain> r2304 should avoid most of the issues
18:35:07 <TrueBrain> it also scews the ingame clock
18:35:10 <TrueBrain> and voices, etc etc
18:35:15 <TrueBrain> but at least it doesn't deadlock :)
18:36:18 <DorpsGek> SVN: truebrain (r2305) -Revert (r2304): I have a better idea to solve this a bit more elegant
18:37:35 <DorpsGek> SVN: truebrain (r2306) -Fix: retry: don't do SDL stuff when file stuff is ongoing
18:37:57 <TrueBrain> that is a bit more efficient
18:41:21 <DorpsGek> SVN: truebrain (r2307) -Codechange: rename g_inputIgnore to g_fileOperation, hopefully reflecting more what it does
18:41:27 <TrueBrain> should be more stable I hope
18:56:16 <glx> hmm when I fix something it deadlocks later
18:56:29 * glx needs to rethink DSP driver :)
18:58:09 <glx> for some reason DSP_SetTimeConst() is called from main thread, and from callback thread at the same time
19:01:00 <glx> that means 2 files are played at the same time, should not happen
19:01:26 <TrueBrain> why does the timer do it btw?
19:01:32 <TrueBrain> only mouse, keyboard and video are handled
19:01:39 <TrueBrain> but .. what calls it?
19:01:57 <glx> MPU interrupt is timer based
19:02:31 <TrueBrain> yes, but that am I saying
19:02:37 <TrueBrain> what calls DSP in the timer?
19:03:21 <glx> nothing it's DSP_Callback() vs DSP_Play()
19:03:33 <glx> callback is the SDL stuff
19:03:40 <TrueBrain> owh, of course, it has a callback too
19:04:30 <glx> anyway calling SDL_CloseAudio() "from" the callback is not a good idea either
19:04:48 <glx> that's why I need to rethink all the DSP stuff
19:05:33 <TrueBrain> let me know if you have any non-DSP crashes now btw :)
19:07:37 <glx> it just hangs, with music still playing and "working" mouse (as in the cursor is correctly updated on moves)
19:20:57 <glx> hmm mpu_send deadlocks too
19:25:04 <TrueBrain> 1 global variable which says: s_mpu_lock
19:25:10 <TrueBrain> set it to true when you start each function
19:25:13 <TrueBrain> set it to false when you are done
19:25:18 <TrueBrain> solves deadlocks for sure :)
21:01:16 <glx> I just checked something, all buggy .voc have type 3 blocks
21:05:23 <glx> that's where I get deadlocks too :)
21:05:45 <TrueBrain> I wanted to diff the VOCs, but I didn't know how :p
21:06:02 <TrueBrain> are the VOCs of MrFlibble without type 3 blocks?
21:14:18 <TrueBrain> indeed, MrFlibbles don't have the type3
21:14:49 <TrueBrain> isnt the silence there so they follow eachother correctly?
21:16:25 <glx> that's the original stuff, only soundblaster drivers know what to do with silence block
21:16:27 <TrueBrain> so we can safely skip it
21:17:10 <TrueBrain> so we can just skip it :P
21:20:43 <TrueBrain> and every time it is at the end of the voc
21:22:31 <DorpsGek> SVN: glx (r2308) -Fix: silence blocks in VOC files cause many problems, just ignore them
21:25:15 <glx> ok there's clearly a problem with MPU
21:25:59 <glx> easy to hear, start a new game (any house), move an unit until it finds an enemy unit
21:26:03 <TrueBrain> posted on the forum about your finding
21:26:16 <TrueBrain> check my bug report
21:26:27 <TrueBrain> the string you see on screen is wrong then
21:26:31 <TrueBrain> Sabatour approaching
21:26:35 <TrueBrain> instead of Atreides
21:27:03 <TrueBrain> maybe it is related?
21:27:08 <TrueBrain> I dunno, haven't had the time to look into it
21:27:20 <glx> the MPU bug is something else
21:27:43 <glx> but you need working audio for that ;à
21:28:05 <TrueBrain> but then what does MPU have to do with seeing an enemy?
21:28:09 <glx> I think you should clearly hear the problem on your windows
21:28:55 <glx> when you see the enemy and start to fight, the music change, but now it seems to mix the 2 musics
21:29:22 <glx> and after some time it will eventually deadlock
21:30:05 <TrueBrain> but the DSP problems are solved now?
21:30:24 <glx> I see no reason for it to deadlock now
21:30:32 <glx> the callback calls nothing
21:31:46 <TrueBrain> is my post correct btw?
21:31:54 <TrueBrain> I tried to summarize what you said :p
21:41:12 <DorpsGek> SVN: glx (r2309) -Fix (r2308): removed useless static variable, added more safety check
22:42:26 <DorpsGek> SVN: glx (r2310) -Fix (r1347, #79): conversion error
continue to next day ⏵
