Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
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  
  What is better for animation?  (Read 1613 times)
0 Members and 1 Guest are viewing this topic.
Offline Graziano Mesina

Senior Newbie





« Posted 2006-09-24 13:56:37 »

Hi, I would create an animation with some frames for my game entities.

Is better to create

an Array of images
or
a single image that will contain all frames and then call methods
[CODE]
g.setClip((int)x,(int)y,image.getWidth(null) / numFrames,image.getHeight(null));         
g.drawImage(image,(int)x - frameCorrente * image.getWidth(null) / numFrames,(int)y,null);
[/CODE]

 Huh Huh

-Montanelli-: Ma lei evadeva quasi sempre, no? <br /><br />-Mesina-: Sì, ho la fortuna di avere i polsi più grossi delle mani...
Offline fletchergames

Senior Devvie





« Reply #1 - Posted 2006-09-24 14:02:46 »

An array of images is probably better because getting a part of the image is generally slower than getting the whole image.  Also, it may make it easier for the JVM to determine what images to accellerate.
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #2 - Posted 2006-09-26 16:29:18 »

In some cases it's better to use a single larger image for your sprites.
It will more likely result in less overhead if this image is to be cached
in vram.

Some hw configurations only allow power of two textures, so
for example your 24x35 sprite will have to be placed into a 32x64 texture.
So if you have tons of textures like that your overhead will be
significant. But if you place all of them into a 512x512 texture,
it could be reduced.

Also, having your sptires in a single image may help with performance
as it requires less context switching for the native pipeline.
Many images:
1  
2  
3  
4  
5  
6  
  copy image 1 into texture 1
  copy image 2 into texture 2
  set texture 1
  render texture 1 at coord1
  set texture 2
  render texture 2 at coord2


Single image:
1  
2  
3  
4  
  copy image into texture
  set texture
  render texture at coord1
  render texture at coord2


And since setting a new texture is an expensive context switching
operaion (at least, for Direct3D), the second way is typically faster.

For software-only rendering it doesn't make that much
of a difference.

Thanks,
  Dmitri
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


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

Interesting, it's always been the other way round in benchmarks, see the discussion here:

http://www.java-gaming.org/forums/index.php?topic=13768.0

and bench mark here:

http://woogley.net/misc/Clipping/

Generally storing lots of little images in Java2D has been faster. However, with the new opengl pipeline it makes sense in my head that sprite sheets should be efficient.

EDIT: Is there any chance that a sub-image in the new pipeline is just a reference to the old image with different texture coordiantes?

Kev

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #4 - Posted 2006-09-28 01:08:16 »

Quote
Is there any chance that a sub-image in the new pipeline is just a reference to the old image with different texture coordiantes?

If by "sub-image" you mean doing a drawImage of a region of larger image, then yes, in
opengl and d3d pipelines it's just a tweaking of the teture coordinates of
the same texture.

In other pipelnes it's pretty much the same thing - just different source
coordinates of corresponding blit operation (srcx,srcy,w,h) instead of 0,0,w,h -
the exact same routine is used as with copying from smaller image.
There's a bit of extra logic to figure out that this is not a scale (if src/dst width/height
are different or not).

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

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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