Archived

This topic is now archived and is closed to further replies.

Telamon

Why does playing MIDIs with MCI screw up my game loop?

Recommended Posts

Telamon    157
For someone who isn''t a complete newbie, I seem to need a lot of help :-) If I have a win32 proggy locked to 30 fps using this code: // lock to 30 fps while((start_time - GetTickCount() < 33)); in the game loop, and then I start playing a MIDI file using MCI, why would this no longer work? Does MCI play with the timers? How can I fix this? I thought the solution might have to do with multithreading, but my game loop gets screwed up even when another app is playing MIDIs. I think I need a new way to lock fps. What do you think? ----------------------------- Let be be finale of seem, seems to me.

Share this post


Link to post
Share on other sites
SteveC    122
One thing you could do is change the updating from being frame-based to being time based.

I''m guessing what your doing every frame time is telling every game object to do its work based on ''I do this much work per frame''

If you game loop worked on a delta-time mechanism you wouldn''t have to worry about the frame rate - unless it gets really slow and choppy, but then you have to load balance.

So you just compute the number of milliseconds or ticks or whatever you think is right ( such as a seconds as a float ) and then tell all your game objects that x amount of time has passed.

As far as the MIDI file interupting your game app, are you using any other MCI commands?

Share this post


Link to post
Share on other sites
Telamon    157
This is for a SpaceWars game I''m writting using the win32 GDI (and no MFC). I am only using MCI to play MIDIs (and what a headache that was!) The basic game loop looks like this:

In WinProc-

// enter main event loop
while(TRUE)
{
// test if there is a message in queue, if so get it
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
// test if this is a quit
if (msg.message == WM_QUIT)
break;

// translate any accelerator keys
TranslateMessage(&msg);

// send the message to the window proc
DispatchMessage(&msg);
} // end if

// main game processing goes here
Game_Main();

} // end while

// closedown game here
Game_Shutdown();

/////////////////////////////////////////////////////////
And Game_Main looks something like this:

int Game_Main(void *parms = NULL, int num_parms = 0)
{

// get the time
DWORD start_time = GetTickCount();

// erase ships
Erase_Ships();

Rotate_Ships();

Move_Ships();

//Draw ships
Draw_Ships();

// lock to 30 fps
while((start_time - GetTickCount() < 33));

if (KEYDOWN(VK_ESCAPE))
SendMessage(main_window_handle,WM_CLOSE,0,0);

// return success or failure or your own return code here
return(1);


} // end Game_Main

I don''t understand what you mean by a "delta time loop". Isn''t that what I''m doing? I was going to try moving the fps lockdown code to the point where Game_Main is called in WinProc. Why would this work when a MIDI is not being played? When I start playing MIDI music, the game speeds up tremendously. I tried taking the timer loop out and it wizzed by even faster. A new theory I have is that MCI alters the units by which the system clock counts time into a measurement of the blocks in the MIDI file that is being played. But that doesn''t make much sense. How do you guys lock fps in your games?


-----------------------------
Let be be finale of seem, seems to me.

Share this post


Link to post
Share on other sites
SteveC    122
What you are doing is running your game loop free-wheeling but limiting how fast it can go.

A time-based loop could, for example, pass down the number of ticks that have gone by since the last time Game_Main() was called and update everyone based upon that number.

As far as the MCI commands, it is possible that since you are running the MCI commands and presumably giving your main window as the handle to specify windows is putting more messages into your message cue and scheduling you more often.

Remember that most apps use GetMessage() which will suspend the thread if no message is posted for that particular thread.

Anyhow, that''s one possibility.

Share this post


Link to post
Share on other sites