Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Acceleration for 2D rendering  (Read 3463 times)
0 Members and 1 Guest are viewing this topic.
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Posted 2005-04-16 13:53:47 »

Hello, I'm writing a 2D game (surprise). Presently sprites are drawn using fillPolygon. It is necessary to rotate, scale and translate these from an abstract map to the screen, and for this I use AffineTransforms. Also, in order for the polygons to be rendered acceptably I have enabled antialiasing.

The problem is that these simple operations seem to be done in software, and framerate quickly falls below 20 if multiple sprites are visible. I have tried enabling the "opengl pipeline", but this seems to make no difference. It appears that antialiasing is by far the most demanding aspect of this.

How, then, is it possible to accelerate rendering? It must *surely* be possible since 3D graphics are so much more complicated and still work quite efficiently.

Tell me if I should post some code.
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #1 - Posted 2005-04-16 14:41:12 »

Well, 2D is not 3D. Antialiasing is extremly expensive and is even with OpenGL enabled done in software.

Where do you render to? To screen, managed image or VolatileImage?

lg Clemens
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #2 - Posted 2005-04-17 21:07:27 »

Thanks for the reply.

Rendering is presently done in a JPanel using paintComponent(Graphics). Swing automatically supplies double buffering, but I do not know exactly how it accomplishes this (i.e. whether it internally uses a Buffered- or VolatileImage). Maybe I should consider using a Canvas (which seems to be a popular way of rendering custom graphics) and then manually specify a BufferStrategy?

By the way, I tested the program with 1.4.2, and this actually further degraded performance significantly! This suggests that the rendering is at least partially accelerated in 1.5.0.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #3 - Posted 2005-04-18 08:29:56 »

ah, I re-read your post and now its clear:

If antialiasing is used, no accerlation at all will take place, regardless the pipeline you use (exception OGL).
I have seen better performance when using teh OGL on my system (compared to X11), OGL only does some things in HW and some in SW.

The only advice I can give you is to turn AA off and maybe use the rotate-methode of Graphics2D instead of AffineTransform (but not 100% sure about this).

lg Clemens
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #4 - Posted 2005-04-19 01:48:26 »

Quote
rotate-methode of Graphics2D instead of AffineTransform (but not 100% sure about this)


There's no difference between using G2D.rotate() and G2D.setTransform()..

AA rendering is not accelerated in 1.5, but there were other performance improvements in 1.5 which probably attributed to better performance.

It's strange that enabling opengl pipeline didn't help. Are you sure it was being used? Try with -Dsun.java2d.opengl=True (with capital T), it'll say if it was enabled or not.

There are known performance issues with opengl (mostly because of drivers), though.

Thanks,
 Dmitri
Java2D Team
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #5 - Posted 2005-04-20 17:39:52 »

Thank you, and excuse my lateness. My harddrive started making funny noises so I had some backup to do  Shocked

After some brief experiments, the OGL pipeline seems to be solely responsible for the increase in performance in 1.5.0 over 1.4.2 (this is in Linux using an nVidia card). Disabling the pipeline yielded a framerate identical to that of 1.4.2! The lack of performance increase before might be due to some mistake, or maybe because things were different in Windows (directX and whatnot).

I'm still disappointed about the performance though, let's hope AA will be accelerated some day.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #6 - Posted 2005-04-21 01:34:02 »

Wait, I'm confused. If you're using the opengl pipeline, then AA is accelerated.

Dmitri
Offline HopeDagger

Junior Newbie




...


« Reply #7 - Posted 2005-04-21 01:41:48 »

Sorry, some confusion on my behalf: are rotated/scaled images accelerated by the OpenGL pipeline?
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #8 - Posted 2005-04-21 08:02:52 »

Quote

Wait, I'm confused. If you're using the opengl pipeline, then AA is accelerated.

Well, I the OGL-pipeline-bog said that its not "really" accerlated. At least there are a lot of software-loops working in background...

Quote

Sorry, some confusion on my behalf: are rotated/scaled images accelerated by the OpenGL pipeline?

Well, scaled images are accerlated as far as I know, if you scale them at drawing. I don't know about rotating...

lg Clemens
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #9 - Posted 2005-04-21 12:58:07 »

Oh, AA *is* accelerated with the pipeline?

Anyway, to clear things up here's a screenshot:

