Hi all,
I am trying to create my own C++ Wrapper around SDL2 functions.
Code:
DrawTarget RenderTarget
| |
| |
±–> Window <—+
DrawTarget is an abstract class for draw target suitable to SDL_Surface blitting.
RenderTarget is and abstract class for render target suitable to SDL_Texture.
Window is derivated class managing SDL_Window, SDL_Renderer and all draw and rendering functions.
I see three possible methods of rendering.
Passing window’s SDL_Renderer pointer all around renderable objects. This allows renderable objects to draw itself to the screen. I do not think, calling object->render(x,y) is a cache efficient way.
Creating, loading and using objects through the Window class. This seems really nice to me, but I do not want to make Window instance global, thus I am not able to create renderable objects from some locations in my code.
Modifying both methods 1 a 2, passing Window all around renderable objects. In additional, their render(x,y) method will call Window’s render methods with necessary parameters.
Could you point me to the best solution of these or even give me a better one?
Thank you------------------------
I’m SDL newbie
Just use raw SDL2 until you have enough experience to answer this question
yourself.
Ideally, all you need the C++ wrapper to do is to manage resource life time
using RAII.On Sat, Mar 29, 2014 at 12:38 PM, lorin wrote:
Hi all,
I am trying to create my own C++ Wrapper around SDL2 functions.
Code:
DrawTarget RenderTarget
| |
| |
±–> Window <—+
DrawTarget is an abstract class for draw target suitable to SDL_Surface
blitting.
RenderTarget is and abstract class for render target suitable to
SDL_Texture.
Window is derivated class managing SDL_Window, SDL_Renderer and all draw
and rendering functions.
I see three possible methods of rendering.
Passing window’s SDL_Renderer pointer all around renderable objects.
This allows renderable objects to draw itself to the screen. I do not
think, calling object->render(x,y) is a cache efficient way.
Creating, loading and using objects through the Window class. This
seems really nice to me, but I do not want to make Window instance global,
thus I am not able to create renderable objects from some locations in my
code.
Modifying both methods 1 a 2, passing Window all around renderable
objects. In additional, their render(x,y) method will call Window’s render
methods with necessary parameters.
Could you point me to the best solution of these or even give me a better
one?
Thank you
I think I get what you are saying. If you google “sdl2 c++ wrapper” you’ll see that several have been produced open source. I’ll bet that would be the best start.
You could make new classes that combine and/or alter existing classes and add some basic hardcoded object data. Who knows, maybe someone is doing exactly what you want already. If you contribute to an existing lib then you might get advice or maybe even help from the main author, and all sdl2 users could use the new features. If you make a basic example people might see it and want to use it.
The way you are talking about this tells me you have not researched the existing body of work out there. Please don’t be mad if I’m wrong.
I hope this is useful advice. Whatever you do I hope to see some of your code one day
---- lorin wrote:=============
Hi all,
I am trying to create my own C++ Wrapper around SDL2 functions.
Code:
DrawTarget RenderTarget
| |
| |
±–> Window <—+
DrawTarget is an abstract class for draw target suitable to SDL_Surface blitting.
RenderTarget is and abstract class for render target suitable to SDL_Texture.
Window is derivated class managing SDL_Window, SDL_Renderer and all draw and rendering functions.
I see three possible methods of rendering.
Passing window’s SDL_Renderer pointer all around renderable objects. This allows renderable objects to draw itself to the screen. I do not think, calling object->render(x,y) is a cache efficient way.
Creating, loading and using objects through the Window class. This seems really nice to me, but I do not want to make Window instance global, thus I am not able to create renderable objects from some locations in my code.
Modifying both methods 1 a 2, passing Window all around renderable objects. In additional, their render(x,y) method will call Window’s render methods with necessary parameters.
Could you point me to the best solution of these or even give me a better one?
Thank you
Make your wrapper the way that feels best to you and minimizes your effort
(both in making it and using it). You probably want to make something
tangible and not just a wrapper for its own sake. If you run into a
limitation, either of flexibility or performance, then you can sit down
with it and refactor. You’ll learn a lot that way.
That said, I would think it makes sense to hide the SDL_Renderer pointer
and not pass it around because it shouldn’t immediately affect your ideal
wrapper API. If renderable objects have a reference (C++ reference or a
integer ID) to the window they correspond to, you can use a global table
(e.g. C++ map) that lets them get their window. It depends on the
direction and looseness of coupling you want. Also, check out the
Singleton or Monostate patterns if you want a cheezy way to hide globals.
I don’t know why you need both surface blitting and texture rendering. Regardless I’d do thing differently between surface blitting and texture rendering. Of course this is design question, and there would be right or wrong. You might don’t agree with me
For surface blitting, I would have drawing function takes the target surface as a parameter. The reason is surface can be blit to any surface, unlike texture which is bound to the renderer it is created with.
For texture renderer, I would have all renderable object contains a pointer to renderer it’s created with. The reason is to avoid invalid renderer being used during function call. If I need only 1 renderer (as the single window application would be most of the time), I might put it in a singleton class.
Thank you for ideas. First of all, this window definition is old. My current design uses two window definitions - one for software rendering, one for hardware one.
mr_tawan: I have been using this method before. I just thought that there might be better and more efficient way than passing sdl-renderer to renderable objects.
One question in the end - is problem to create sdl_texture with one renderer and render it with another one?------------------------
I’m SDL newbie
One question in the end - is problem to create sdl_texture with one
renderer and render it with another one?
No, It will not work. Each renderer checks before rendering whether the
texture was created with the same renderer, or not. If not, no rendering
is done.On 3/30/2014 4:47 AM, lorin wrote:
Pallav Nawani wrote:> On 3/30/2014 4:47 AM, lorin wrote:
One question in the end - is problem to create sdl_texture with one
renderer and render it with another one?
No, It will not work. Each renderer checks before rendering whether the
texture was created with the same renderer, or not. If not, no rendering
is done.
Then I do not understand why SDL_RenderCopy needs SDL_Renderer pointer. Texture itself owns pointer to renderer it was created with.
Mostly for consistency with the other APIs which do need one.On Mon, Mar 31, 2014 at 7:37 AM, lorin wrote:
Pallav Nawani wrote:
On 3/30/2014 4:47 AM, lorin wrote:
Quote:
One question in the end - is problem to create sdl_texture with one
renderer and render it with another one?
No, It will not work. Each renderer checks before rendering whether the
texture was created with the same renderer, or not. If not, no rendering
is done.
Then I do not understand why SDL_RenderCopy needs SDL_Renderer pointer.
Texture itself owns pointer to renderer it was created with.
