Jump to content
  • Advertisement
Sign in to follow this  
deonbotha

[java] drawing sprites

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
I agree, have the sprites draw themselves. This is the way the pros do it:

http://doc.trolltech.com/3.3/qcanvassprite.html

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!