[java] drawing sprites
Author
I'm creating a clone of bomberman and i was wondering should my Sprite class have a render/draw method to draw itself, or should I have one main method somewhere looping through all the sprites and drawing them. whats the best way to go about it?
I'd definitely recommend that each sprite takes care of its own rendering, myself. I also think that it's worthwhile creating sprite-groups that can tell any contained sprites to draw themselves, because managing groups of sprites is simply a lot less hassle than having to deal with sprites individually, and is also pretty much essential when you're having your sprites created and destroyed all the time.
I agree, have the sprites draw themselves. This is the way the pros do it:
http://doc.trolltech.com/3.3/qcanvassprite.html
http://doc.trolltech.com/3.3/qcanvassprite.html
Unless you are using a 3D API that would benefit from setting a sprite texture once and drawing the same thing many times. Just thought I would add that.
Make render() a function of Sprite itself - that way you can overload it in subclasses. In one of the more complex engines I've designed, Sprite was a completely abstract class, with subclasses for different image storage types (ie Image sprites or direct pixel arrays) as well as different types of sprites (Polygon sprites, keyframes that were composite sprites made up of other sprites).
For the keyframes, I actually made Render a function that could also accept a previous keyframe and time so that the positions of all the sprites could be interpolated in the animation. For the polygon sprites, it could also accept a rotation. They both worked with standard render(), and thus didn't break the different animation and sprite management classes.
For the keyframes, I actually made Render a function that could also accept a previous keyframe and time so that the positions of all the sprites could be interpolated in the animation. For the polygon sprites, it could also accept a rotation. They both worked with standard render(), and thus didn't break the different animation and sprite management classes.
Yeah - I'm also having Sprites as abstract class in my gamelib, with simple render method implemented in abstract Sprite class. I create then Subclasses at app level for different movable objects (like player, alien, bonus clasees etc). Most of them are quite ok with base implementation of render() method which just draws current frame (BufferedImage) on the screen, but some classes override method to implement their own rendering - for example compositing several images .
Good thing of doing it that way is that render method is easy to implement - just few lines of code. Also it's easy to add new kind of sprites with different rendering - I never had to touch my original Sprite class.
If you were to write main method that loops through different sprites, you would have to make big switch or if/else or maybe some other way to decide what you are drawing as soon as you wanted to implement different way to render different things.
However this approach (one render method that loops through all sprites) have one pros - it's only one function call to render() instead of one function call per sprite. But I don't think that speedup is worth having big method that needs constant updating when new things are added - it's easy to mess up. But if yuu would draw all your sprites same way then you can probably make it that approach as well.
Good thing of doing it that way is that render method is easy to implement - just few lines of code. Also it's easy to add new kind of sprites with different rendering - I never had to touch my original Sprite class.
If you were to write main method that loops through different sprites, you would have to make big switch or if/else or maybe some other way to decide what you are drawing as soon as you wanted to implement different way to render different things.
However this approach (one render method that loops through all sprites) have one pros - it's only one function call to render() instead of one function call per sprite. But I don't think that speedup is worth having big method that needs constant updating when new things are added - it's easy to mess up. But if yuu would draw all your sprites same way then you can probably make it that approach as well.
usually I never bother writing a specific sprite class. I'll have classes for something more concrete like a space ship or something, and that will keep a reference to a BufferedImage. In that case, the ship class will have a render method, but nothing lower than that.
I find that a general sprite class can make things an awful lot simpler, though. Having all of your sprites derived from a single class often comes in handy, especially when you want to implement things like the sprite-groups I mentioned earlier. Makes collision routines simpler too, in my experience.
Author
In kinda the same light then where would be the best place to do collision detection, inside a sprites update method or somewhere else? Thanks guys you've all been a great help so far :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
