I think what Grey Alien is trying to do makes perfect sense.
The sprite type should always call it's own Draw() method when it tries to Draw() from within itself.
And the player type should call the sprite's Draw() method, unless the player type has it's own Draw() method.
It doesn't make sense for the code in the sprite type to call the player's draw method when the draw method is overridden in the player type, because then the person that wrote the sprite type cannot predict how his own functions will behave when given these overridden types.
On the other hand, if you need a player to draw in a special way, and the sprite type's update function draws all the sprites with the sprite's draw method, then in order to use that update function and have it draw the players correctly, the sprite's draw method must be overridden.
But what if the sprite's draw method counts on the fact that draw works a certain way, and it draws shadows by calling the draw mwthod after setting some blending modes? Then that shadow casting functionality will break as soon as the user who wrote the player type overrides the sprite type.
This doesn't seem like it prevents bugs to me. It seems to me that if the aim is to have objects that you don't need to consider the internals of when making new objects, that having methods that override the methods another type calls itself internally is a very bad thing.
On the other hand, being able to call sprite.update() to draw all the sprites is useful, and if you can't override the draw function your players won't be drawn correctly.
But should it be? That Sprite.Update() function is for updating sprites. And a player is not a sprite... Well, actually it is a sprite in the world of OOP. The sprite is not an object the player moves, the player is a sprite.
I think I still hate OOP.
Btw, grey, why are you making a sprite type, I thought you were using my sprite system? :-) If you've changed it, you should know it already handles drawing sprites brighter than normal and the draw function won't allow you to override the blend mode in that way. I suspect you're making your own sprite type though so that wouldn't be an issue then.
The sprite type should always call it's own Draw() method when it tries to Draw() from within itself.
And the player type should call the sprite's Draw() method, unless the player type has it's own Draw() method.
It doesn't make sense for the code in the sprite type to call the player's draw method when the draw method is overridden in the player type, because then the person that wrote the sprite type cannot predict how his own functions will behave when given these overridden types.
On the other hand, if you need a player to draw in a special way, and the sprite type's update function draws all the sprites with the sprite's draw method, then in order to use that update function and have it draw the players correctly, the sprite's draw method must be overridden.
But what if the sprite's draw method counts on the fact that draw works a certain way, and it draws shadows by calling the draw mwthod after setting some blending modes? Then that shadow casting functionality will break as soon as the user who wrote the player type overrides the sprite type.
This doesn't seem like it prevents bugs to me. It seems to me that if the aim is to have objects that you don't need to consider the internals of when making new objects, that having methods that override the methods another type calls itself internally is a very bad thing.
On the other hand, being able to call sprite.update() to draw all the sprites is useful, and if you can't override the draw function your players won't be drawn correctly.
But should it be? That Sprite.Update() function is for updating sprites. And a player is not a sprite... Well, actually it is a sprite in the world of OOP. The sprite is not an object the player moves, the player is a sprite.
I think I still hate OOP.
Btw, grey, why are you making a sprite type, I thought you were using my sprite system? :-) If you've changed it, you should know it already handles drawing sprites brighter than normal and the draw function won't allow you to override the blend mode in that way. I suspect you're making your own sprite type though so that wouldn't be an issue then.