Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  clip an image  (Read 7839 times)
0 Members and 1 Guest are viewing this topic.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #30 - Posted 2006-05-24 02:03:57 »

> Basically, I just do getSubImage on a different image instead of the one used by "mode 0".

I meant to say that I do getSubImage on a different image instead of the one used by modes other than
"mode 0".

Also, you might want to change '+' to add like 500 sprites, otherwise it takes a while to get
to the point when the fps falls to less than 60  =)

Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #31 - Posted 2006-05-24 02:28:23 »

And regarding the clipping mode. It will be slower because we'll need to update/calculate the clip
for each sprite.

So, in short - the drawImage(srcRect,dstRect) should be the fastest.

Dmitri
Offline woogley
« Reply #32 - Posted 2006-05-24 02:37:50 »

thanks dmitri! nice to see some clues to these mysteries..

for sake of argument, I took your change a step further: I separated the Subimaging and Clipping/drawImage tests into 2 applications. take a look...

however, @1000 sprites, Subimaging is at 44FPS while Clipping lags behind 19FPS... what's going on here?

edit: adding/substracting sprites are now at 15 intervals, as you pointed out, +1/-1 was too slow Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #33 - Posted 2006-05-24 04:11:48 »

I was running the test on Mustang with Direct3D pipeline enabled, so I didn't notice the
problem with clipped images and the default pipeline..

Basically, if you're using 5.0, or 6.0 with d3d pipeline disabled, you're using
DirectDraw acceleration. And we have this funny (rather arbitrary) restriction
on the size of 1-bit transparent images that we can accelerate. If
a 1-bit transparent image with DirectColorModel has size larger than
65536 we don't accelerate it. Your sprite.png is 576 * 128 = 73728 so it doesn't
get accelerated. (for those interested, the offending file is WinCachingSurfaceManager.java,
take a look at Mustang's code on http://mustang.dev.java.net). The restriction has to do with the algorythm
used for calculating a pixel which can be used for masking with DirectDraw's blit operation.
If the image is too large, it takes too long to calculate.

The direct3d and opengl pipelines don't have this restriction.

Workaround is rather simple. Do not convert your image after loading. The restriction above
is only applicable to images with DirectColorModel. Your image is 8-bit, so it will be IndexColorModel, so it will
get accelerated. Anyway, as of 5.0 all images could potentially be accelerated, no need for converting them to a "compatible image"
as in 1.4 days.

So, in your loadImage() method just return 'b'.

Thanks,
   Dmitri
Offline Alexian

Senior Newbie





« Reply #34 - Posted 2006-08-30 05:00:08 »

Hi! I come from Italy and I'm working on a project about Java2D for university.
I'm developing a game and I want to know if my "drawing-engine" is good or not.

I do not know how you create a Sprite but in my case I create an ArrayList of BufferedImage and each element is a Frame of this Sprite. Every n milliseconds the Frame changes and is drawn with drawImage(...) of a Graphics with a double-buffering strategy. The game with 640 by 480 resolution goes well, but can I do something else to increase the performance? Ah I also use the getSubImage() method to draw parts of the sprites (always using drawImage() in this way g.drawImage(image.getSubImage(0, 0, 20, 20), 0, 12, null)).

Thanks in advance for all replies!
Offline Alexian

Senior Newbie





« Reply #35 - Posted 2006-09-01 16:09:02 »

Nobody knows?
Offline campbell

Junior Member




Java games rock!


« Reply #36 - Posted 2006-09-01 17:33:52 »

Ah I also use the getSubImage() method to draw parts of the sprites (always using drawImage() in this way g.drawImage(image.getSubImage(0, 0, 20, 20), 0, 12, null)).

Don't use getSubimage() for this case, it will defeat image acceleration.  Instead use the variant of Graphics.drawImage() that takes both src and dst parameters:
http://download.java.net/jdk6/docs/api/java/awt/Graphics.html#drawImage(java.awt.Image,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20java.awt.image.ImageObserver)

So taking your example:
g.drawImage(image, 0, 12, 20, 12+20, 0, 0, 20, 20, null);

We really should add an item to the FAQ about this.

Chris
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #37 - Posted 2006-09-01 18:39:16 »

Quote
We really should add an item to the FAQ about this.

Or fix this bug, as well as the whole getScaledInstance mess.
Why can't these methods be implemented just by doing what you describe - creating a new bufferedimage, copy/scale the stuff and return it?

lg Clemens
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #38 - Posted 2006-09-04 20:30:38 »

Quote
Why can't these methods be implemented just by doing what you describe - creating a new bufferedimage, copy/scale the stuff and return it?

Because of backward compatibility.

Currently both parent image and subimage share single data buffer.
So any changes you make to any of them is reflected in another.
If we do what you suggest this will be broken.

Dmitri
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #39 - Posted 2006-09-04 21:11:01 »

Quote
Why can't these methods be implemented just by doing what you describe - creating a new bufferedimage, copy/scale the stuff and return it?

Because of backward compatibility.

Currently both parent image and subimage share single data buffer.
So any changes you make to any of them is reflected in another.
If we do what you suggest this will be broken.

Dmitri


Thats an interesting bit of info!
getScaledInstance makes no mention of it sharing the parent images data buffer!

It'd be nice for the javadoc to :-
a) document all the methods behaviour, and
b) be marked as deprecated regardless.
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 #40 - Posted 2006-09-07 15:49:44 »

Currently both parent image and subimage share single data buffer.
So any changes you make to any of them is reflected in another.
If we do what you suggest this will be broken.

A thanks for clearifying this - I've never heard about this behaviour in the past, but I thought it must be something about compatibility ;-)
I still use getScaledInstance because I need to stay 1.1 compatible - and to be honest I don't know howto archive the same with BufferedImages - and because to archive the smooth-scale effect I would need translucent images I would not get accaleration anyway.
Maybe someone could add another method, or with different parameters getSalesInstance(...., boolean shareBuffer) - so that people don't use getScaledImage accidentially.

lg Clemens
Pages: 1 [2]
  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.

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

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

Riven (6 views)
2014-07-23 20:56:16

ctomni231 (40 views)
2014-07-18 06:55:21

Zero Volt (36 views)
2014-07-17 23:47:54

danieldean (30 views)
2014-07-17 23:41:23

MustardPeter (32 views)
2014-07-16 23:30:00

Cero (47 views)
2014-07-16 00:42:17

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47
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!