Hello,

so, I've got my 2d renderer using the lpd3dxsprite-interface working, but since I've just started my new projet I want to make sure everything gets designed well from the beginning. My main goals for this 2d rendering "libary" are:

- Reusability (at least for me in future projects)
- I might want to step away from lpd3dxsprite to plain vb/ibs, as well as change the api (d3d11, open gl) with as little extra work on the mid/high-level layers as possible
- I want to be able to render 2d-only games as well as built a 3d-renderer around this in the future

So this is what I have right now:

- a wrapper for direct3D, the device and the lpd3dxsprite-object (low-level)
- on top of that, graphical objects like: sprite, texture..

And here are a couple of questions:

- Should I have some sort of render-queue like a 3d renderer here, or is it ok to having my sprite-objects issue the draw-command directly to the dx-sprite wrapper?

- Should I rather draw my sprites directly (say I have a player entity composed of a controller, and a sprite, that gets stored in a scene-graph. I call now Player->Draw() which calls Draw() on its sprite-component) or would it be better to have a seperate class handling this, having sprites register/unregister to that class and then drawing them in a flush?

- Extention to both questions above: Is it better to have sprite->draw() issue any command to whether a renderqueue or the lpd3dxsprite-wrapper, or should I rather have sprite->draw() add an internal command in a generic struct to a vector<>. This vector<> could later on being pulled out and issued as a draw command to the lpd3dxsprite-interface, by whatever class finally is responsible for rendering the sprite. A command would consist of the Source-Rect, Destination-Rect, Z, and texture in any case.

- Would it be ok to have my d3ddevice and/or lpd3dxsprite-wrappers singletons/globals? Is there any possible reason to have more than one device and sprite-interface? I'd use Single-window, single-thread applications only.

- Is there any additional design I might want to apply on top of that? Any classes I might want to add to handle rendering?

Hello,

so, I've got my 2d renderer using the lpd3dxsprite-interface working, but since I've just started my new projet I want to make sure everything gets designed well from the beginning. My main goals for this 2d rendering "libary" are:

- Reusability (at least for me in future projects)
- I might want to step away from lpd3dxsprite to plain vb/ibs, as well as change the api (d3d11, open gl) with as little extra work on the mid/high-level layers as possible
- I want to be able to render 2d-only games as well as built a 3d-renderer around this in the future

So this is what I have right now:

- a wrapper for direct3D, the device and the lpd3dxsprite-object (low-level)
- on top of that, graphical objects like: sprite, texture..

And here are a couple of questions:

- Should I have some sort of render-queue like a 3d renderer here, or is it ok to having my sprite-objects issue the draw-command directly to the dx-sprite wrapper?

- Should I rather draw my sprites directly (say I have a player entity composed of a controller, and a sprite, that gets stored in a scene-graph. I call now Player->Draw() which calls Draw() on its sprite-component) or would it be better to have a seperate class handling this, having sprites register/unregister to that class and then drawing them in a flush?

- Extention to both questions above: Is it better to have sprite->draw() issue any command to whether a renderqueue or the lpd3dxsprite-wrapper, or should I rather have sprite->draw() add an internal command in a generic struct to a vector<>. This vector<> could later on being pulled out and issued as a draw command to the lpd3dxsprite-interface, by whatever class finally is responsible for rendering the sprite.

- Would it be ok to have my d3ddevice and/or lpd3dxsprite-wrappers singletons/globals? Is there any possible reason to have more than one device and sprite-interface? I'd use Single-window, single-thread applications only.

- Is there any additional design I might want to apply on top of that? Any classes I might want to add to handle rendering?

Hello,

so, I've got my 2d renderer using the lpd3dxsprite-interface working, but since I've just started my new projet I want to make sure everything gets designed well from the beginning. My main goals for this 2d rendering "libary" are:

- Reusability (at least for me in future projects)
- I want to be able to render 2d-only games as well as built a 3d-renderer around this in the future

So this is what I have right now:

- a wrapper for direct3D, the device and the lpd3dxsprite-object
- on top of that, graphical objects like: sprite, texture..

And here are a couple of questions:

- Should I have some sort of render-queue like a 3d renderer here, or is it ok to having my sprite-objects issue the draw-command directly to the dx-sprite wrapper?

- Should I rather draw my sprites directly (say I have a player entity composed of a controller, and a sprite, that gets stored in a scene-graph. I call now Player->Draw() which calls Draw() on its sprite-component) or would it be better to have a seperate class handling this, having sprites register/unregister to that class and then drawing them in a flush?

- Extention to both questions above: Is it better to have sprite->draw() issue any command to whether a renderqueue or the lpd3dxsprite-wrapper, or should I rather have sprite->draw() add an internal command in a generic struct to a vector<>. This vector<> could later on being pulled out and issued as a draw command to the lpd3dxsprite-interface, by whatever class finally is responsible for rendering the sprite.

- Would it be ok to have my d3ddevice and/or lpd3dxsprite-wrappers singletons/globals? Is there any possible reason to have more than one device and sprite-interface? I'd use Single-window, single-thread applications only.

- Is there any additional design I might want to apply on top of that? Any classes I might want to add to handle rendering?

Hello,

so, I've got my 2d renderer using the lpd3dxsprite-interface working, but since I've just started my new projet I want to make sure everything gets designed well from the beginning. So this is what I have right now:

- a wrapper for direct3D, the device and the lpd3dxsprite-object
- on top of that, graphical objects like: sprite, texture..

And here are a couple of questions:

- Should I have some sort of render-queue like a 3d renderer here, or is it ok to having my sprite-objects issue the draw-command directly to the dx-sprite wrapper?

- Should I rather draw my sprites directly (say I have a player entity composed of a controller, and a sprite, that gets stored in a scene-graph. I call now Player->Draw() which calls Draw() on its sprite-component) or would it be better to have a seperate class handling this, having sprites register/unregister to that class and then drawing them in a flush?

- Extention to both questions above: Is it better to have sprite->draw() issue any command to whether a renderqueue or the lpd3dxsprite-wrapper, or should I rather have sprite->draw() add an internal command in a generic struct to a vector<>. This vector<> could later on being pulled out and issued as a draw command to the lpd3dxsprite-interface, by whatever class finally is responsible for rendering the sprite.

- Would it be ok to have my d3ddevice and/or lpd3dxsprite-wrappers singletons/globals? Is there any possible reason to have more than one device and sprite-interface? I'd use Single-window, single-thread applications only.

- Is there any additional design I might want to apply on top of that? Any classes I might want to add to handle rendering?