I am sorta new to this forum so I am not sure if this question has been asked, but while searching the Internet I have not found a satisfactory answer. The main question I have is should I program my engine with a sprite class (a class that effects images only), a sprite controller (a single class that controls all sprite drawing no matter how many sprites need to be drawn, even if it is 1000) and an entity class that will be the parent of the other various entities that will require the sprite image skins to be displayed on the screen?

Also I am wondering if this is the case, would the sprite translate, rotate, and scale matrix transform be part of the sprite controller or the sprite image, and would any of this information need to be part of the entity classes?

Thank you,

Stitch

I am sorta new to this forum so I am not sure if this question has been asked, but while searching the Internet I have not found a satisfactory answer. The main question I have is should I program my engine with a sprite class (a class that effects images only), a sprite controller (a single class that controls all sprite drawing no matter how many sprites need to be drawn, even if it is 1000) and an entity class that will be the parent of the other various entities that will require the sprite image skins to be displayed on the screen?

Also I am wondering if this is the case, would the sprite translate, rotate, and scale matrix transform be part of the sprite controller or the sprite image, and would any of this information need to be part of the entity classes?

Thank you,

Stitch

There isn't really a need for a sprite controller. You could just put all the transformation functionality (translate, rotate, scale, etc.) into a single sprite class. Whenever you need to draw your sprite, just use a simple CSprite::Draw() method to draw it. The only issue with having a sprite controller is the sprite would have to somehow link to the controller and whatever entity is using it. Using a controller may just make things more confusing than they have to be.

[quote name='Experiment-626' timestamp='1312492650' post='4844714']
I am sorta new to this forum so I am not sure if this question has been asked, but while searching the Internet I have not found a satisfactory answer. The main question I have is should I program my engine with a sprite class (a class that effects images only), a sprite controller (a single class that controls all sprite drawing no matter how many sprites need to be drawn, even if it is 1000) and an entity class that will be the parent of the other various entities that will require the sprite image skins to be displayed on the screen?

Also I am wondering if this is the case, would the sprite translate, rotate, and scale matrix transform be part of the sprite controller or the sprite image, and would any of this information need to be part of the entity classes?

Thank you,

Stitch

There isn't really a need for a sprite controller. You could just put all the transformation functionality (translate, rotate, scale, etc.) into a single sprite class. Whenever you need to draw your sprite, just use a simple CSprite::Draw() method to draw it. The only issue with having a sprite controller is the sprite would have to somehow link to the controller and whatever entity is using it. Using a controller may just make things more confusing than they have to be.
[/quote]

I suppose that the LPD3DXSPRITE variable could just be added to the graphics engine but I am trying to understand how I should go about making the classes for my sprites and the entities. All I meant by a sprite controller was a class that handles the begin, end, and draw aspects of LPD3DXSPRITE. I read in several places that you should only have one of them. I was considering maybe placing LPD3DXSPRITE in the sprite class but would it not slow down the rendering process? I know that I will have an image processing class (SPRITE) and a player processing class (ENTITY).

Setting up a dedicated controller (better renderer or painter) helps in implementing and switching between different kind of paint techniques or in implementing a debug renderer which paints some useful info like sprite ids or collisions points.
Entities shouldn't know much, at best nothing, about their visualization.

[quote name='bluehailex' timestamp='1312499940' post='4844774']
[quote name='Experiment-626' timestamp='1312492650' post='4844714']
I am sorta new to this forum so I am not sure if this question has been asked, but while searching the Internet I have not found a satisfactory answer. The main question I have is should I program my engine with a sprite class (a class that effects images only), a sprite controller (a single class that controls all sprite drawing no matter how many sprites need to be drawn, even if it is 1000) and an entity class that will be the parent of the other various entities that will require the sprite image skins to be displayed on the screen?

Also I am wondering if this is the case, would the sprite translate, rotate, and scale matrix transform be part of the sprite controller or the sprite image, and would any of this information need to be part of the entity classes?

Thank you,

Stitch

There isn't really a need for a sprite controller. You could just put all the transformation functionality (translate, rotate, scale, etc.) into a single sprite class. Whenever you need to draw your sprite, just use a simple CSprite::Draw() method to draw it. The only issue with having a sprite controller is the sprite would have to somehow link to the controller and whatever entity is using it. Using a controller may just make things more confusing than they have to be.
[/quote]



