clip an image

[trembovetski]

> 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

[trembovetski]

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

[woogley]

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...

• Subimaging.jar [source]
  
• Clipping.jar [source]
  

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

Games published by our own members! Check 'em out!

[trembovetski]

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

[Alexian]

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!

[Alexian]

Nobody knows?

[campbell]

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

[Linuxhippy]

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

[trembovetski]

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

[Anon666]

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!

[Linuxhippy]

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