|
||||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread ![]() |
| Getting Rid of the Windows Message Pump & Solving the ALT-TAB Problem |
|
![]() jjmontes Member since: 5/28/2002 From: Spain |
||||
|
|
||||
| This article is what I were looking for. I also have a state machine with manages correctly a State Stack (push... pop...) and overlapped states in my engine, but now I'm thinking on porting to DirectGraphics I'd want to do a better aproach. I was thinking on the multithreaded model too but I think, however, there are 2 more aproaches: one of them is to put the message loop inside the game loop. We can do this in a function and call that function from each game function, and the other is doing the same but instead of calling the function that check messages inside each game state, we put it in its normal place and make a hook from outside. Anyway, I think I'll do the multithreaded version so I can forget the main window loop. What do you think about? Good article, in any case. |
||||
|
||||
![]() Merick Member since: 5/20/2001 From: USA |
||||
|
|
||||
| I've been wondering, Direct3D says that "Direct3D is designed so that the methods Reset, CreateDevice, TestCoorperativeLevel, or the final Release of IDirect3DDevice8 can only be called from the same thread that handles window messages." How then should games be written to be ALT-TAB friendly if we have one thread thats handling the message pump and another thats handling the actual game. It would seem to imply that the "message pump" thread needs to do all the handling of reseting and reinitializing all the game resources. Otherwise the game thread would have to constantly be doing checks to see if it needed to reinitialize things, and that seems almost more of a hassle than just writting the game as a state-machine. |
||||
|
||||
![]() marach Member since: 2/7/2005 From: Croatia |
||||
|
|
||||
| also a comment on article. from MSDN Library, CreateThread function: >A thread that uses functions from the C run-time libraries >should use the beginthread and endthread C run-time functions >for thread management rather than CreateThread and ExitThread. >Failure to do so results in small memory leaks when ExitThread >is called. If I figured it out correctly, using CreateThread function like the article suggests, isn't proper way of making another thread. |
||||
|
||||
![]() exgex Member since: 8/9/2007 From: Singapore |
||||
|
|
||||
| I really, really didnt like the FSM model for games programming and your article really helped me alot. But i face one problem. I tried to do Intro(); Sleep(5000); Splash(); Menu(); But the intro function, has rendering, and unfortunately doesnt work when placed outside of d3ddev->BeginScene(); // begins the 3D scene d3ddev->EndScene(); // ends the 3D scene so im not sure how to ger around that... i really dont like to even go near the FSM model. thanks in advance |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|