This difference in conceptual model is reflected in the methods supported by the GLine class, which implements GScalable , but not GFillable or GResizable. It is, moreover, important to modify the notion of containment for lines, since the idea of being within the boundary of the line is not well defined. In the abstract, of course, a line is infinitely thin and therefore contains no points in its interior. In practice, however, it makes sense to define a point as being contained within a line if it is "close enough" to be considered as part of that line.
The motivation for this definition comes from the fact that one of the central uses of the contains method is to determine whether a mouse click applies to a particular object. As is the case in any drawing program, selecting a line with the mouse is indicated by clicking within some pixel distance of the abstract line. Thus, these methods return the appropriate dimensions of the bounding box that encloses the line.
For this reason, it is a common practice to use more simple shapes for collision detection that we overlay on top of the original object. We then check for collisions based on these simple shapes; this makes the code easier and saves a lot of performance. A few examples of such collision shapes are circles, spheres, rectangles, and boxes; these are a lot simpler to work with compared to arbitrary meshes with hundreds of triangles. To detect collisions between complexly shaped game objects. It's a way to make collision detection easier and uses only basic geometric shapes, like the rectangles and circles covered in this tutorial. So, before you start building support for all kinds of complex shapes, try to think of a simple way to achieve the same effect, with basic shapes and hitboxes.
Although the GPolygon class is useful in a variety of contexts, it is limited to those applications in which the desired graphical object can be described as a simple closed polygon. Many graphical objects that one might want to define don't fit this model. Fortunately, the GCompound class described in section 5.7 provides the basis for a much more powerful extension mechanism. In this model, coordinate values are stored as ints, just as they are in the methods provided by the Graphics class in java.awt. Locations, sizes, and bounds for graphical objects are stored using the standard Point, Dimension, and Rectangle classes, which use integer-valued coordinates. This option is the easiest to implement and maintains consistency with the methods provided in the Graphics class.
The GImage class turns out to be relatively easy to design. By using the color of the object to specify this background, clients can use setColor to tint an image as long as that image includes pixels that are less than fully opaque. If the image contains only opaque pixels, setting its color has no effect. The first change is that GCanvas objects should use null as their default layout manager so that the positioning of the components is under client control, just as is true for graphical objects.
Second, the add method must check the size of the component and set it to its preferred size if its bounds are empty. These simple changes seem to do exactly what students would want. Although it makes perfect sense to fill a GRect or GOval, filling is not appropriate for GImage or GLabel. Several members of the Java Task Force felt it was important to define each shape class so that it responded only to messages appropriate to graphical objects of that type.
Such a design makes it possible to catch at compile time any attempts to invoke inappropriate methods. In the acm.graphics package, a filled shape is, in essence, both framed and filled, and therefore covers exactly the same pixels in either mode. This definition was necessary to support separate fill and frame colors and is also likely to generate less confusion for students. Hitboxes are imaginary geometric shapes around game objects that are used to determine collision detection.
You won't check its arms and legs for collision but instead just check a big imaginary rectangle that's placed around the player. The two specialized forms of rectangles—GRoundRect and G3DRect—appear in the hierarchy as subclasses of GRect. The purpose of introducing this additional layer in the hierarchy was to provide an intuitively compelling illustration of the nested hierarchies. Just as all the shape classes are graphical objects , the GRoundRect and G3DRect classes are graphical rectangles .
Organizing the hierarchy in this way emphasizes the is-a relationship that defines subclassing. The objectdraw package allows an object to determine whether its bounding box overlaps that of another through the inclusion of an overlaps method. This method would be straightforward to add, but the functionality is easily obtainable by calling intersects on the bounding rectangles returned by getBounds. Making the user retrieve the bounding box has the advantage that the definition of overlap is then more explicit. The fact that two circles can "overlap" in objectdraw even when they are not touching seems likely to cause confusion.
The acm.graphics package diagram shown in Figure 5-2 contains several additional classes beyond those that have already been described. The GMath class provides an extended set of mathematical methods that are useful for graphical programs and is described in section 5.4. The GCompound class makes it possible to define one GObject as a collection of others. The GPen class provides a simple mechanism for constructing line drawings that adopts a conceptual model of a pen drawing on the canvas. The GTurtle class is similar in many respects, but offers a somewhat more restricted graphical model based on the "turtle graphics" paradigm described in Seymour Papert's Mindstorms .
Instead, this is more of an animation process than anything. The variable we defined as gravity is just a numeric value—a float so that we can use decimal values, not just integers—that we add to ballSpeedVert on every loop. And ballSpeedVert is the vertical speed of the ball, which is added to the Y coordinate of the ball on each loop.
We watch the coordinates of the ball and make sure it stays in the screen. So we watch the floor and ceiling boundries of the screen. With keepInScreen() method, we check if ballY (+ the radius) is less than height, and similarly ballY (- the radius) is more than 0. If the conditions don't meet, we make the ball bounce with makeBounceBottom() and makeBounceTop() methods. To make the ball bounce, we simply move the ball to the exact location where it had to bounce and multiply the vertical speed with -1 (multiplying with -1 changes the sign).
When the speed value has a minus sign, adding Y coordinate the speed becomes ballY + (-ballSpeedVert), which is ballY - ballSpeedVert. So the ball immediately changes its direction with the same speed. Then, as we add gravity to ballSpeedVert and ballSpeedVert has a negative value, it starts to get close to 0, eventually becomes 0, and starts increasing again. That makes the ball rise, rise slower, stop and start falling. Before you can detect collisions between moving objects, you'll need some objects to begin with. In the previous tutorial you've learned how to move a single rectangle.
Let's expand that logic and create a whole bunch of moving objects to fill your game. The GCanvas class provides the link between the world of graphical objects and the Java windowing system. Conceptually, the GCanvas class acts as a container for graphical objects and allows clients of the package to add and remove elements of type GObject from an internal display list. When the GCanvas is repainted, it forwards paint messages to each of the graphical objects it contains. Metaphorically, the GCanvas class acts as the background for a collage in which the student, acting in the role of the artist, positions shapes of various colors, sizes, and styles. These additional methods are collected into standard suites identified by interfaces.
As an example, the shape classes that implement GFillable respond to the methods setFilled, isFilled, setFillColor, and getFillColor. The public methods defined for all graphical objects appear in Figure 5-4, and the additional methods specified by interfaces appear in Figure 5-5. This model requires aggregate structures that describe locations, sizes, and bounds in double precision and that are therefore analogous to Point, Dimension, and Rectangle in the integer world. If nothing else, these names expose the notion of inner classes, which is not generally taken to be an introductory concept.
In light of that complexity, the acm.graphics package includes definitions for the classes GPoint, GDimension, and GRectangle, which provide the same functionality. The more I think about it, the more I like James' idea of letting Java do a lot of the math work as far as figuring out whether things intersect. In Java, as in math, a Rectangle is a Polygon, which is simply a closed Shape made up of line segments, in your case 4. If your rectangles are allowed to tilt, you can't use Rectangle (note the capitalization and lower-case here. Upper case is a class name) unless you use AffineTransforms to tilt things I believe. If you are going to tilt things, use Polygon, which is a 4 sided closed Shape with right angles and line segments as the edges. Polygon and Ellipse are both Shapes, so use the Ellipse.intersects function to determine collisions.
For the details about whether it has collided with each of the four corners, use Ellipse.contains. You probably can't use the contains function because a Line has no area. Now check the Ellipse.intersects function to see if the circle has collided with that edge. The GTurtle class is similar to GPen but uses a "turtle graphics" model derived from the Project Logo turtle described in Seymour Papert's Mindstorms .
In the turtle graphics world, the conceptual model is that of a turtle moving on a large piece of paper. A GTurtle object maintains its current location just as a GPen does, but also maintains a current direction. The path is created by a pen located at the center of the turtle.
If the pen is down, calls to forward generate a line; if the pen is up, such calls simply move the turtle without drawing a line. The GPen class models a pen that remembers its current location on the GCanvas on which it is installed. The most important methods for GPen are setLocation and drawLine.
The former corresponds to picking up the pen and moving it to a new location; the latter represents motion with the pen against the canvas, thereby drawing a line. Each subsequent line begins where the last one ended, which makes it very easy to draw connected figures. The GPen object also remembers the path it has drawn, making it possible to redraw the path when repaint requests occur. The full set of methods for the GPen class is shown in Figure 5-14. The shape classes that appear at the bottom of Figure 5-2 represent "atomic" shapes that have no internal components. Although the GCanvas class makes it possible to position these shapes on the display, it is often useful to assemble several atomic shapes into a "molecule" that you can then manipulate as a unit.
The need to construct this type of compound units provides the motivation behind the inclusion of the GCompound class, in the acm.graphics package. The methods available for GCompound are in some sense the union of those available to the GObject and GCanvas classes. As a GObject, a GCompound responds to method calls like setLocation and scale; as an implementer of the GContainer interface, it supports methods like add and remove. The two submitted packages that offer mouse support each provide a mechanism for responding to mouse events whose design use a callback model rather than listeners. In objectdraw, mouse events generated on the graphical canvas are eventually handled in methods contained in class WindowController, which is the extension of JApplet that contains that canvas.
Students write a class extending WindowController and then override the event-handling methods whose behavior they wish to specify. To avoid this possible source of confusion, GArc does not implement GResizable, but instead implements the methods setFrameRectangle and getFrameRectangle. The GArc class raises a variety of interesting design issues, particularly in terms of seeking to understand the relationship between a filled arc and an unfilled one. Most notably, the contains method for the GArc class returns a result that depends on whether the arc is filled. For an unfilled arc, containment implies that the arc point is actually on the arc, subject to the same interpretation of "closeness" as described for lines in the preceding section. For a filled arc, containment implies inclusion in the wedge.
This definition of containment is necessary to ensure that mouse events are transmitted to the arc in a way that matches the user's intuition. There was, however, one change that the Task Force decided—after extensive debate—would be worth adopting. All but one of the graphics proposals we received chose to use doubles rather than ints to specify coordinate values.
The principal advantage in adopting a double-based paradigm is that the abstract model typically makes more sense in a real-valued world. Physics, after all, operates in the continuous space of real numbers and not in the discrete world of integers, which is simply an artifact of the pixel-based character of graphical displays. Animating an object so that it has velocity or acceleration pretty much forces the programmer to work with real numbers at some point.
Keeping track of object coordinates in double-precision typically makes it possible for programmers to use the stored coordinates of a graphical object as the sole description of its position. If the position of a graphical object is stored as an integer, many applications will require the programmer to keep track of an equivalent real-valued position somewhere else within the structure. On the other hand, the disadvantage of using real-valued coordinates is that doing so represents something of a break from the standard Java model . We defined the coordinates as global variables, created a method that draw the ball, called from gameScreen method. Only thing to pay attention to here is that we initialized coordinates, but we defined them in setup().
The reason we did that is we wanted the ball to start at one fourth from left and one fifth from top. There is no particular reason we want that, but that is a good point for the ball to start. So we needed to get the width and height of the sketch dynamically. The sketch size is defined in setup(), after the first line. Width and height are not set before setup() runs, that's why we couldn't achieve this if we defined the variables on top.
You could simply use the function for rectangle collision detection, you've applied before, to check the hitboxes for collisions. It's far less CPU-intensive and makes supporting complex shapes in your game much easier. In some special cases, you could even use multiple hitboxes per game object. While this simple style of extension is accessible to introductory students, it is problematic for two reasons. First, its use is limited to those cases in which an existing class can be made to draw the desired figure.
Second, this extension model creates class names that imply properties for an object without any guarantee that those properties can be maintained. Since GFilledSquare and GRedSquare both inherit all the methods of GRect and GObject, clients would be able to change the initial properties at will. Thus, an object declared to be a GRedSquare could end up being a green rectangle after a couple of client calls. It therefore seems preferable—at least for pedagogical reasons—to adopt one of the alternative extension models described in a subsequent section.
The GCompound class makes it possible to shift the virtual origin of any of the other figures. However, you can achieve the desired effect by embedding a GOval at the appropriate location within a GCompound. In essence, this strategy relies on the fact that GCompound objects define their own local coordinate system, which offers significant expressive power. The ObjectDragExample application installs two shapes—a red rectangle and a green oval—and then allows the user to drag either shape using the mouse. The code also illustrates z-ordering by moving the current object to the front on a mouse click.
This demo is available as an applet on the JTF web site. The evolutionary history of Java provides two distinct models for responding to mouse events. The model that was defined for JDK 1.0 was based on callback methods whose behavior was defined through subclassing. Thus, to detect a mouse click on a component, you need to define a subclass that overrides the definition of mouseDown with a new implementation having the desired behavior. That model was abandoned in JDK 1.1 in favor of a new model based on event listeners. These models are quite different, and there is no obvious sense in which learning one helps prepare you to learn the other.
