Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Applet/frame low fps problem  (Read 2745 times)
0 Members and 1 Guest are viewing this topic.
Offline JESTERRRRRR

Senior Member


Medals: 7
Exp: 1 year



« Posted 2011-03-16 20:15:38 »

Hi, I'm relatively new to Java, but can't get my head round this.

I was creating a 2d game engine, but was noticing very low fps when the applet size was increased. I created an new applet that has size of 1200x800. The applet only fills a black rectangle, draws it onto a bufferedImage, then draws the bufferedimage, using the overriden 'update()' method. It gets approx 45-51 fps.

I then created a non-applet version extending JPanel. This does the same, and gets 47-80fps.

These fps ratings go down with larger screen size, but I want a large screensize. The codes are very short; can anyone tell me what I'm missing here? What have I completely missed out on? I refuse to believe this is the best fps I can acheive. Drawing layers from images at fullscreen I got down to 19fps. I also tried drawing several smaller boxes onto the screen at different points, same problem.

The applet version: http://pastie.org/1676959
JPanel: http://pastie.org/1676965
Offline ra4king

JGO Kernel


Medals: 340
Projects: 2
Exp: 5 years


I'm the King!


« Reply #1 - Posted 2011-03-16 21:12:06 »

Use Canvas to draw into for both applet and desktop. Then you can use BufferStrategy since that is faster than using BufferedImage because BufferStrategy uses page flipping (changing the memory pointer of the image) while BufferedImage uses page blitting (copying the image bit by bit).

Hope that helped Grin

Offline philfrei
« Reply #2 - Posted 2011-03-17 00:19:48 »

I am wondering about a few things:
1) what is happening in the fpscounter code? (Side note: usually a Class starts with a capital letter.)
2) maybe it would be faster to use setBackground and clearRect than to draw the black background?

1  
2  
   g2.setBackground(new Color(0,0,0)); 
   g2.clearRect(0,0,width,height);  //assumes you've set width, height to the desired size

3) maybe since all the drawing is occuring within paintComponent anyway, simply draw directly onto the graphics object instead of drawing to your buffer and then copying from the buffer to the graphics object? This also avoids the blitting mentioned by ra4king.

Note that you can pass the update's or paintComponent's graphic object to draw methods that you create for anything that needs to be drawn. For example, consider that you can define a public method such as: fpscounter.draw(Graphics2D). Then, in your update/paintComponent code, make FPS.draw(g2) a statement. (Side note: usually an object name starts with a lowercase letter.)

I haven't tried drawing directly on an Applet, myself. I've only used JApplet and drawn on a JPanel within that. It's not necessarily the fastest way to do things, but Java is fast enough that even so I've gotten good fps rates.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 340
Projects: 2
Exp: 5 years


I'm the King!


« Reply #3 - Posted 2011-03-17 02:47:19 »

@Philfrei
There is nothing wrong with his code. He could not make it any more efficient (unless FPS.tick() is the problem, but I doubt it is).
First, in the JPanel example, you can directly draw into 'g' since JPanel is automatically double buffered so no need to use BufferedImage.
Second, there is technically nothing wrong with your code. However, there is a reason why there is paint(Graphics g) Tongue

Offline JESTERRRRRR

Senior Member


Medals: 7
Exp: 1 year



« Reply #4 - Posted 2011-03-17 03:12:20 »

Thanks for your help guys. I had no idea about this blitting, completely explains the larger resolution! I'm gong to re-construct it with the canvas and bufferstratergy, and all being well apply this to my project.

My tick() just increases a variable, checks to see if time between start and current time is > 1000ms then resets start time and the variable. Nothing fancy, whipped it up quickly to see what was going on.
Offline ra4king

JGO Kernel


Medals: 340
Projects: 2
Exp: 5 years


I'm the King!


« Reply #5 - Posted 2011-03-17 03:22:29 »

Also remember next time you want to use any Swing component to draw into, they are automatically double buffered.

For Canvas, you don't even need your own extended Canvas class. You can just create a new Canvas object, add it to the JFrame, and use it's BufferStrategy to draw.
http://ra4king.is-a-geek.net/javadocs/java/awt/Canvas.html
http://ra4king.is-a-geek.net/javadocs/java/awt/image/BufferStrategy.html

Offline philfrei
« Reply #6 - Posted 2011-03-17 06:08:15 »

@ ra4king -- Well excuuuuse me!  Wink

If you set the background color in the constructor, setBackground(Color.black); for example, you avoid an unnecessary setPaint command, since you can use clearRect. That seems like a small but real efficiency.

Also, I've never seen a Java tutorial that cleared or initialized a graphics area via a fillRect. In the Java Tutorials Graphics2D section they always use clearRect. Do you know why? I don't. Maybe there is no difference, but as I said in my suggestion, "maybe"!

I don't understand why you say to ME "he can't make it any more efficient" then suggest drawing directly into the graphic object (as I did). Doing so eliminates the creation of an unneeded BufferedImage and the elimination of an unneeded drawImage command. Yes? I can't (and didn't try to) say how significant this might be. I voiced them as suggestions as things to consider.

Pax

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Offline ra4king

JGO Kernel


Medals: 340
Projects: 2
Exp: 5 years


I'm the King!


« Reply #7 - Posted 2011-03-17 06:14:40 »

clearRect and fillRect do the same thing except one uses the background color and the other uses the current set color, respectively.

Plus I meant the Applet one is fine. The JPanel example is the one that needs fixing Grin

Offline JESTERRRRRR

Senior Member


Medals: 7
Exp: 1 year



« Reply #8 - Posted 2011-03-21 23:31:16 »

I fixed the JFrame as suggested, it runs awesomely. What sort of buffering is it using? It works even when I draw 3 different fullscreen sized images every frame.
Offline Captain Awesome

Junior Member


Medals: 2


Hi


« Reply #9 - Posted 2011-03-21 23:54:08 »

clearRect and fillRect do the same thing except one uses the background color and the other uses the current set color, respectively.

Plus I meant the Applet one is fine. The JPanel example is the one that needs fixing Grin

If I recall correctly, fillRect just paints over the specified rectangle with the color while clearRect replaces the pixels with the background color (try this with partly transparent colors)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline IronclawsBt

Junior Member


Medals: 1



« Reply #10 - Posted 2011-03-22 00:03:21 »

clearRect and fillRect do the same thing except one uses the background color and the other uses the current set color, respectively.

Plus I meant the Applet one is fine. The JPanel example is the one that needs fixing Grin

If I recall correctly, fillRect just paints over the specified rectangle with the color while clearRect replaces the pixels with the background color (try this with partly transparent colors)

From the JavaDoc "Beginning with Java 1.1, the background color of offscreen images may be system dependent. Applications should use setColor followed by fillRect to ensure that an offscreen image is cleared to a specific color".

You can setBackground from Graphics2D or for the underlining component to control this. I don't know if there is any performance difference between the two operations.

It's not what you know, it's what other people think you know.
Just hope you don't get quizzed on it.
Game engine design tutorials
Offline ra4king

JGO Kernel


Medals: 340
Projects: 2
Exp: 5 years


I'm the King!


« Reply #11 - Posted 2011-03-22 02:24:56 »

Just to note something, if you're gonna use BufferStrategy, there is no need to clearRect or fillRect since the screen is automatically filled with the background color.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (8 views)
2014-07-30 21:08:39

Riven (20 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!