Sign in to follow this  
davidthefat

Methods of Drawing Images

Recommended Posts

What is a better way to draw objects into the screen? The draw class has a constructor that takes in a file and loads the image in the class or have a function that takes in an array of images and the index of the image and draw those on the screen? So the Player and Enemy Classes both have their own array of images and they will have to be passed to the Draw Function.

Share this post


Link to post
Share on other sites
So... Load the image into the Image Handling class and have a draw function that takes in the image and draws it? Or load the image into the Actor class and draw it though the Draw function the the Image Handling class?

Share this post


Link to post
Share on other sites
Which is better is a subjective statement; we can list the disadvantages and advantages of any solution, and even tell you what to do, but it's still up to you to figure out what is right for you. The question is what problem are you trying to solve? Without knowing that, answers are meaningless.

You said you want to draw abjects on the screen. If you can implement either system, and it works, then that's a valid system for you. Depending on how you implement it, there may be inefficiencies or bugs. If you can describe your problem more clearly, the choice may become more obvious.

Quote:
Original post by Hodgman
What is the "draw class", what does it represent, what problem does it solve?
It shouldn't be solving the problem of loading images, choosing from a set of images AND actually drawing images - that's 3 different problems.


I agree that a class named "draw" shouldn't load images, or choose from a list, but that's all semantics. Is it OK for one abstractions to handle loading and drawing of images? Why not? Even if possible to separate it into smaller steps or abstractions, is anything gained? Your link suggests your argument is based on one abstraction having information about many different tasks, but is it not valid to use an abstraction that represents loading, choosing, and drawing? What advantage will be gained for the OP if it separates them?

Share this post


Link to post
Share on other sites
Quote:
Original post by Splinter of Chaos
Is it OK for one abstractions to handle loading and drawing of images? Why not? Even if possible to separate it into smaller steps or abstractions, is anything gained?
From a pure engineering viewpoint, you get better testability and reusability.
For example, some other part of the code may need to draw images but not load them, or load images but not draw them. By breaking it into two separate problems you allow the individual solutions to be reused.
Also unit tests are a lot easier to write if there is only one problem to validate, without being tightly coupled to other problems as well.
Quote:
Your link suggests your argument is based on one abstraction having information about many different tasks, but is it not valid to use an abstraction that represents loading, choosing, and drawing? What advantage will be gained for the OP if it separates them?
You can still have one class that does both loading and drawing if that's useful to you, but following this guideline, you would create such a class by simply composing an "image drawer" object and an "image loader" object together.

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