http://www.student.dtu.dk/~s021864/screen.png

Drawing consists of fillPolygon (each ship hull polygon consists of 26 points, for example), fillOval and drawLine  except for the explosions which are images.

The pipeline is used, and the computer is an AMD 1200 MHz with a GeForce 4 MX440. The framerate is capped at 50, but is presently (two ships) only 25. Since an arbitrary unit in Warcraft 3 is more complicated than the entire screen here, it seems reasonable that there should be a more efficient way.

I just reread
http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html
which deals with some of these things.

So, er, any ideas? I know this is very vague. By the way, if you look at the screenshot, notice how ugly the "circles" in the radar panel are. When I don't use the pipeline they look quite nice and circular. Is there a way to fix this?

HopeDagger: the above document states that the following imaging operations are accelerated:

simple copies (e.g. drawImage(img, x, y, null))
simple scales (e.g. drawImage(img, x, y, w, h, null))
arbitrary transforms (e.g. drawImage(img, xform, null))
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #10 - Posted 2005-04-21 13:25:59 »

Why do not blit the ships, this would especially help with the OGL pipeline a lot!

Since you want them to be rendered antialiased this partially explains your bad performance, if you would use pre-drawn ships I think you could tripple your performance. Anyway, turn AA OFF!

Quote

Since an arbitrary unit in Warcraft 3 is more complicated than the entire screen here, it seems reasonable that there should be a more efficient way.

Wowow - you completly mix two things. Warcraft is completly 3D, there is a bit difference between doing it in 3D or raping 3D api's and guarantee that it does look equal.
Another problem is, that your graphic card is quit suboptimal for use with the OGL pipeline, believe me, I've the same ;-)

Here my tip of the day:
try to start your program with "-Dsun.java2d.trace=log or = count" and see which operations occur how often.
If there are a lot operations with java2d.loops or SwToSurfaceBlit in it, you're definitivly doing something wich bothers the OGL pipeline a lot.

Very-fine are TextureToSurface blits and the whole OGL?Huh? commands ;-)

lg Clemens
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #11 - Posted 2005-04-21 18:45:42 »

I have actually tried using images, but decided to use polygons instead "to increase performance". I thought the polygons would be faster since all the pixels have the same colour.

Images, however, do introduce some problems. When I use the pipeline in Linux, interpolation of the rotated images is messed up along the image boundaries. To be exact, white pixels appear along the boundary (they are probably interpolated from "outside" the image which is, per default, white)! This problem appears while using Nearest Neighbor as well as Bilinear interpolation, but not while using Bicubic (bicubic is, however, out of the question because of complexity among other things).

One solution would be to disable the pipeline, since bilinear interpolation seems rather efficient without.

Still, another drawback of images is that the movement appears very jaggy since images are centered on pixels, whereas corners of polygons with AA are simply drawn "between" pixels. (EDIT: solved easily by applying floats in an AffineTransform!)

I will try logging the OGL output as you suggested soon.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #12 - Posted 2005-04-22 03:28:08 »

Arbitrary transforms _are_ accelerated with the opengl pipeline.

Anyway, check out Chris' article about the pipeline:
 http://today.java.net/cs/user/print/a/147

And the followup about the Singl Thread Rendering:
 http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html

Thanks,
 Dmitri
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #13 - Posted 2005-04-22 11:21:32 »

I have now rendered the polygons and ovals that make up a ship onto a BufferedImage using antialiasing such that it looks nice around the ship edges, and the images are rendered onto screen with bilinear interpolation. This vastly increases performance, while everything looks just as nice as before! I have tested the performance with around 40 ships on the screen, and saw framerates in excess of 40, which is good since it is capped at 50.

It is interesting that antialiasing is so slow while bilinear interpolation is so fast.

As stated before there is a problem with the edges of the images while using linux. This is probably due to bad drivers, but we'll have to see about that.

Thanks a lot to LinuxHippy for the suggestions, and to Dmitri for the info on the pipeline.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #14 - Posted 2005-04-22 21:09:48 »

I believe the problem with the sprite edges is fixed in the latest mustang build (b33).

Dmitri

Offline tusaki

Junior Member


Medals: 1


In a mad world only the mad are sane.


« Reply #15 - Posted 2005-04-28 07:25:25 »

Hi Hjorth_Larsen,

