2
\$\begingroup\$

I'm managing my game state by having a base GameScreen class with a Draw method.

I then have (basically) a stack of GameScreens that I render.
I render the bottom one first, as screens above might not completely cover the ones below.

I now have a problem where one GameScreen changes render targets while doing its rendering. Anything the previous screens have drawn to the backbuffer is lost (as XNA emulates what happens on the xbox). I don't want to just set the backbuffer to preserve its contents as I want this to work on the xbox as well as PC.


How should I manage this problem?

A few ideas I've had:

  1. Render every GameScreen to its own render target, then render them all to the backbuffer.
  2. Create some kind of RenderAction queue where a game screen (and anything else I guess) could queue something to be rendered to the back buffer. They'd render whatever they wanted to any render target as normal, but if they wanted to render to the backbuffer they'd stick that in a queue which would get processed once all rendertarget rendering was done.
  3. Abstract away from render targets and backbuffers and have some way of representing the way graphics flows and transforms between render targets and have something manage/work out the correct rendering order (and render targets) given what rendering process needs as input and what it produces as output.

I think each of my ideas have pros and cons and there are probably several other ways of approaching this general problem so I'm interested in finding out what solutions are out there.

\$\endgroup\$
8
  • \$\begingroup\$ I think the problem is SpriteBatch.Begin() is not set to use AlphaBlending, be sure to set all render states correctly before drawing. \$\endgroup\$
    – Roy T.
    Apr 18, 2012 at 11:17
  • \$\begingroup\$ Thanks for the suggestion, .Begin() with no parameters does use alphablending. \$\endgroup\$ Apr 18, 2012 at 11:19
  • \$\begingroup\$ It looks like this is standard behaviour in XNA, to emulate what it does on the xbox. stackoverflow.com/a/5091707/593627 (So I think my question is still valid). \$\endgroup\$ Apr 18, 2012 at 11:26
  • \$\begingroup\$ George Duckett: doh you're right. And the device states when calling Draw(...); Btw why did you remove the code again? \$\endgroup\$
    – Roy T.
    Apr 18, 2012 at 11:59
  • \$\begingroup\$ I removed the code as I don't think it's needed for the question; I don't think I'm doing anything wrong, it's how XNA works. \$\endgroup\$ Apr 18, 2012 at 12:18

2 Answers 2

2
\$\begingroup\$

I believe (haven't tested it) that if you split your Draw call into PrepareDraw and Draw calls, you can have the GameScreen that changes render targets do that in PrepareDraw and then all GameScreens draw to the backbuffer in the Draw call.

List<GameScreen> screens;
foreach (var screen in screens)
  screen.PrepareDraw(...);
foreach (var screen in screens)
  screen.Draw(...);
\$\endgroup\$
0
\$\begingroup\$

You should be able to first draw to screen, then to a render target and then to the screen again in the same draw loop without losing data. Once that works you should be fine by letting each GameScreen handle whether they need an RT or not themselves. Keep them as 'black box' as possible.

Maybe you're forgetting to fetch the texture from the render target before switching them out? Also note that you can't re-use a render target in the same frame.

What tech are you using btw? Maybe there is a difference between XNA/DirectX and what you're using

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Updated the question (tags), I'm using XNA \$\endgroup\$ Apr 18, 2012 at 10:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .