Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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  
  Alpha shapes are slow.  (Read 2930 times)
0 Members and 1 Guest are viewing this topic.
Offline thedracle

Senior Newbie

Java games rock!

« Posted 2003-01-28 13:23:14 »

Drawing semi-transparent shapes with an alpha comonent is SLOW SLOW SLOW.

I really can't understand where the bottle-neck is now. I'm drawing semi-transparent shapes (About 20 every frame), and my frame-rate is suffering horribly due to it. I'm getting around 9 FPS, and without the shapes being drawn at least 29-32 FPS (Which is what I'm shooting for). Any suggestions?

-Jason Thomas.
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #1 - Posted 2003-01-28 14:00:29 »

Of course they are slow!! Transparency is *extremely* hard to accomplish if not supported by hardware.

So if you really need it, head for using a 3D accelerator.

Ahm, or try doing it yourself! Would need to specialized and easy to handle color format (indexed, or 24bit RGB?), specialize on certain transparency levels and then write pixel-setting routines. This will enligthen you how difficult it can be doing it fast.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Abuse

JGO Ninja

Medals: 66

falling into the abyss of reality

« Reply #2 - Posted 2003-01-28 16:08:53 »

also, if your drawing onto a VolatileImage (that includes BufferStrategy rendering) performance will absolutely die.

if you *have* to use an AlphaChannel (or AlphaCompositing), make sure all your images are in main memory. (not vram)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline thedracle

Senior Newbie

Java games rock!

« Reply #3 - Posted 2003-01-28 16:57:20 »

Ugh.. So it doesn't just use a BITMASK in the background? I mean.. You'd think it would just draw every other pixel in it's routine, rather than actually drawing transparent pixels. Also, is using a BufferedImage risky? I know as a fact often these Images will be implemented as an "Automatic Image", meaning sometimes it may be using a VolatileImage in the background. Perhaps I should just use a regular image.

-Jason Thomas.
Offline Captain-Goatse

Junior Devvie

I suck at teh 2D. XBOX IS BIG LOL!111

« Reply #4 - Posted 2003-01-28 18:00:45 »

I found out that the best way of doing this was making gifs manually transparent in the file.

Just draw every other pixel transparent, but this only work on reasonably high resolutions AND the hardware acceleration(?) disappears if you turn it into bufferedImage, or at least did for me in certain areas. Yes it is frustrating, but at least you have an option.
Offline Abuse

JGO Ninja

Medals: 66

falling into the abyss of reality

« Reply #5 - Posted 2003-01-28 21:15:32 »

IMHO automatic images are the best solution
( graphicsConfiguration.createImage(width,height,[Transparency.OPAQUE|Transparency.BITMASK]) )

here are my reasons...

1) automatic images are *almost* as fast as VolatileImages (ive benchmarked the 2, the difference realy is negligable)

2) automatic images support bitmask transparency (impossible with VolatileImage in the current 1.4.1_01 api)

3) automatic images handle the loss of their vram surface automatically, hence, less code.

4) if you draw an automatic image and perform a software operation (such as AlphaCompositing) the version of the automatic image in main memory is used.
If you do the same with a VolatileImage, the performane hit is very dramatic (the image has to fetched from vram, the operation performed, and the image copied back to vram)

i've got a little app. that demonstrates these issues.

its got all sorts of options, 1 of the most interesting, is this :-

set the imageType to VolatileImage
the buffering mechanism to BufferStrategy
and turn on AlphaCompositing

then, compare it to the speed of this :-

imageType automatic image (masked or unmasked)
buffer strategy to Normal
AlphaCompositing on as well

IMHO, VolatileImage should be ditched from the API, and hardware acceleration should be done behind the scenes.
In its current state VolatileImage is useless, and until all pixel operations have hardware support enabled, it always will be.

Pages: [1]
  ignore  |  Print  

EgonOlsen (79 views)
2018-06-10 19:43:48

EgonOlsen (59 views)
2018-06-10 19:43:44

EgonOlsen (78 views)
2018-06-10 19:43:20

DesertCoockie (261 views)
2018-05-13 18:23:11

nelsongames (159 views)
2018-04-24 18:15:36

nelsongames (158 views)
2018-04-24 18:14:32

ivj94 (901 views)
2018-03-24 14:47:39

ivj94 (162 views)
2018-03-24 14:46:31

ivj94 (813 views)
2018-03-24 14:43:53

Solater (177 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!