Transparency does not seem to be nothing on a sprite. Make sure that your game also sticks to the order. Group as much as possible in one sheet - but don't distribute one set on different sheets. So: If you can't fit all game objects, enemies and character in 1 sheet make sure to define a clear z-order for them: Multiple sheets: Textures might have to be switched - forcing additional draw calls: Overlapping sprites in your game (background to foreground): Sheet A: Sprites: a1,a2 Then it comes to the characters, enemies, bullets, game objects whatever.Īll on one sheet: No problem. It first draws your background in 1 batch. The first 2 are quite obvious - the latter maybe not.Īs explained above: The game engine starts with the background, working to the front. Place everything that might appear before or behind some other object in one sheet.Place everything that is clearly before other sprites in 1 sheet.Place everything that is clearly behind other sprites in 1 sheet.Group your sprites, objects and ui elements in layers - depending on how they overlap: So distributing your sprites across multiple sprite sheets requires a bit more thinking: If you have many animations the restrictions with mobile (mentioned above) might not allow you to place everything in 1 sheet. This works perfectly as long as you can put all sprites in 1 sheet. This is required to ensure that the transparency is handled correctly for overlapping objects. The painting start with objects in the background, working to the foreground. You see: Using sprite sheets is important. This is too theoretical? Here's a funny video about optimizing game performance. tTargetCoordinates(screenPositions)ġ Sprite sheet, 4 OpenGL calls. ScreenPositions.append(sprite.screenPosition) TextureCoordinates.append(sprite.sourceRect) The game engine can draw all sprites that are on one sprite sheet with 3 draw calls: foreach(sprite in sprites) To optimize the number of draw calls your game engine batches the painting of the sprites. This is bad!Īfter the draw() it might be required to wait until the next texture can be set. So you have about 4 calls for each of your sprite. tTargetCoordinates(sprite.screenPosition) Using single sprites looks like this (pseudo code) foreach(sprite in sprites) Desktops can handle bigger textures but you might get problems with shader precisions.Ĭhanging textures and setting parameters for OpenGL costs time. I would recommend staying below 4096x4096 for all devices. libgdx, andengine.) - this increases performance but comes with restrictions: Don't create sprite sheets bigger than 2048x2048 for mobile. Most game development frameworks use OpenGL for rendering (e.g. But if you have a system that deals with it very well, and it's a matter of flipping some kinds of configurations, it might be worth doing. If one giant spritesheet is difficult to work with in your system, you're probably going to end up doing awkward things, in code, to manage it, which will end up nuking any performance gains pretty quickly. a few well organized ones, I would recommend the easiest implementation. Since there is only the potential of a small performance gain in having a giant spritesheet vs. A giant spritesheet might not yield much gain, here, since you only need the frames that exist in the animation to be in the sprite. Often, these kinds of transformations are hardware accelerated (though that really depends on the system architecture), but it's far more performant than copying image data around, even without hardware acceleration. This is probably the more significant performance benefit provided by spritesheets. They speed up painting/animation by allowing simple translation of images that are already in memory, rather than copying bunch of data around. This will have a bigger memory footprint, but it's probably not enough to make much of a difference. So having sprite sheets will likely cut down on your load time and having one giant spritesheet may speed this up, but also means that you will have to load every sprite in the game-even if your only going to use a few. Sprites are almost always loaded before a game starts, since trying to get all that data on the fly would be noticeably awful. They reduce the significant overhead of reading image data from disk (or via network requests). Spritesheets tend to make things more efficient in a couple of ways: Having one giant spritesheet might yield slightly better performance, but you hit the law of diminishing returns fairly quickly, and it may make things more memory intensive. Using spritesheets for any animations and static sprites that are likely to appear in the same section/level of a the game is usually the best way to go.
0 kommentar(er)
