The problem:
I've been creating a Snake game in Java and everything is working smoothly. The only problem I've having is displaying the score. Each time the snake "eats" an apple, the score increases by 10. Instead of displaying the current score, it simply writes over the present score without actually erasing it. When I attempt to erase the content before re-displaying, I get an error and nothing appears, other than my background colour.
I have other Graphics components, including a paint() that I do NOT want affected.
My attempt (theoretical):
I display the score using a Graphics object that calls
drawString("Current score: " + currScore, 0, (Constants.TOTAL_HEIGHT + 15));
I figured I have to call a clearRect() method, which makes sense to me. Unfortunately, I get a NullPointerException at the line specifying clearRect().
I'm not using Graphics2D just so I can first be familiar with Graphics. If resolving this issue involves Graphics2D, I have no problem using it.
My attempt (the method in question):
public void displayScore(Graphics g) {
//clearScore.clearRect(0, getY(), getWidth(), getHeight());
//g.clearRect(0, getY(), getWidth(), getHeight());
g.drawString("Current score: " + currHighScore, 0, (Constants.TOTAL_HEIGHT + 15));
}
In the code, clearScore is a Graphics object declared in the class outside of any methods. My reason for using this was to avoid affecting the other graphics. I attempted each of the clearRect() lines and both produced the same NullPointerException, which is why I have them commented out.
(Constants.TOTAL_HEIGHT + 15) is responsible for assigning the Y-coordinate.
The Error Message:
Exception in thread "Thread-3" java.lang.NullPointerException
at com.nmw.view.CanvasFrame.displayScore(CanvasFrame.java:149)
at com.nmw.view.CanvasFrame.drawAll(CanvasFrame.java:43)
at com.nmw.view.CanvasFrame.run(CanvasFrame.java:64)
at java.lang.Thread.run(Thread.java:722)
drawAll is where I call all of my methods that take in Graphics to draw a segment of the game.
Apologies for the lengthy question =/
Your problem is that you are likely trying to draw with a null Graphics object. This usually occurs if you are not drawing within the paint(...) method if AWT or paintComponent(...) if Swing. The solution,
draw within one of those two methods (depending on the library you're using).
Always call the super's method within your painting method.
Or use a Label (AWT) or JLabel (Swing) to display the data.
To be blunt, your statement: "I have other Graphics components, including a paint() that I do NOT want affected." -- is an unrealistic requirement if this is an AWT project and if you don't want to use a Label.
And this statement:
In the code, clearScore is a Graphics object declared in the class outside of any methods. My reason for using this was to avoid affecting the other graphics.
Is not how you should do drawing, ever. You're finding out now why. If you happen to get a Graphics context during the running of the program, use it to assign Graphics to your class field, and then try to use that class field, you'll often get the NPE like you're seeing because a Graphics object thus obtained is not long-lasting.
If you need more in-depth help, please post your actual assignment requirements and more code. In particular your drawing methods. Best would be to create and post an sscce.
Edit
You state in comment:
My Snake game is an independent project I've been doing to learn more about Graphics. I've only been using the AWT library, however, I'll try using a Label. Thank you for your response and explanation of why I got the NullPointerException
If this is for your own project and not a school assignment, then I think that you will want to avoid using AWT and instead use Swing. It is much more powerful and flexible than AWT. There really is no reason why you'd want to use AWT now adays.
Related
I'm using the Slick2D Java game library and I want to set the scale of the graphics object that gets passed to the render method in my game loop. I'd like to do this outside the render method, so that I would only have to call the setScale() method once. I am implementing my game as StateBasedGame, so I'd to like to initialize my graphics object in my StateBasedGame class. Where would be the appropriate place to do this?
In the Init method, where you should be initializing your image. I can expand upon this, but your question seems to acknowledge that you already know how to scale the image.
EDIT: After rereading the question, the answer would be that you need to scale it every time you go into the render method of your gamestate object. This requires that you put graphics.scale(0.5f, 0.5f);
This is required, I believe, because the graphics object resets its scale every game tick so that you don't get a compounded effect as it calls the render method hundreds of times.
I'm planning to write a simple spaceshooter. I have read that the repaint() method is only a request, and it doesn't execute every time it's called. I believe I'm noticing the effects of this, as my spaceship tends to lag ever so slightly when I'm moving it. Currently I'm simply drawing my ship in a a JPanel's paintComponent() method, and keep calling repaint() on regular intervals (my panel's also Runnable). Seeing as repaint() may potentially screw me over, I'm trying to find a way to work arround it, however I've ran out of ideas. The code I have so far:
private void renderGraphics() {
if (MyImage == null) {
MyImage = new BufferedImage(getPreferredSize().width,
getPreferredSize().height, BufferedImage.TYPE_INT_RGB);
}
MyGraphics = MyImage.getGraphics();
MyGraphics.setColor(Color.BLACK);
MyGraphics.fillRect(0, 0, getPreferredSize().width, getPreferredSize().height);
MyGraphics.drawImage(ship.getImage(), ship.getCurrentX(), ship.getCurrentY(), null);
}
The idea was to create my own graphics, and then make the JPanel draw it, and keep calling this instead of repaint() in my run() method, however I have no idea how to do that. I'd appriciate any input on the matter.
There are multiple ways to approach this.
The best is probably to use BufferStrategy and draw to that, of which I have included a code snippet that should work for you.
You can take this one step further and abandon Swing altogether, just using Frame/BufferStrategy. There is a fully working example (from which the code snippet was taken and adapted) in my question here:
AWT custom rendering - capture smooth resizes and eliminate resize flicker
Anyway, here is an implementation BufferStrategy that you should be able to just drop in:
// you should be extending JFrame
public void addNotify() {
super.addNotify();
createBufferStrategy(2);
}
private synchronized void render() {
BufferStrategy strategy = getBufferStrategy();
if (strategy==null) return;
sizeChanged = false;
// Render single frame
do {
// The following loop ensures that the contents of the drawing buffer
// are consistent in case the underlying surface was recreated
do {
MyGraphics draw = strategy.getDrawGraphics();
draw.setColor(Color.BLACK);
draw.fillRect(0, 0, getPreferredSize().width, getPreferredSize().height);
draw.drawImage(ship.getImage(), ship.getCurrentX(), ship.getCurrentY(), null);
draw.dispose();
// Repeat the rendering if the drawing buffer contents
// were restored
} while (strategy.contentsRestored());
// Display the buffer
strategy.show();
// Repeat the rendering if the drawing buffer was lost
} while (strategy.contentsLost());
}
any drawing will still be performed in the Swing Thread, so no matter what you try work around, it wont help.
Make sure you are not doing any lengthy calculations in the swing thread, this may be stopping repaint from being executed as soon as it needs to be executed
Separate all the logic into 2 parts. Static and Dynamic. (e.g. sea and moving ship. Ship changes shape/location on a static image of sea)
Draw static content in an image once and use the image in your paintComponent(). Call dynamic parts painting after the static image.
Use setClip() to restrict repainting areas.
Calling repaint without any arguments means that the whole panel is repainted.
If you need to repaint parts of the screen (the spaceship has moved to a different location) you should make shure that only those parts of the screen are repainted. The areas that stay the same should not be touched.
Repaint takes coordinates of a rectangle that should be repainted. When moving the ship you should know the old coordinates of the ship and the coordinates the ship should move to.
repaint( oldShipCoordinateX, oldShipCoordinateY, shipWidth, shipLength );
repaint( newShipCoordinateX, newShipCoordinateY, shipWidth, shipLength );
This is usually much faster than calling repaint() without arguments. However you have extra effort to remember the last position of the ship and must be able to calculate the new position of the ship.
See also: http://download.oracle.com/javase/tutorial/uiswing/painting/index.html - especially step 3
Just for code that you post here:
1/ if you want to display Image/ImageIcon, then the best and easiest way is to Use Labels
2/ as you mentioned Runnable{...}.start(); Swing is simple threaded and all output to GUI must be done on EDT; you have to look at Concurrency in Swing, result is that all output from BackGround Task(s) must be wrapped into invokeLater(), and if is there problem with perfomancie then into invokeAndWait()
3/ if you be switch (between JComponents)/add/delete/change Layout then you have to call revalidate() + repaint() as last lines in concrete code block
EDIT:
dirty hack would be paintImmediately()
I have read that the repaint() method is only a request, and it doesn't execute every time it's called
It consolidates multiple repaint() requests into one to be more efficient.
I believe I'm noticing the effects of this, as my spaceship tends to lag ever so slightly when I'm moving it.
Then post your SSCCE that demonstrates this problem. I suspect the problem is your code.
Regarding the solution you accepted, take a look at Charles last posting: Swing/JFrame vs AWT/Frame for rendering outside the EDT comparing Swing vs AWT solutions.
I'm writing a program to input a number and draw that number of circles of random color and location on an applet. I've been up all night trying to figure out how to add a delay between each of the circles appearing. Right now if I have a for-each statement with a delay in it, and say I input 20 circles and have a delay of 1000, it won't do anything for 20 seconds, then all the circles will appear at once, because the screen doesn't get refreshed until the end of the paint() method.
The only other alternative I could think of was to have a for-each statement in the start() method that would add a color and coordinate to an array, and have the paint() method draw all the circles in this array. I could be wrong, but I would imagine that this would use up way too much memory.
Another possibility would be to just add a circle on to the existing frame without clearing it, but I couldn't find a way to do this.
Use a javax.swing.Timer to add a new Circle object to an expandable list such as an ArrayList. Call repaint() after each addition. In paintComponent(Graphics) draw every Circle in the list.
Update
Unfortunately I cannot add comments at the moment (see External JS failed to load for the gory details). For that reason, I'm adding this as an edit.
#mKorbel: No I sure have not tried it on 1.6.0_26! If I'd tried it at all, I'd have posted the code. ;)
#Tycho: I did not notice you added the awt tag and presumed you were working with Swing.
Are you really using AWT? (If so.) Why?
#Tycho: "The only thing I could tell by quickly searching was that Swing is used more for user interfaces, which is not what I'm going for here."
Umm.. both AWT and Swing (using Applet/JApplet or Frame/JFrame) are used for developing Graphical User Interfaces. Or to put that another way, whether using AWT or Swing, or developing an applet or free-floating frame, you are developing a (G)UI.
Either the applet extends java.applet.Applet (AWT) or javax.swing.JApplet (Swing).
If your applet extends Applet, change it to a Swing JApplet. Few GUI developers can even remember AWT well enough to give good advice on it. My advice was all related to JApplet/Swing. It would not work using AWT.
Use a timer. For example, when you start drawing your circles, set a value:
time_press = System.currentTimeMillis();
circles_to_draw = 20;
Then somewhere in your draw method, do the following:
while(circles_to_draw > 0 && System.currentTimeMillis() < time_press + 1000)
{
time_press += 1000;
circles_to_draw --;
//Draw your circle
}
I have a custom UI drawn for my java application. Right now I draw the entire UI from scratch. I know for a fact some parts of the UI are static. I know I could save these static parts to an image, but will this yield a improvement in performance (Since even an image must be drawn every frame)?
Is it plausible to save a reference to the Graphics2D object after the UI has been drawn and assign that to the new graphics object every frame (starting from a point where all the static components are drawn)?
Thanks in advance,
Alan
You don't need to redraw everything in every frame. So if you have static parts of your UI (or even dynamic parts that you know haven't changed since last frame) then you simply don't need to repaint them.
In my code (Swing games and simulations mostly) I usually try to follow the following rules:
Pre-prepare static images (e.g. BufferedImage textures for UI elements)
Override the paintComponent() method for each UI element individually to do the painting
Only call the repaint() method of any given UI element if I know that something has changed
Call repaint() in a timer-based loop for animation, but only call it on the portion of the UI that is being animated (e.g. a nested JPanel)
This approach seems to work and perform pretty well (though I'd welcome comments if there are ways to improve it!!)
There are two main optimizations you can do here. The first is to make sure that when you cause your UI to be repainted, usually done by calling repaint, make sure you call the version of repaint where you specify a rectangle that has changed. Only make the rectangle big enough to encompass the parts that actually have changed, not the static parts. For this to be effective you also have to pay attention to the clipRect in the Graphics2D object you are passed in paint(). That is used by the system to tell you exactly what needs to be repainted, in the above case usually the rectangle that you passed to repaint. Don't paint anything that lies entirely outside that rectangle.
You can also get significant performance improvements by caching the static parts of your interface in an image. Writing an image is by far the fastest way of getting things onto a screen. My measurements indicate that small images are faster than even a few simple drawing primitives. However you need to make sure the image characteristics match the screen, by using createCompatibleImage().
Of course you may be using a lot of memory to get this speedup. I would recommend testing to see if you need to do image caching before implementing it.
if some parts of the screen is completely static, then never redraw that part. Don't do a full-screen/window clear, just clear the part of the screen/window that changes all the time.
This way, you don't unnecessarily redraw the static image.
I'm developing a fair sized hospital simulation game in java.
Right now, my pain method is starting to look a little big, and I need a way to split it up into different sections...
I have an idea, but I'm not sure if this is the best way.
It starts by painting the grass, then the hospital building, then any buildings, then people, then any building previews when building. The grass and hospital building will not change, so I only need to paint this once. The buildings themselves won't change very often, only when new ones are built.
I was thinking, use boolean values to determine which sections need repainting?
Ideal, id like to be able to split up the paint method, and then call each one when needed, but I'm unsure how to physically split it up.
I am still quite new to java, and learning on the go.
Thanks in advance.
Rel
Another idea is to create a super class or interface for all items that must be drawn on the screen. Lets cvall this class ScreenObject. You can then have a draw(Graphics2d g) method specified in the ScreenObject class. Next, each object that must be drawn implements the draw() method and is only concerned about drawing itself. You can even consider creating a variable that determines whether this draw method should be run at all.
In the main class that paints the screen you can have a reference to all ScreenObjects in an ArrayList and your paint() method will simply iterate over this calling draw() on each object.
I'm assuming from your description that your scene is split up into tiles. Keeping an array of booleans is a good way to keep track of which tiles need redrawn on the next update. A LinkedList might perform a little better in some situations. (I'm thinking of a Game of Life simulation where there are tons of tiles to redraw and you need to check each neighbor, so you may not need to go this route.)
Without seeing your code I can't give very specific advice on splitting up your paint method. I can tell you that in sprite animations, each sprite object typically has its own draw method that takes the main Graphics object (or more likely a buffer) as a parameter. Since the sprite should know its own image and location, it can then draw itself into the main image. Your paint method can then just loop through your list of sprites that need to be redrawn and call their draw method.
You might look to Killer Game Programming in Java for more detailed information.
Well I am not really an expert at programming but to split up my paint method Ive always just made a new method that takes a Graphics object and call that from paint, it has always helped me to keep my code organized but I have never had a big project like it sounds you are working on so it might not work for your situation.