Sign in to follow this  

Object Oriented approach Java

This topic is 3726 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

This my first post in this Community so I would like to shout out a HELLO WORLD :) I am trying to get into gamedeveloping and now I'm developping a Tetris-Clone. My question though is a more general one. In Java you have these Graphic-Objects on which you paint. Now I have kind of a Playfield-Class and the Shapes. Now when I want to draw a shape, how do I approach this? should I give the Gamefield's Graphic object to the method in the Shape-Class which draws the shape, or should I create a new Graphics object which is returned by the method, and is then added to the surrounding Graphics object? I read into Classes and so on, and I would like to do it very clean and nicely so I hope to get a good answer from you guys. Thank you, -C2k7

Share this post


Link to post
Share on other sites
You extend JComponent (any you find suitable, or just the plain one) and override the paintComponent(Graphics g) method. You then put rendering code in there.

To update the display, call the repaint (or invalidate or something similar, they have minor differences in how they work), and the paintComponent will get called when windowing system finds it appropriate.

And you shouldn't have any need to create your own Graphics object. Appropriate instance that you use is provided as a parameter to paintComponent.

Share this post


Link to post
Share on other sites
Thank you :)

I have read this article but it does not answer my OO-Question. In that example, a Graphics-Object is painted with different shapes and strings but if it had a shape class, would it pass that g2d-Object over to that class to paint on it too, or would it ask that shape-class for it's own Graphics object and then add that object to the g2d?

I don't know if what I write makes any sense so please ask if something I say needs further explanation :)

-C2k7

Share this post


Link to post
Share on other sites
Swing has a certain hierarchy and design concepts, and while not really required, the solution can be much simpler if you try to embrace them.

Your paintComponent renders entire playfield. Background, borders, pieces, ....

Since you'll likely have these defined in separate classes, define an interface:

public interface Renderable {
public void draw(Graphics2D g); // use Graphics2D here if using Java 1.4+
}



You then implement this interface in pieces that can be rendered:

class Tetrino : implements Renderable {
public void draw(Graphics2D g) {
// render the piece
// assume that you're rendering the piece
// without any offset.
// so for block, you render from (0,0) to (2*w, 2*h)
}
}



Your main component then looks like this:
class Playfield {
public void paintComponent( Graphics g ) <-- regular graphics
{
Graphics2D g2 = (Graphics2D)g; <-- unchecked-cast
for (Tetrino t : tetrinos) {
g2.setColor( Color.RED );

// translate canvas so that the location of tetrino becomes (0,0)
g2.translate( t.getX(), t.getY() );

t.draw(g2);

// translate back to origin
g2.translate( -t.getX(), -t.getY() );
}
}
}



Where's the benefit of this? Isn't this slow? Isn't there another way?

This approach allows you to completely decouple all rendering from tetrino class. Performance, for all practical purposes, is not an issue.

You could make Tetrino extend JComponent. That's your choice, and you can choose to implement it this way same as JTable, JList and other renderers are implemented.

Some would recognize this approach as very similar to how 3D renderers operate. And due to the way Graphics class is implemented on the platform, that might as well be the case.

Java's graphics, while somewhat clunky, tries to take as much advantage from hardware rendering, and using Graphics' functionality may considerably improve performance, as well as provide consistent approach to rendering.

There are other ways though.

Share this post


Link to post
Share on other sites

This topic is 3726 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.

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