Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap to draw with. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That class HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since it's responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
Show differencesHistory of post edits
#24Khatharr
Posted 25 October 2012 - 12:10 AM
Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap to draw with. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That UI element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element's class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap to draw with. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That UI element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element's class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
#23Khatharr
Posted 25 October 2012 - 12:07 AM
Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap to draw with. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap to draw with. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
#22Khatharr
Posted 25 October 2012 - 12:06 AM
Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
#21Khatharr
Posted 25 October 2012 - 12:06 AM
Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/functionality, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since the element class is responsible for encapsulating the UI element state/functionality, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
#20Khatharr
Posted 25 October 2012 - 12:04 AM
Single Responsiblity Principal
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since it's responsible for processing logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').
In my own personal lexicon 'Sprite' is one type of inheritor from abstract 'RenderObject', which represents anything that can be individually rendered during a frame according to its current internal state. Sprite, in particular, contains a pointer to a 'Bitmap' (responsible for a single texture and its relevant info/loading/etc), an x/y screen position, and a rect of some form indicating the source-rect from the Bitmap draw. An entity usually carries its own Sprite object, but Sprite itself is not an entity.
Sprite HAS-A Bitmap, which it uses as the texture to render itself with.
Sprite IS-A RenderObject because if you call .render() then it renders according to its internal state. (I actually use RenderObject to obscure registration with a list of objects in the 'Graphics' namespace that have their render() member function called by Graphics::update() if their 'visible' boolean member is true.)
In my games an Entity HAS-A Sprite so that it can be displayed on the screen when appropriate.
Each Entity is responsible for keeping the members of its member Sprite up-to-date so that when Graphics::update() is called everything gets drawn correctly.
For UI elements I may compose a class for simple elements that HAS-A Sprite, or more than one. Otherwise, if I feel it's better for the structure I may create a separate RenderObject inheritor to draw (but not implement any logic for) some complex UI element. That element HAS-A RenderObject, but it itself can't claim that it IS-A RenderObject, since it's responsible for processing logic, not for drawing.
That's just how I do it, though. I suppose it can mean different things to different people. I've heard some people refer to a texture as a sprite, or a cell within a multi-celled texture as sprite (calling the full texture a 'sprite-sheet').