Jump to content
  • Advertisement

Archived

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

RuneLancer

On threads and rendering...

This topic is 5304 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

I''m curious about one thing... Assuming I''m creating a 2D game with 2D rendering methods (ie, the traditional blitter with nothing being sent to 3D acceleration hardware as such), what would be the best way to handle the rendering? As I see it, there are two possibilities for two different parts. 1 - When to render: as needed or every frame The former sounds easiest on the CPU since less work takes place, but it makes it rather hard to support double buffering (since you''ll have to either keep both buffers updated at once, which defeats the purpose of double buffering, or re-render everytime you update in order to keep your display in sync; or am I missing something here?) and often, such as when you have a scrolling BG, pretty much the whole display gets updated anyways. But for static displays (such as a menu screen or a status screen), re-rendering seems wasteful. Then again, there''s not much going on during these sorts of screens, so it''s not like a full render would cause any problems anyways. In fact, if it works fine in-game, it should work even better during a screen with very little in terms of events. There being less stuff to do and all. 2 - How to render: via a separate thread or not. The guts of my question. Assuming I decide to fully rerender every frame, would there be a significant increase if I were to seperate the render loop and the rest of the game loop? Let''s suppose my game represents its graphics by objects. I could have a sprite object, a background object, a tile object, a window object, etc. And each would have a render method which would just plain and simple render them to screen from a pre-rendered buffer (to avoid having to rebuild every frame, say, a window: text, edges, etc..). Nice and simple. Two things I could do, then. - In my main, I handle the basic stuff (enemy AI, player input, etc.. etc..), then loop through every element and render them. - Or, screw that, just worry about the "basic stuff," and let a seperate thread constantly loop through the elements and render them. So, what''s the best way to do this? Or is there a better way than what I''ve suggested up there? Input on the matter would be very welcomed

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I think using a seperate thread to do your rendering is a good idea as far as giving everyone a fair and equal chance to do whatever task it is that they have to do without breaking the continuity. Especially when you have animations going in the background which need to be rendered at a constant rate. Eg: The game may receive a huge data packet, and have to do some decryption, or have a heavy AI routine "every now and then" which could take longer than 1 / (whatever framerate you are getting). This becomes very noticible when you have animation-like objects, since there is a break in the continuity in the animation. But, if your game is not very taxing on the CPU then screw it i say. Of course, there are the finer details of having a seperate rendering thread which make use of the time it takes to page flip from one page to the next. But i dont think it''s worth it, since Flip, as far as i know, do not block such that another thread receives focus for the time it takes to flip, or do a VSync. I think the WaitForVerticalBlank does block though, but this method does not need to be invoked on a page flip.

Share this post


Link to post
Share on other sites
Having a separate rendering thread is a very bad idea, as your game model may change while it''s rendering, in ways that are very hard to protect against.

Instead do all logic & rendering in the same thread, other threads (if necessary for input, OS event handling etc) should do as little work as possible and just set flags read periodically by the main thread.

As far as re-rendering the entire screen is concerned, most games do this even if nothing very much is happening at the time (for instance, game paused, main menu etc).

There are a number of reasons for this:
1. CPU has nothing better to do; assume that the game is the only important task on the OS (usually safe assumption even on multitasking OS)
2. It keeps things like caches full of game data so that performance is more consistent (and stops OS swapping out data in use) - don''t get "jerky" performance for first few frames following pause.
3. FPS can be measured for calibration purposes so that when the game resumes it can go at the right speed immediately.

I sometimes run the renderer loop with the game paused for 1s or so before starting the game, just to let things "settle down". Sort of like letting the engine warm up

Mark

Share this post


Link to post
Share on other sites
So... is a render thread good or bad? Opinions seem pretty divided on the subject... If there''s no substantially significant benefit to having a seperate thread handle a certain part of the game engine, is there even an actual use for them in a game, performance-wise?

The way my rendering loop works, I just set certain properties of certain objects (for instance, the position and size) and wether they exist or not (ie, should we draw say, ItemTextWindow, or should we just can it for now since it doesn''t have its place onscreen currently?) in other parts of the game loop. Then, I just loop through every graphic object and render it.

Seems to me it would be pretty easy to just cut out the loop-and-render bit, seeing as it isn''t actually "linked" to any other part of my game loop and happens to be pretty much stand-alone... So I''m a bit confused about this.

Share this post


Link to post
Share on other sites
Yes, threads are a good option for applications, including games, but should not be used to divide the renderer from the game logic. The reason is that the renderer is very dependent on the game logic and there would be lots of locking going on as the two threads clash over access to common variables. It''s better to combine your game logic and rendering into the same thread. Tasks that are very tightly coupled should work in the same thread.

However, if you have non-time critical processing, such as gathering network I/O or doing logging, things that may hold up the rendering if they take too long, but that you don''t care if they take a little longer than normal sometimes, try putting those in separate threads. I always put my logging into a separate thread, because writing to files on disk can be very time consuming and I never want the logging to hold up the rendering. Some processing that isn''t done every frame may also be a good candidate for a separate thread, such as loading resources from disk or some AI logic.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!