Jump to content
  • Advertisement

Archived

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

Mayrel

Object Model

This topic is 5893 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 making an OOP engine that uses OpenGL for rendering, and I''m in a quandry as to an aspect of the object model. Basically, I already have a triumvirate of classes: Pixmap, Texture and Context. A Pixmap is what you''d expect. A Texture is a GL texture, and a Context is, roughly, a render context. All these classes derive from the Image class, which defines a blit operation, so you can blit between the lot of them. The problem I''m having is this: if the hardware supports rendering to textures, I want to use it. As it stands, you render to a context and then blit it to a texture - there''s no way to fit a render-to-texture optimisation in there. I''ve got two solutions in mind, and I''d like some feedback on which one you like, or what you think might be a better solution. The first is that you use Contexts for rendering as usual, but that if you want to render to a texture, you use an Image::createContext to get a context that you can use to draw to that texture. If render-to-texture is not available, it just returns a new context that renders to the backbuffer (and blits back to the texture when you''ve done rendering), but if it is, then it returns a context that renders to the texture. The second is that I get rid of the Pixmap/Texture/Context distinction and just have Images. The engine will then keep a track of how an Image is being used: if it is attached to a Window, then it cannot be used a texture elsewhere; if it is being used as a texture, it cannot be used as a pixmap; if it''s just a pixmap, you can do anything with it. The trick with this is that I (and the users of my engine) need to be careful about knowing what state an Image will be in at a particular point so as to keep things running smoothly - mixing up context-based methods (like rendering primitives) and pixmap-based methods (like accessing pixels) will greatly degrade performance.
Just Plain Wrong

Share this post


Link to post
Share on other sites
Advertisement
In my opinion i would go for the second choice, you should keep also a texture rendering list, to pack same texture to be drawn in a single tetxure binding stage, ( i''m referring to opengl )
and also , don''t you think that putting too much overhead before just using a texture may slow things down ?

Share this post


Link to post
Share on other sites
quote:
Original post by v71
don''t you think that putting too much overhead before just using a texture may slow things down ?


Hmm. I''m not planning to render to every texture in the program, if that''s what you mean: only to those that need it. In truth, I cannot think of anything that I want to use a render-to-texture feature for, right now, so the speed issue doesn''t exist. I just like to plan ahead.

On the other hand - if you mean that the overhead of having to set up a Context for every texture (in the second method) would slow things down - you''re right. The system would only set up the Context part of the Image when it is first used as an Image (although you could still ''prime'' the Image at any time so you can be sure it''ll be real quick to use as a Context later on).



Just Plain Wrong

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!