I suppose that the LPD3DXSPRITE variable could just be added to the graphics engine but I am trying to understand how I should go about making the classes for my sprites and the entities. All I meant by a sprite controller was a class that handles the begin, end, and draw aspects of LPD3DXSPRITE. I read in several places that you should only have one of them. I was considering maybe placing LPD3DXSPRITE in the sprite class but would it not slow down the rendering process? I know that I will have an image processing class (SPRITE) and a player processing class (ENTITY).
[/quote]

It would all depend on when you are calling the Draw() method from your sprite class. If you are using DirectX's sprite system where you need to be calling Begin and end Scene before and after sprite rendering, then you should have a main Render2D() with you graphics engine. In that you would call Begin() at the beginning and then your End() at the end, with all your Draw() calls for your sprites in between. If you want to be able to call Draw() anywhere, then a sprite controller would probably be a better option. [color="#CCCCCC"] The [color="#CCCCCC"] LPD3DXSPRITE variable should just be apart of the graphics engine.

Then should[color="#1c2837"][size=2] LPD3DXSPRITE be called per each screen sprite or should it be called once and make it a global variable within the game loop or graphics engine?

Then should[color="#1c2837"] LPD3DXSPRITE be called per each screen sprite or should it be called once and make it a global variable within the game loop or graphics engine?

What do you mean by called? LPD3DXSPRITE (ID3DXSprite*) is a type, not a function. Some calls will have to be called for each sprite every time you draw it such as ID3DXSprite::Draw(...) or ID3DXSprite::Settransform(...) or whatever you are using to draw and manipulate your sprites. But you should only call ID3DXSprite::Begin(...) and ID3DXSprite::End() once every frame at the beginning and end of your entire game loop respectively. Your LPD3DXSPRITE object should be apart of the graphics engine, and you reference that in your sprite class whenever you need to draw a sprite.

[quote name='Experiment-626' timestamp='1312574243' post='4845182']
Then should[color="#1c2837"] LPD3DXSPRITE be called per each screen sprite or should it be called once and make it a global variable within the game loop or graphics engine?

What do you mean by called? LPD3DXSPRITE (ID3DXSprite*) is a type, not a function. Some calls will have to be called for each sprite every time you draw it such as ID3DXSprite::Draw(...) or ID3DXSprite::Settransform(...) or whatever you are using to draw and manipulate your sprites. But you should only call ID3DXSprite::Begin(...) and ID3DXSprite::End() once every frame at the beginning and end of your entire game loop respectively. Your LPD3DXSPRITE object should be apart of the graphics engine, and you reference that in your sprite class whenever you need to draw a sprite.
[/quote]

I know it is a type and not a function. What I was meaning was should LPD3DXSPRITE be part of a sprite that has only all of the images attributes: LPDIRECT3DTEXTURE9, D3DXIMAGE_INFO, etc. If LPD3DXSPRITE is part of the sprite class that controls all aspects of the image that the entity classes will use as their skins, then LPD3DXSPRITE::Begin(), ::Draw(), and ::End() would need to be called per different sprite being used.

[quote name='bluehailex' timestamp='1312578083' post='4845219']
[quote name='Experiment-626' timestamp='1312574243' post='4845182']
Then should[color="#1c2837"] LPD3DXSPRITE be called per each screen sprite or should it be called once and make it a global variable within the game loop or graphics engine?

What do you mean by called? LPD3DXSPRITE (ID3DXSprite*) is a type, not a function. Some calls will have to be called for each sprite every time you draw it such as ID3DXSprite::Draw(...) or ID3DXSprite::Settransform(...) or whatever you are using to draw and manipulate your sprites. But you should only call ID3DXSprite::Begin(...) and ID3DXSprite::End() once every frame at the beginning and end of your entire game loop respectively. Your LPD3DXSPRITE object should be apart of the graphics engine, and you reference that in your sprite class whenever you need to draw a sprite.
[/quote]

I know it is a type and not a function. What I was meaning was should LPD3DXSPRITE be part of a sprite that has only all of the images attributes: LPDIRECT3DTEXTURE9, D3DXIMAGE_INFO, etc. If LPD3DXSPRITE is part of the sprite class that controls all aspects of the image that the entity classes will use as their skins, then LPD3DXSPRITE::Begin(), ::Draw(), and ::End() would need to be called per different sprite being used.
[/quote]

If all of your sprites use LPD3DXSPRITE in the same exact way, then you should only have one LPD3DXSPRITE object which is apart of your graphics engine.

This is the conclusion that I think I came up with but that's when I had the thought about placing LPD3DXSPRITE in its own controller class. But I am in the initial phase of experimenting with various classes and interactions. Thank you for the insight. Do you think I should strive to have zero global variables or are some globals good?