I've had great results by just dumping the AWT/Swing framework and using OGL directly via JOGL. It can do anything, and it's so much faster, it's not even in the same race.

https://jogl.dev.java.net/

Regards,
- Vincent
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #16 - Posted 2005-04-29 22:17:30 »

I believe the problem with the sprite edges is fixed in the latest mustang build (b33).

Dmitri


I installed Mustang b33, but it does not fix the problem. I can supply screenshots and some hardware info if anyone is really interested, but presently I just disable the pipeline by default and rely on the increased performance from bilinear interpolation.

Thanks, Vincent, for the suggestion. In the near future I will stay with Swing, but in the long run I may take a deeper look at JOGL.

Ask
Offline tom
« Reply #17 - Posted 2005-04-30 08:53:32 »

You can fix the sprite edge color bleeding by going over every pixel and set the color of the transparent pixels to the average of it's opaque neighbours.

Since I've been using OpenGL alot, I don't consider the edge bleed a bug. It's just how it works.

Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #18 - Posted 2005-04-30 13:13:24 »

Quote
You can fix the sprite edge color bleeding by going over every pixel and set the color of the transparent pixels to the average of it's opaque neighbours.


Yikes, that sounded very scary. None of the transparent pixels in question even have opaque neighbours, except of course the background of the screen on which the images are rendered - but it's impossible to keep track of that, what with the numerous transformations and such. I took care to have only opaque pixels near the Image boundaries, such that the bilinear interpolation could work correctly.

Are you quite sure that we are talking about the same problem? I did some searching for "color bleeding" but didn't find anything that looked like my problem. Maybe I should stress that the problem is on the image boundaries, not on the edges between opaque and transparent pixels.

Thanks for the tip though.

Ask
Offline tom
« Reply #19 - Posted 2005-04-30 13:51:49 »

My mistake. I was thinking of another "bug" that has been fixed in mustang. Where the color of transparent pixels bleed over when using bilinear.

Your probably seeing some lack edge clamping. Don't know of any workaround for that though Sad

Offline campbell

Junior Member




Java games rock!


« Reply #20 - Posted 2005-05-01 17:42:37 »

Quote
I believe the problem with the sprite edges is fixed in the latest mustang build (b33).

Dmitri


I installed Mustang b33, but it does not fix the problem. I can supply screenshots and some hardware info if anyone is really interested, but presently I just disable the pipeline by default and rely on the increased performance from bilinear interpolation.
Ask


Hi Ask,

The bug Dmitri referred to is this one:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5009033

This bug actually has not been fixed yet in Mustang.  The evaluation for that bug goes into more detail about why it's not easy to fix.  (OpenGL doesn't make this easy when the image has non-pow2 dimensions.)  I really hope to have it fixed in Mustang, as it can be a very distracting artifact.

Thanks,
Chris.
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #21 - Posted 2005-05-06 14:15:47 »

Thank you, campbell!

I know almost nothing about OGL, so I cannot understand much of the bug report - but I changed the dimensions of the Images in use to powers of 2, which completely solved the problem. All rendering is now nice and fast.
Offline Grazer

Junior Member




My other avatar is much more flattering.


« Reply #22 - Posted 2005-05-13 03:41:48 »

Quote
I changed the dimensions of the Images in use to powers of 2, which completely solved the problem. All rendering is now nice and fast.

Did using pow2 images give any speed increase or did it just fix the problem?

Current Project: Easy Decal
Other Stuff: grlea online
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #23 - Posted 2005-05-16 10:49:45 »

Quote
Did using pow2 images give any speed increase or did it just fix the problem?


I have not checked this. The program presently runs as dictated by a timer, and I'll have to rewrite some stuff in order to test how quickly it will actually draw once it surpasses the capping framerate. It'll probably be simpler (and more accurate because of other tasks running in the program) to do tests in a separate program. If you make a test, be sure to supply the results here. I don't have time right now to do the test, but maybe sometime later.
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.

BurntPizza (8 views)
2014-09-21 01:30:30

BurntPizza (9 views)
2014-09-21 00:34:41

moogie (10 views)
2014-09-21 00:26:15

UprightPath (23 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (40 views)
2014-09-12 09:08:26

Norakomi (70 views)
2014-09-10 13:57:51

TehJavaDev (96 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!