Jump to content
  • Advertisement


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


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

This topic is 6439 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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
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
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
// 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)

// translate any accelerator keys

// send the message to the window proc
} // end if

// main game processing goes here

} // end while

// closedown game here

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



//Draw ships

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


// return success or failure or your own return code here

} // 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
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

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!