tags:

views:

277

answers:

2

I have a C# game program that i'm developing. it uses sound samples and winsock.

when i test run the game most of the audio works fine but from time to time if it is multiple samples being played sequentially the application form shakes a little bit and then goes back to its old position.

how do i go about debugging this or present it to you folks in a manageable manner? i'm sure no one is going to want the whole app code in fear of virus attacks.

please guide me..

EDIT: i have not been able to pin down any code section that produces this result. it just does and i cannot explain it.

EDIT: no the x/y position are not changing. the window like shakes around a few pixels and then goes back to the position were it was before the shake.

if (audio)
{
    Stream stream;
    SoundPlayer player;

    stream = Properties.Resources.ResourceManager.GetStream("_home");
    player = new System.Media.SoundPlayer(stream);
    player.PlaySync();
    player.Dispose();

    string ShipID = fireResult.DestroyedShipType.ToString();
    stream = Properties.Resources.ResourceManager.GetStream("_" + ShipID);
    player = new System.Media.SoundPlayer(stream);
    player.PlaySync();
    player.Dispose();

    stream = Properties.Resources.ResourceManager.GetStream("_destroyed");
    player = new System.Media.SoundPlayer(stream);
    player.PlaySync();
    player.Dispose();
}

can you see anything in the above code that would produce this shake?

EDIT: yes the code is being executed within a: this.Invoke(new Action(delegate(){ ....})); could this be it? how do i resolve this?

EDIT:

           stream = Properties.Resources.ResourceManager.GetStream("_destroyed");
           player = new System.Media.SoundPlayer(stream);
           player.PlaySync();
           player.Dispose();
           stream.Dispose();

if the take out the above code, then it works fine! any ideas?

EDIT: i replaced the line with:

stream = Properties.Resources.ResourceManager.GetStream("_destroyed");

to a different file name but the problem is still there but at least it is not the audio file is corrupt.

EDIT: MSN when someone sends a nudge? it is bit like that but only happens 2 or 3 times.

EDIT: Are you using any 3rd party libraries? - no i am not using any 3rd party libs.

EDIT: it seems no matter what file, the 3rd sample always causes this.

EDIT: happens everywhere i use sound samples. if i play 3 samples, the situation happens.

EDIT: @nobugz: yes think you are right. the problem is holding up the UI thread for too long. as i have tried just using a merged audio file and the problem is there given its original duration.

EDIT: i solved this issue by putting Application.DoEvents(); after each sample play command. no shakes :)

EDIT: the above solution did not really work. as the number of player samples grew the application GUI got stuck again. a solution using QueueUserWorkItem has been employed instead. this still remains to be proven as a satisfactory solution as cross therading occurs i.e. a new thread of samples can be started while an old one is still playing.

will update this as more knowledge comes to light.

+2  A: 

Make a copy of your program. Delete as many game elements from the copy as possible. Remove modules, chop out game logic, shift functions between classes to reduce abstraction (so that you can delete classes), and generally hack up the game.

Each time you do so, check if the bug still exists. Initially you'll be deleting bigger chunks of the program but over time the amount of deletion will reduce.

If you find something which, when deleted, fixes the bug, there are two possibilities: Either you found the bug, or there is some sort of synergy with the rest of the program to cause the bug. In the latter case, continue deleting more of the program.

Eventually, you will end up with a minimal program that has the bug. Post that here (or in a pastebin if it's too big).

This is one of the last-resort strategies I use when I encounter a bug that I am unable to locate at all.

Brian
good tip. im glad i have been able to isolate the cause/code without being extreme.
iEisenhower
+3  A: 

Calling PlaySync on the UI thread isn't so great. It will make your main window unresponsive as your UI thread is busy waiting for the sound to finish, it doesn't get around to pumping messages like it should do. If that takes long enough, Windows steps in and overlaps the window with a "ghost", it usually says "Not Responding" in the title bar (if it has one). This ghost window might not quite match your own window, that could explain the "shaking".

Using Play() instead will solve that problem. But gets you a new one, sequencing sounds becomes difficult. Making the calls from a thread can solve both. Check out NAudio for better control over sound.

Hans Passant
I was thinking this might have had something to do with it (calling PlaySync from within the UI thread) - if that is indeed what is happening. But I didn't know the ghosting behaviour, although that explains a lot. That's why I had asked whether it was run in the UI thread since I know that can cause some issues.
Corazu
@nobugz: (Making the calls from a thread can solve both). could you please mention a web article related to what you said?looking at NAudio :)
iEisenhower
Look up ThreadPool.QueueUserWorkItem in MSDN.
Hans Passant
@nobugz: i will accept your tips as answer as it caused me to think about the solution i developed. greets and thanks.
iEisenhower
@ikurtz: fwiw, DoEvents() isn't much of a solution. Try closing the window while the sound is playing.
Hans Passant
@nobugz: if i try to close the window while the sound is playing, it waits till the sample is completely played. this is okay behaviour.unless you have something else in mind?i do agree this is a simplified solution as if the samples are longer than they are now i would run into the same problem again.
iEisenhower
@ikurtz, well, you're lucky. You'd usually bomb with an ObjectDisposed exception when the code continues to run and tries to access a control on the form that is no longer there.
Hans Passant
@nobugz: the behaviour you mentioned is not hapening as the code is executed on the main ui thread. many thanks for your insights.
iEisenhower