-
Stop Bullet Firing...
Heres the deal...
I have a procedure that fires a shotgun at a window in my program (by pressing the right mouse button), this starts a process of a wave file being played and then the picture of the bullet wound being blitted to the screen.
Well the wave is about 2-3 seconds long and I want to prevent people from shooting again until the wave file is done playing (using the PlaySound API). Well I first tried changing one property from ASYNC to SYNC, but all this does is build up shots in the queue, so delayed bullets and sounds for every time they right click.
My theory and what I need help with. I was wondering if anyone could hint at what API or process I could use to ignore all right click events until the sound is done playing. So if there was an API to check the state of the wave file (still open..playin... etc... ) then I might be able to just use an IF statement...
Thanks for any help...
If you wish to have a visual idea of what I am talking about...
http://www.geocities.com/yassinator/screenkill/sk.html
-
Could you just record the time and then every time the user right clicks you just check to see that the last time was at least 3 seconds ago?
- Sean
-
i used playsound once for a game i made and there was a way to inturrupt the previous wav to play the next way
there should be a 3rd option other than sync and async
i just forget the specifics. check msdn
-
untested code:
Code:
bool shoot=0;
int stopsound=5;
timer //have a timer that uses the systemtime
if(mouseb1 && !shoot)
{
shoot=1;
timer=0;
//playsound
timer++;
}
if(shoot && timer==stopsound)
{
// stop sound
shoot=0;
}
is this what you want?
-
Use Win32 timer.
set it to the duration of the .wav file. Maintain a boolean that you set to false when you begin playing the file and set to true when you receive the WM_TIMER message. All you have to do then is a simple if statement.
-
Sean345 your answer is probably the easiest way for me to do this.
Revelation437, yhea you can interrupt the playing wave by feeding the PlaySound API call with a NULL wave file name, but I don't want the wave file interrupted because after the shot is fired and the wave plays the sound of the gun being cocked it should wait until it is cocked before they can shoot again. So while useful, it isn't what I was looking for.
pode, your method is probably the most secure and controlled manner for handling it, however that means I would have to insert the structure all over my code unless I wanted to pause the whole thread (including animation, movement.. etc..) to wait till the wave is completed which isn't acceptable, but thanks.:)
HybridM, your method is what I think I want to use, even though that requires me to insert a procedure call that isn't generic inside of my WndProc callback. But I do like it.
Thanks everyone for their help!!!:)
I am no professional when it comes to C++ but everyday I work with it, I love it more and more!
-
Glad to help.
By the way, what do you mean by non-generic?
-
in my WndProc, I have GameMouseMove, MouseRBDown, MouseRBUp... etc. etc... but now for the WM_TIMER event, I will need to change a global variable or a specific function ... ChangeShotGunStatus... to tell it that it can fire again... am I being too unclear still...?
-
you don't really need to do that, just have a static bool in your WndProc, then have like:
Code:
LRESULT CALLBACK WndProc(HWND hwnd etc....)
{
static bool CanFire = true;
//........
case WM_TIMER:
CanFire = true;
break;
//........
case WM_RBUTTONDOWN:
if(CanFire)
{
//...do the stuff
CanFire = false;
}
break;
//.......
}
-
Actually, that is just about a perfect idea, so then when I add in new weapons, all I have to do is just set the timer to a different amount and then the Timer event will handle the rest... perfect... the only reason I didn't want to keep stuff that is game specific in my WndProc is because I am trying to keep a generic Game Engine class. But, it is only a few things I will need to remove if I transfer the class....
-
Sounds good. Just remember WM_TIMER messages are very low priority, it won't matter in anything like you're doing now but if your program is busy you can not rely on getting a WM_TIMER message at the specified interval, and I think it's even possible to lose them entirely, but I'm not sure.
-
Well crap, thats not good. Oh well it will due for now. I would of thought time messages would have high priority because a lot of things count on timing...
-
Well then have a look at the GetTickCount() function. It returns a DWORD which is the number of milliseconds elapsed since Windows started.
You could call that when you start playing the sound and put it in a static DWORD, then you can see when they press the right mouse button whether a call to GetTickCount is over 3000 greater than the DWORD from the previous call.
If it is, do the stuff! There are many possibilities. :)
-
Oh and the DWORD will wrap around to 0 after Windows has been up for 49.7 days, so look out for that.
-
Thanks for the info, I can't imagine any time I will set that will go that far... :)
