Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


RenderWindow + GBuffer + Events


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Alundra   Members   -  Reputation: 928

Like
0Likes
Like

Posted 21 May 2013 - 07:55 PM

Hi all,

I have a RenderWindow class who is inherited by renderer (D3D11 and OGL4).

In each of them they have a GBuffer instance and have an array to get events.

What i'm saying in my head is, only one GBuffer is needed and so it can be managed by the render window.

Same for the ortho matrix, only one is needed so it can be managed by the render window.

Is it a correct design to handle that ?

 

My second question is :

Do you have a nice design to handle event ? Actually I have a callback in IGameState and the MainLoop sends

each event stored for the active RenderWindow and the application manage each one.

 

Thanks



Sponsor:

#2 Juliean   GDNet+   -  Reputation: 2741

Like
0Likes
Like

Posted 22 May 2013 - 02:07 AM

What i'm saying in my head is, only one GBuffer is needed and so it can be managed by the render window.

 

Are you implying to GBuffer here as some sort of class, that keeps/manages the GBuffer render targets? If so, I generally don't see any need for this, a gbuffer is nothing more than said render targets, your render architecture determines when they are set/cleared, and the effects pick them as input texture if they need to, at least I('d) design it that way, maybe someone with more experience has an even better idea.

 

Same for the ortho matrix, only one is needed so it can be managed by the render window.

Is it a correct design to handle that ?

 

I wouldn't say that there only needs to be one ortho matrix. There can be many needs for more than one: Rendering non-screenspace pre-transformed sprites, shadow mapping, etc... all of whose are going to need a different ortho matrix. I haven't figured a scalable design for this out myself, so I can't give you a hint here, sorry! I'm just thinking that you might be restricting yourself if you have the render window completely handle the ortho matrix. I have my render window in my 3d editor keep its own camera (view+ortho-matrix), but thats about it...






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS