Sign in to follow this  
Antonym

Sprite Decoupling

Recommended Posts

Well I have this function that loads my sprites(On DirectX with c++). All my sprite's properties are kept in a small class, the current column and row(To show the current frame), the width and height of each frame, the last time an animation frame was displayed and the texture variable. Right now I am trying to remove all global variables and basicly decouple my code to make it more managable. My current problem is that after each sprite is loaded and stored in an instance of the sprite class I need each of those instances in a different function to draw/render the objects and another one to update the current frame... How can I acomplish this without making the sprite class's instances global or placing them in a container and passing that container around as an argument like crazy...

Share this post


Link to post
Share on other sites
Quote:
Original post by AntonymHow can I acomplish this without making the sprite class's instances global or placing them in a container and passing that container around as an argument like crazy...
What do you think is wrong with 'passing arguments around like crazy'? If you wish to remove globals, then it is exactly what you must do.

Share this post


Link to post
Share on other sites
Well each object must have a sprite to display in game. I am still not sure though how I will/should go about tieing an object class to a sprite class, perhaps combining them into a single class or having a member of the object class be an instance of the sprite class.

At first the sprite class is instantiated for every sprite loaded into the game.(A ship sprite, a missile sprite) Each sprite is stored into a different instance of the sprite class, then each object has one of those instances assigned to it depending on what it is.(A missile object would need a missile sprite a ship a ship one and so on..)

Each missile object fired/created would need to have a missile sprite assigned/created/instanced for it. So would ships.

That's how they interact I suppose.

Share this post


Link to post
Share on other sites
It sounds like you are close to the MVC pattern. The object is the model and the sprite is the view. In this post Toohrvyk links to a tutorial he wrote about a simple Pong game. If you look towards the end of that tutorial he describes how he applied this pattern to this simple game. Maybe that will give you some clues as to how to structure your code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this