Recently I've been experimenting with spritesheets, particularly in AS3. I've managed to extract standard sprites and develop functional animations through sheets with equal sized squares. A lot of spritesheets on the internet aren't properly organized with equal sized squares though. Is there a way to manipulate pixels to obtain the location and dimensions of sprites from these sheets dynamically? Or must I modify the spritesheet itself to a 'square format'?. I want to avoid hard-coding as much as possible.
The point of spritesheets is often to reduce the overhead of data. Loading one image is much faster than loading hundreds of images. Because you can have variable sized images, most spritesheets generated will also come with a secondary file that defines where in the spritesheet you can find each image. Then, it's just a matter of referencing the x, y, width, and height values for that image.
TexturePacker will generate these, as I imagine most other apps do.
Typically if you have non-regular sized and/or spaced sprites, you'd also have an accompanying data file (XML or JSON probably) that defines the locations and sizes of the different sprites.
Related
For specific example, drawing a basic shape and icon that is used in different parts of the site in different colors. Should I use svg or sprites?
But asking if there is a standard answer for this.
Using SVGs has great advantages over using a sprite, especially when implemented correctly. SVGs have good compatibility among all browsers.
An SVG is a vector shape that can be infinitely zoomed-in, while you must have several sprites for different density displays - as a sidenote, having just one sprite of great resolution and then making it smaller using background-size doesn't scale well in all browsers leaving artifacts.
SVG sprites can be used inline, reducing HTTP calls - depending on the language/framework you are using, an SVG can be turned inline using plugins/addons - in ember for example.
You haven't specified what kind of shapes you are talking about, but if we are talking about single-color shapes then you can use a tool like icomoon to import all your SVG files into one Icon font file. So you have one HTTP call to get the font, like you would have with a sprite. As an added bonus an icon's color can be changed using the CSS color property; so with just one icon you can have multiple iterations of different colors with CSS as opposed to sprites, where you would have to design different iterations one be one before implementing them into a sprite.
Performance wise, I think these days it's not important unless we are talking about hundreds of SVGs compared to an image sprite. Even if it is slower, it would only be on 'paper' and the difference would not be identifiable to the user.
My team is currently working on a rather large Web application. We have switched from the flash platform to Html5 in hope for a one size fits all platform.
The UI, is mainly based on createjs, which I by the way really enjoy working with.
However we have now reached the maturity phase and started optimizing some of the animations, that doesn't run smoothly in especially IE.
The thing is that we have a around 1500 sprites (pngs & jpgs) which is drawn onto a stage. We only draw around 60 of them per frame.
They are rather large (up to 800x800 pixels), and the application engine can choose which 60 to show more or less randomly.
The images are packed in a zip file and unpacked in the browser and Html images are constructed by converting the binary data to a base64 encoded string, which is passed to the src property of an image.
So in each frame render a set of around
60 images are drawn to the stage. And this is for some reason slow.
I have therefore used some time to experiment with the Spritestage of createjs to take advantage of Webgl, but with only small improvements.
So now I'm considering to pack our sprites in a spritesheet, which results in many sheets because of the large amount of data.
My question is therefore:
Would spritestage gain any improvements if my sprites are spread across multiple sheets? According to the documentation only spritesheets with a single image are supported.
Best regards
/Mikkel Rasmussen
In general, spritesheets speed up rendering by decrease the number of draw call required by frame. Instead of say, using a different texture and render for every sprite, spritesheet implementations can draw multiple sprites with one render call, provided that the sprite sheet contains all the different individual sprite images. So to answer your question, you are unlikely to see performance gains if the sprites you want to draw are scattered on different sprite sheets.
Draw calls have significant overhead and it is generally a good idea to minimize them. 1500 individual draw calls would be pretty slow.
I dont know if it this is applicable to your situation but it is possible your bottleneck is not the number of draw calls you dispatch to GPU but you are doing too much overdraw since you mention your sprites are 800x800 each. If that is the case, try to render front to back with the depth test or stencil test turned on.
there are spritesheets of tiles for a new game I'm developing. I'm planning to use them with mask layers. I mean for example there is 30 different tiles on each spritesheets, to use each one I'm planning to change spritesheet's x and y, so mask will show only the wanted tile.
But the problem is, it may force cpu.
For example if there are 30 tiles on the screen and if each spritesheets has 30 different tiles, that makes 900 tiles if I use mask layer instead of cropping each tiles.
So the problem is , If I use mask layer, does it effect the cpu in a bad way, or does only the part under the mask is calculated on cpu?
I hope I could define the problem clearly.
Thank you
-Ozan
Starling is a whole new field, as it's using Stage3D. This means you have to rethink your development flow - everything must be as textures and so there are a lot of limitations - you cannot simply design a button in your Flash IDE, give it a name and use it. I'm not saying it's bad, no, I just say you have to you it wise and if you don't have any experience with it - it will take time to learn.
I think you are doing some calculations wrong. You say For example if there are 30 tiles on the screen and if each spritesheets has 30 different tiles, that makes 900 tiles, which means you have 30 spritesheets with 30 tiles on each. This is a lot of tiles for your game, are you sure? :)
Anyways, the common approach is to use each tile of the spritesheet as an individual one. That's why it's called spritesheet. And the meaning of this is very simple - the memory it will use. Imagine you have 100 tiles in one spritesheet (for easier calculations), and this spritesheet is 1mb. If you splice it in smaller chunks (100 of them), the size of it will be close to 1mb also. So if you do this and delete the original source, the RAM that will be taken because of those bitmaps will be close to the original.
Then you want to use a single tile (or let's say your map is just "water" and you use only one tile). You instantiate many instances of the very same class, and because you use only one kind, the memory that will be taken in order to be displayed is 1/100 of the original 1mb.
What I mean is that the worst case scenario would be to use the total 100 of them at the same time, and this will take 1mb of memory (I'm talking for the images only). Every time you use less, the memory will decrease.
The approach of having a mask is worse, because even if you use a single tile, it will put all of the original spritesheet into memory. Single tile - 1mb. And it will also draw a mask object (Sprite) and will also need to precalculate that mask and remove the outer part of the Bitmap. This is more memory, more CPU calculations, and more graphic rendering (as it will draw the cropped Bitmap every time you instantiate).
I think this will give you an idea why it's used that way! :) If you have some fancy regions and that's the reason you want to use masking instead, then use some spritesheet packager program. It will provide you with a data file describing the regions of the spritesheet that are used, and so with a single class (there are many for that) it will parse your initial Bitmap, create Bitmap children for each chunk and destroy the original. And the coordinates won't matter.
Cheers! :)
I am using Pygame 1.9.2a with Python 2.7 for designing an experiment and have been so far using Pygame only on a need basis and am not familiar with all Pygame classes or concepts (Sprites, for instance, I have no idea about).
I am required to draw many (45 - 50 at one time) shapes on the screen at different locations to create a crowded display. The shapes vary from displaced Ts , displaced Ls to line intersections. [ Like _| or † or ‡ etc.]! I'm sorry that I am not able to post an image of this because I apparently do not have a reputation of 10, which is necessary to post images.
I also need these shapes in 8 different orientations. I was initially contemplating generating point lists and using these to draw lines. But, for a single shape, I will need four points and I need 50 of these shapes. Again, I'm not sure how to rotate these once drawn. Can I use the Pygame Transform or something? I think they can be used, say on Rects. Or will I have to generate points for the different orientations too, so that when drawn, they come out looking rotated, that is, in the desired orientation?
The alternative I was thinking of was to generate images for the shapes in GIMP or some software like that. But, for any screen, I will have to load around 50 images. Will I have to use Pygame Image and make 50 calls for something like this? Or is there an easier way to handle multiple images?
Also, which method would be a bigger hit to performance? Since, it is an experiment, I am worried about timing precision too. I don't know if there is a different way to generate shapes in Pygame. Please help me decide which of these two (or a different method) is better to use for my purposes.
Thank you!
It is easer to use pygame.draw.rect() or pygame.draw.polygon() (because you don't need to know how to use GIMP or InkScape :) ) but you have to draw it on another pygame.Surface() (to get bitmap) and than you can rotate it, add alpha (to make transparet) and than you can put it on screen.
You can create function to generate images (using Surface()) with all shapes in different orientations at program start. If you will need better looking images you can change function to load images created in GIMP.
Try every method on your own - this is the best method to check which one is good for you.
By the way: you can save generated images pygame.image.save() and then load it. You can have all elements on one image and use part of image Surface.get_clip()
For a personal project I'm creating a static gif decoder. Everything works well so far, except I'm having trouble understanding one concept from the specification:
This block is REQUIRED for an image.
Exactly one Image Descriptor must
be present per image in the Data Stream. An unlimited number of images
may be present per Data Stream.
(Spec)
Unlimited images per data stream? There can be more than 1? I'm assuming they don't mean an animated GIF because in the same specification they state, that they don't recommend gif's be used for animation.
I've read a lot of other sites documenting the gif format and they all state something similar. Heres another link:
There might be an unlimited number of images present in a GIF.
Any ideas?
GIF87a does not allow animation, but enables multiple images in GIF.
The idea was to decompose (for better total compression ratio) large picture into several rectangular subpictures drawn on a common canvas initially filled with background color. Every subpicture has its own x, y, width, height and palette. For example, if you are drawing astronomic picture: Earth and Moon, these two objects may be represented as two small subpictures on common large black canvas. It is not an animation: both subpictures are visible simultaneously.
But this beautiful idea was not supported by software (browsers, picture viewers, etc.), probably due to such non-standard approach.
Since GIF89a these subpictures were transformed into animation frames.
There can be more than one image present in a GIF file. Yes, GIF files can perform crude animation, but it's usually not pretty.