I looked a lot in the internet but somehow couldn't find any benefits to always clear the screen in the render method or didn't understand it very well.
So what's the benefit from clearing the screen wouldn't clearing somehow cause the game to draw everything from scratch each time the render method is called?
If you have a game with at least one moving thing, not clearing the screen will cause the sprite (if you're using a sprite) of the thing to be in every place it has been in past frames. Usually you clear the screen to remove past drawn stuff and redraw with updated positions. You could program some logic to know whether stuff has moved and avoid clearing the screen but I don't think clearing the screen's computational cost is high enough for the effort.
Below is an example of the effect caused by not clearing the screen each frame.
Edit: As Tenfour04 stated, there is another good reason for clearing the screen: Perfomance.
Libgdx, like almost all game engines, uses double buffering, which means that while one frame is being rendered to screen, it is already drawing the next frame to another frame buffer. If you don't clear the screen, it has to wait and then copy the contents of the first buffer into the second before it can start drawing to it. So it wastes GPU time copying and also prevents the multitasking that saves some time
Related
I need some help with a Java assignment I have, I'm required to build a clone of Pac-Man.
The problem is, I don't know how to draw the movements of the Pac-Man or the Ghosts. I'm thinking I should only draw the walls once, and continiously redraw the characters, but I don't know how I should do it or what methods of drawing I should use.
Generally speaking, it is no good idea not to redraw the complete GUI of any game you write several times each second (the quotient of complete redraws over a second is referred to as the 'frame-rate' of a game). If you do not do this, you might observe weird effects like: The contents look strange if you resize or move the window in case its not displayed in full-screen, there might by weird graphical effects, and, most important, the images of your game-characters won't disappear at their previous positions, if you do not draw the background over them again.
Common approach is to set up a Thread that is not doing anything else but invoking some redraw methods about 60 times each second (60 fps (frames per second) appear fluent to the human eye as our temporal resolution lies in that scale) and to use another Thread that updates the position data of the characters and passes it to the draw-Thread together with the static wall-position-data.
This might be a weird question but what is the right way to think about how images are projected onto the screen?
if we have an image already on the screen and we render another image onto the screen does the new image go ON TOP of the old one, thus making the old one not visible anymore. or does it go behind the old one thus making the new one not visible till we clear the screen off of the old one.
I used to think that the new image goes on top of the old one, however, after working with buffers for a little bit (ie BufferedImage and BufferedStrategy) I come to think that is not the right way it happens.
so can someone please clarify this matter
thanks
Generally speaking, you can think of it like a painters canvas. Every time you paint something new you are painting over the top of what is there.
When dealing with buffers, the process is the same, but know you are dealing with whatever was painted last to THAT buffer.
So if you have three buffers, [1] is on the screen, you are painting [2] which gets pushed to the screen, it doesn't have the content of [1], but what was ever painted to [2] when it was painted last...
So you have [1][2][3], then you have [2][3][1], then [3][1][2]. Each buffer will be out of date by at least two paint cycles.
This is why it's important to clear you buffers and rebuild them from scratch each time, as you don't know the last time a buffer was painted
It depends on what and how you are drawing.
The screen "refreshes" itself at a certain rate, (for example 60 times a second). At that point whatever the graphics card has in its memory gets drawn.
There are lots of different ways of putting things into that graphics card memory though and they have different behaviour.
BufferedImage does not directly go to the screen. Instead it's "copied" into the graphics card and that is used to draw to the screen.
Swing hides all that away from you though - you just need to worry about the repaint and it will handle the rest. The actual handling of this comes from the Control you are using, for example JButton, JPanel, etc.
I'm creating a simple Breakout game and I've encountered a couple of problems.
First off, I need to render the bricks, the paddle, etc... I need to generally render everything on the screen that's needed. However, I don't want, for example, the bricks to continuously render; you can see where the render is occurring as it happens. There's a flash of white.
So, my question is: is it possible to render only certain objects, or more specifically, only render what needs to be rendered?
Every time I call repaint(); I don't want the whole screen to clear and repaint.
Just a forewarning: I'm new to java - I normally use UnrealScript and C# but I'm branching out, so there is likely one or two things I've done incorrectly or against the normal java convection (that would be more in align with convictions of those other two languages)
Feel free to point them out, and I'll mold myself to them accordingly
I'm making a JRPGish style game in java using BlueJ. I'm not aiming massively high, and am more doing it as a proof-of-concept rather than a full blown game.
So far its going ok. I'm got a sprite animation working using a sprite sheet and the player can walk around with the sprite changing to the correct animation depending on the direction.
However I'm having an issue when the player stops moving - there sometimes is a afterimage of the previous frame - In fairness, this may be happening all the time except you cant see it if the player stops moving on the first and last frame of the walking animations, as those take up the same pixel space and thus are hidden (if that makes sense)
Here is an image of the issue in action:
This is after the player has moved, and then stopped, leaving the last frame of the "moveRight" sprite behind.
I have created a small version of my project that has just the character animation playing when you press a key, and stopping when you release, in which the issue appears
The Skeleton class
The Character class
The GameManager class
The KeyManager class
To start the game run the Main method in GameManager
You'll need to save this image with the filename of "James.png" and place it in the same folder of the java project for it to work
Thanks in advance for any help given.
paintComponent() passes Graphics to drawCharactor(). drawCharactor() should not disposes that Graphics object unless you made a copy, this Graphics is shared.
Also, do not call repaint() from drawCharactor(). repaint() schedules another paint cycle. You already do call repaint() from a timer.
Do not use java.util.Timer use javax.swing.Timer for Swing painting. See How to Use Swing Timers
For more information and examples Performing Custom Painting and Painting in AWT and Swing.
Consider posting a minimal example.
I am currently in the process of making a tile based 2D platformer using lwjgl. I have a character that is able to run and jump all around the map. I have run into a strange problem when moving the window. When I move the window the game will freeze which isn't a big deal because when you let go it unfreezes, but after it unfreezes my character will end up moving down a number of tiles based on how long you hold the window or move the window for. Is there anything i should know about the library and the display, or do you need to see the code for the window initialization or the physics and collision detection? I have no idea why the movement of the window would have anything to do with the players position!
Solution:
After quite a lot of thought and attempts to fix the problem, I had realized that i am using a delta in my update methods, because delta is calculated by the time between each update, because the game freezes when the window is "moved" or "grabbed" the delta value becomes very large in a short period of time causing the player or object to be moved a very large amount at once. To fix this i simply put a limit on the delta value that gets passed into my update methods so that the player would not be able to move 10+ tiles at a time.