In an object-oriented programming style does how does one tend to handle graphics? Should each object contain its own graphics information? How does that information get displayed?
My experience with making graphical programs is limited, but I have tended to have the objects and the graphics be only loosely related. For instance, if I implemented a chess game I would tend to have a graphics object responsible for making the board, getting images for the chess pieces, loading them into a hash attached to names such as White_Queen, and then updating the screen whenever things changed. The changes themselves would be passed to the main game loop from the objects, and then to the graphics object. The piece objects would contain the name of the piece graphics they were attached to, in a string, but wouldn’t have any graphics information in them. Is this OOP? Is it good OOP?
What I am thinking about now is that since the project I am working on involves procedurally generated graphics (very, very simple ones), I could have the procedures stored in the objects and get the graphics object to read the procedures from objects passed to it. Would this be OOP? Would it be good?
In the real world, as I have come to know it, things do not contain graphics. Things contain properties and my brain interprets them. Blind people’s brains and the brains of hawks all interpret different objects differently. Is this OOP? Should I try to do it that way?
Hey, thanks for your help as usual!
z.
PS I am writing code in C for the nintendo DS. I’m drawing graphics by coloring pixels individually!
You have several questions in one. Hopefully this will help.
Programmers tend to differentiate between the terms “graphics” and “graphical user interface” (GUI). Generally graphics mean static images (like photographs) or dynamic images (like video games), whereas GUI refers to the normal things you see in an application, such as windows, buttons, or menus. Are you referring to graphics or GUIs?
There are several layers of abstraction between your program and getting an image on your monitor. On a Windows PC it usually comes down to calling Win32 or DirectX functions, which handle all the lowest layer stuff.
You should not put your main functionality in the graphics code, or vice versa. Keep them distinct. This makes it much easier to, say, change the way your pieces look in a chess game, or maybe modify the rules without changing the user interface.
As mentioned by Alex Martelli, the MVC architecture is a good way to separate the business logic (the way it works) from the presentation of your application (the way it looks). In MVC, the view is generally thought of holding the GUI, which may or may not have “graphics”.
It sounds to me like you need to get a better grasp on what object oriented design means. Since there are so many external resources on this topic, I suggest that you Google it. In the mean time, maybe you should just experiment and try different ways of programming your game, rather than worrying if it’s good design. You can figure out what works well and what doesn’t–you don’t need to get it perfect the first time!
On a metaphysical level I suppose you’re correct… what we see is simply a representation of what is around us, electrical signals generated by photons hitting our retinas. When you write your program, you are simply trying to generate images which are meaningful to people. I’m not really sure where you could go with this.
Wouldn’t it be easier to use some graphics library to handle this stuff for you? That way you could just do things like DrawCircle() rather that doing all the pixels yourself. That said, you can learn a lot by implementing your own low level graphics library… just remember that you will spend a lot of time on the library rather than on the game itself.