Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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  
  Sprite Atlas vs. Sprite cache  (Read 3843 times)
0 Members and 1 Guest are viewing this topic.
Offline broumbroum

Junior Member





« Posted 2009-12-09 15:12:06 »

Hi !
I'm wondering  which one would a game developer choose between an Sprite Atlas (described  http://www.java-gaming.org/topics/cramming-the-most-into-a-sprite-atlas-bin-packing-problem/21680/view/topicseen.html) and a Sprite Cache.

Having 200 Sprites of 256x256 RGBA for one character in my game, I meant a Sprite Cache that loads up in ~40 seconds from the cache to openGL cache.
Do you think a Sprite Atlas would break down the load time ?

One constraint is that the java heap should not be increased more than one or two RGBA sprites (that's 2⁸⁺⁸⁺² = 2¹⁸ bytes / sprite ≃ 256kb / sprite) at a time. Then the cache is max 50 MB uncompressed per character.


::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 12


Game Engineer


« Reply #1 - Posted 2009-12-09 16:02:46 »

Well seems like you could use them in tandem, although in my experience caching raw sprite data (as it appears you might be doing?) ends up being slower than just decoding a PNG. Neither of your two options will break down load time in a significant amount, in my opinion, although with an Atlas you're only decoding one image so that will help a bit. The real advantage of a sprite atlas is that, if you're smart in implementing them, you can end up with 3 or 4 texture binds per draw step instead of 50 or 100 or more. Texture binds have a high overhead, so keeping everything in as few textures as possible is a large advantage.

See my work:
OTC Software
Offline broumbroum

Junior Member





« Reply #2 - Posted 2009-12-09 23:34:22 »

(...)
The real advantage of a sprite atlas is that, if you're smart in implementing them, you can end up with 3 or 4 texture binds per draw step instead of 50 or 100 or more. Texture binds have a high overhead, so keeping everything in as few textures as possible is a large advantage.
That's what I thought about atlas mode. Indeed, it'll end up in one big texture for a animation set... But that means the bigger the single sprite frame is, the biggest will be an atlas texture.
I mean I have 200 sprites I'd store in one big atlas file. The texture will be 100x256 squared, which leads to a 25k texture, hence impossible to fit in the gl standard cache (limit is 4096 squared texture size on  a geforce 6200).  lol ! An animation of 1 sec long, at 24 fps would be 12x256 squared ≃ 2400 px large... that may be thinkable.. but 2400 is a 2Mpx texture, which should be raw-tiled in say 128px² tiles and behave like decoding 24 small png to textures.
 
I'm currently using a so-called Sprite cache to store the data from one run to the other, not actually to use it in a real-time render. yet I cannot use the atlas mode for it .. .(


maybe I should use the atlas for small sprite stores, like menu icons or small background patterns. As you said, a mix of both worlds would be fine..

thank you demonpants !

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 12


Game Engineer


« Reply #3 - Posted 2009-12-10 00:20:14 »

Well, in general, as long as all the images in your atlas will be used together (all the images from the same level, all the frames of an animation, etc.), then it is in fact the best to make your Atlas as large as possible. It obviously becomes a waste if you have a lot of dead space in your applet or you have a lot of images that you won't be using at the same time, but otherwise even if you have a massive texture it's a better option than a lot of small ones. It will take up the same amount of memory but you'll have less texture binds.

See my work:
OTC Software
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2009-12-10 16:54:22 »

Another approach is to use the atlas to contain the animating sprite images that are currently being used.  I doubt all 200 sprites are going to be onscreen at once, so just move them from disk to cache to atlas as they go into the viewport.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 12


Game Engineer


« Reply #5 - Posted 2009-12-10 19:08:38 »

Another approach is to use the atlas to contain the animating sprite images that are currently being used.  I doubt all 200 sprites are going to be onscreen at once, so just move them from disk to cache to atlas as they go into the viewport.
Hm, interesting idea. Do you think that would be fast enough?

See my work:
OTC Software
Offline lhkbob

JGO Knight


Medals: 32



« Reply #6 - Posted 2009-12-11 07:50:47 »

No idea, I was just spit-balling, but it's similar to the concepts used in streaming 3D worlds and that works out okay.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 12


Game Engineer


« Reply #7 - Posted 2009-12-11 17:15:25 »

No idea, I was just spit-balling, but it's similar to the concepts used in streaming 3D worlds and that works out okay.
That's true. I do wonder how they manage to do that sort of thing well, because there's no question in my mind that at least ImageIO is really quite slow, so that streaming would probably not be very feasible. Then again, who knows? One thing I'm sure you couldn't do would be loading and unloading some images every single timestep - that would definitely be too slow. But you could probably get away with not loading offscreen tiles and instead pulling them in when you go near.

See my work:
OTC Software
Online Roquen
« Reply #8 - Posted 2009-12-11 17:24:28 »

Think render to texture.
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.

xsi3rr4x (64 views)
2014-04-15 18:08:23

BurntPizza (62 views)
2014-04-15 03:46:01

UprightPath (75 views)
2014-04-14 17:39:50

UprightPath (58 views)
2014-04-14 17:35:47

Porlus (76 views)
2014-04-14 15:48:38

tom_mai78101 (101 views)
2014-04-10 04:04:31

BurntPizza (161 views)
2014-04-08 23:06:04

tom_mai78101 (256 views)
2014-04-05 13:34:39

trollwarrior1 (209 views)
2014-04-04 12:06:45

CJLetsGame (216 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!