Add: [Video] move GameLoop into its own thread
This allows drawing to happen while the GameLoop is doing an iteration too. Sadly, not much drawing currently can be done while the GameLoop is running, as for example PollEvent() or UpdateWindows() can influence the game-state. As such, they first need to acquire a lock on the game-state before they can be called. Currently, the main advantage is the time spend in Paint(), which for non-OpenGL drivers can be a few milliseconds. For OpenGL this is more like 0.05 milliseconds; in these instances this change doesn't add any benefits for now. This is an alternative to the former "draw-thread", which moved the drawing in a thread for some OSes. It has similar performance gain as this does, although this implementation allows for more finer control over what suffers when the GameLoop takes too long: drawing or the next GameLoop. For now they both suffer equally.
This commit is contained in:
		 Patric Stout
					Patric Stout
				
			
				
					committed by
					
						 Patric Stout
						Patric Stout
					
				
			
			
				
	
			
			
			 Patric Stout
						Patric Stout
					
				
			
						parent
						
							3a4a15cc93
						
					
				
				
					commit
					e56d2c63c3
				
			| @@ -48,9 +48,9 @@ void VideoDriver_Null::MainLoop() | ||||
| 	uint i; | ||||
|  | ||||
| 	for (i = 0; i < this->ticks; i++) { | ||||
| 		GameLoop(); | ||||
| 		InputLoop(); | ||||
| 		UpdateWindows(); | ||||
| 		::GameLoop(); | ||||
| 		::InputLoop(); | ||||
| 		::UpdateWindows(); | ||||
| 	} | ||||
| } | ||||
|  | ||||
|   | ||||
		Reference in New Issue
	
	Block a user