Hi, Been doing a bit more imvestigating. I managed to get it to crash without locking the screen. I got a dump from the debug, but I couldn't get it off the eeepc (no network -cant mount non BeFS RW). If i disable sound, no crashing. It crashed in PlaySound() with the previous stack element FillNextBuffer(). It seems that if this crashes whilst the Locker is locked (still can't work out how :) the system freezes. That is probably something I can try to protect, however the crashing sound I can't. All I ever do is: BFileGameSound *screech = new BFileGameSound("screech.wav", true); To play the sound: if( !screech->IsPlaying() ) { screech->StartPlaying(); } and visa versa when it wants to turn off if( screech->IsPlaying() ) { screech->StopPlaying(); } At the moment, this is all in one thread (drawing thread). The basic flow is: drawing thread: while ! quit lock update direct window unlock check inputs update car physics The directconnected uses the same lock. I was thinking of making an input thread, however I really need max performance - I can get about 20 fps from a 630MHz eeepc at 640x480 32 bit on 4 million points (the map). All software rendering. Cheers, Jeff On Sat, Jun 13, 2009 at 9:25 PM, Stephan Assmus<superstippi@xxxxxx> wrote: > Hi, > > On 2009-06-13 at 14:02:20 [+0200], j s <jsvader@xxxxxxxxx> wrote: >> A while back I wrote a game using a direct window. I've had a few fun and >> games getting it running again - I had to change MessageReceived to >> MouseDown (probably the correct way anyway). Anyway, the game runs now - >> although I can't seem to get the cursor working properly. The biggest >> problem is I use a game sound (screeching tyres) which freezes the system >> when it reaches the end. Normally it doesn't reach the end (ie the car >> stops sliding). There is no debug as the system completely freezes - >> needs a power cycle to reboot. >> >> Is there something that I now need to do that previously worked? Similar >> to the MessageReceived to MouseUp/Down issue. I wouldn't rule out bad >> practice which was less problematic in a previous life :^) > > In principle, everything that used to work is supposed to work still. :-) > But it will be easier to track down the problem if you post code. If you > don't want to do that, you are probably the best person to track down the > problem. For that I'd recommend setting up the Haiku source tree on Haiku, > placing a link to the generated libgame.so in your applications ./lib > folder and start adding debug output to the problematic API implementations > that you use. Then your application will run your modified libgame.so with > the debug output and you are hopefully able to track it down. The "complete > freeze" sounds more like your BDirectWindow is blocking the app_server. But > if some media_addon_server realtime thread is caught up in a loop, it may > also look like a complete system freeze. Usually, you should still be able > to press F12 to enter the kernel debugger. > >> PS I hope to release the game soon - well at least for others to test. > > Mhhmm yummie! Screeching tyres... sounds fun! :-D > > Best regards, > -Stephan > >