Luhar

I want to make a component with the same functionality as a SpriteBatch, but it automatically translates, scales, and clips everything drawn with it. I figured I could inherit from SpriteBatch and override the Draw methods, but they're not overridable. I'd be forced to shadow the Draw calls and it kind of blows my whole object-oriented, polymorphic system outta the water.

Right now I'm using containment to do what I want, but it doesn't seem very flexible or object-oriented. I have a base component that just passes everything straight to my internal SpriteBatch object and a derived component that translates, scales, and clips everything before passing it on to the SpriteBatch.

Can anybody offer a better way of doing what I'm trying to do

Thanks!



Re: XNA Framework SpriteBatch.Draw methods not overridable?

Bill Reiss

You can override them, I did it in my Dr. Popper game, the syntax is just a little different... The method declarations will look like this:

new public void Draw(Texture2D texture, Rectangle destinationRectangle, Color color)

Bill






Re: XNA Framework SpriteBatch.Draw methods not overridable?

The ZMan

You have mentioned 2 out of the 3 methods (containment and shadowing)... the 3rd one is write your own spritebatch from scratch to do just what you want but thats not a great idea either.

Send MS a request to make them overridable in future versions






Re: XNA Framework SpriteBatch.Draw methods not overridable?

The ZMan

Bill Reiss wrote:

You can override them, I did it in my Dr. Popper game, the syntax is just a little different... The method declarations will look like this:

new public void Draw(Texture2D texture, Rectangle destinationRectangle, Color color)

Bill

That is the 'shadowing' that he mentioned in the original post. There are some OO reasons why its not always good but off the top of my head I can't remember the issues.






Re: XNA Framework SpriteBatch.Draw methods not overridable?

Bill Reiss

The ZMan wrote:
Bill Reiss wrote:

You can override them, I did it in my Dr. Popper game, the syntax is just a little different... The method declarations will look like this:

new public void Draw(Texture2D texture, Rectangle destinationRectangle, Color color)

Bill

That is the 'shadowing' that he mentioned in the original post. There are some OO reasons why its not always good but off the top of my head I can't remember the issues.

Ok sorry my bad...I agree that they probably should have made these methods virtual so that they can be overridden, but since they didn't, sometimes OO has to go out the window to get the job done.






Re: XNA Framework SpriteBatch.Draw methods not overridable?

Luhar

The ZMan wrote:
Bill Reiss wrote:

You can override them, I did it in my Dr. Popper game, the syntax is just a little different... The method declarations will look like this:

new public void Draw(Texture2D texture, Rectangle destinationRectangle, Color color)

Bill

That is the 'shadowing' that he mentioned in the original post. There are some OO reasons why its not always good but off the top of my head I can't remember the issues.

Well... in my case, the problem with shadowing is that if I pass my derived version of SpriteBatch to a routine that wants a SpriteBatch...

Font.Draw(SpriteBatch renderer, String text, Color color), for example

...the base SpriteBatch.Draw methods will be used instead of my overriden Draw methods.

The problem with my containment solution is that I lose all the advantages of polymorphism and I can't use my object wherever a SpriteBatch is called for. It's a bummer, but I guess I'll just have to go this way. I don't want to write my own SpriteBatch from scratch.

Anyways, thanks for the replies.





Re: XNA Framework SpriteBatch.Draw methods not overridable?

Bill Reiss

Yeah that's true, I forgot that I had to change all mentions of SpriteBatch in my code to my derived class. I guess the other thing that would help us would be if there was an ISpriteBatch interface that we could code to.

Bill






Re: XNA Framework SpriteBatch.Draw methods not overridable?

Shawn Hargreaves - MSFT

The problem with making everything virtual is that calls to virtual functions are significantly slower than to normal methods. Is it worth slowing down everyone who uses SpriteBatch just for the sake of a few people who want to customise it Tough question to answer...





Re: XNA Framework SpriteBatch.Draw methods not overridable?

Bill Reiss

Would creating an ISpriteBatch interface that SpriteBatch would implement and that could be implemented by the people who want to roll their own or encapsulate the existing SpriteBatch suffer from the same performance problems

Thanks,
Bill






Re: XNA Framework SpriteBatch.Draw methods not overridable?

Shawn Hargreaves - MSFT

Calling through interfaces is slower than direct method calls too. That also limits extensibility, because while you could pass a custom ISpriteBatch implementation into methods that were written to take ISpriteBatch parameters, there's nothing stopping people writing their code to work directly with the concrete SpriteBatch, at which point you are back where you started when you want to extend this class.

The performance overhead of virtual calls isn't huge, and in many cases totally irrelevant, but it's something we have to consider when designing methods that are expected to have a particularly high call frequency.





Re: XNA Framework SpriteBatch.Draw methods not overridable?

Bill Reiss

Ok Shawn thanks for the explanation. One last thing that's slightly off topic but may alleviate the need for overriding the SpriteBatch in my current project. How does the performance of the Draw method that takes a scale vector and a position vector compare with the performance of the ones that take a destination rectangle I've already changed some of my draw calls to use the scale and position version of the Draw method because it was the only way I could smoothly scale text without seeing it jump from pixel to pixel due to rounding, but I am considering changing all my drawing to use that style of the Draw method.

Thanks again,
Bill






Re: XNA Framework SpriteBatch.Draw methods not overridable?

Shawn Hargreaves - MSFT

Perf differences between the various overloads should be minimal where they exist at all: I wouldn't expect this to make a lot of difference either way.





Re: XNA Framework SpriteBatch.Draw methods not overridable?

Luhar

That's definitely something to think about. Sounds like I'll have to approach this problem from a different direction. Maybe a separate component that transforms everything before being sent to the SpriteBatch

Thanks for the info.