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! :)
Related
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.
I understand it's often faster to pre-render graphics to an off-screen canvas. Is this the case for a shape as simple as a circle? Would it make a significant difference for rendering 100 circles at a game-like framerate? 50 circles? 25?
To break this into two slightly different problems, there are two aspects to what you're asking:
1) is drawing a shape off-screen and putting it on-screen faster
2) is drawing a shape one time and copying it to 100 different places faster than drawing a shape 100 times
The answer to the first one is "it depends".
That's a technique known as "buffering" and it's not really about speed.
The goal of buffering an image is to remove jerkiness from it.
If you drew everything on-screen, then as you loop through all of your objects and draw them, they're updating in real-time.
In the NES-days, that was normal, because there wasn't much room in memory, or much power to do anything about it, and because programmers didn't know much better, with the limited instructions they had to work with.
But that's not really the way games do things, these days.
Typically, they call all of the draw updates for one frame, then they take that whole frame as a finished image, and paste that whole thing on the screen.
The GPU (and GL/DirectX) takes care of this, by default, in a process called "double-buffering".
It's a double-buffer, because there's room for the "in-progress" buffer used for the updates, as well as the buffer that holds the final image from the last frame, that's being read by the monitor.
At the end of the frame processing, the buffers will "swap". The newly full frame will be sent to the monitor and the old frame will be overwritten with the new image data from the other draw calls.
Now, in HTML5, there isn't really access to the frame-buffer, so we do it ourselves; make every draw call to an offscreen canvas. When all of the updates are finished (the image is stable), then copy and paste that whole image to the onscreen canvas.
There is a large speed-optimization in here, called "blitting", which basically copies over only the parts that have changed, and reuses the old image.
There's a lot more to it than that, and there are a lot of caveats, these days, because of all of the special-effects we add, but there it is.
The second part of your question has to do with a concept called "instancing".
Instancing is similar to blitting, but while blitting is about only redrawing what's changed, instancing is about drawing the exact same thing several times in different places.
Say you're painting a forest in Photoshop.
You've got two options:
Draw every tree from scratch.
Draw one tree, copy it, paste it all over the image.
The downside of the second one is that each "instance" of the image looks exactly the same.
If your "template" image changes colour or takes damage, then all instances of the image do, too.
Also, if you had 87 different tree variations for an 8000 tree forest, making instances of them all would still be very fast, but it would take more memory, because you now need to save 87x more images than when it was just one tree, to reference on every draw call.
The upside is that it's still much, much faster.
To answer your specific question about X circles, versus instancing 1 circle:
Yes, it's still going to be a lot faster.
What a "lot" means, though, will change based on a lot of different things, because now you're talking about browsers on PCs.
How strong is the PC?
How good is the videocard?
How large is the canvas in software-pixels (not CSS pixels)?
How large are the circles? Do they have alpha-blending?
Is this written in WebGL or software?
If software is the canvas compositing in hardware mode?
For a typical PC, you should still be able to hit 60fps in Chrome, drawing 20 circles, I think (depending on what you're doing to them... ...just drawing them onscreen, every frame is simple), so in this case, the instances are still a "lot" faster, but it's not going to matter, because you've already passed the performance-ceiling of Canvas.
I don't know that the same would be true on phones/tablets, or battery-powered laptops/netbooks, though.
Yes, transferring from an offscreen canvas is faster than even primitive drawings like an arc-circle.
That's because the GPU just copies the pixels from the offscreen canvas (not much CPU effort required)
I have many small, identical vector circles that move around the screen, but only appear for a defined period in defined areas. Currently, these circles are children of whatever parent object produces them, and each is given its own interframe handler for animation (move a few pixels, maybe change alpha). With hundreds on screen, this gets somewhat slow.
Would it be advisable to cache the circles as bitmaps? Would it be better to add them all to one array and have one interframe event handler run through the whole shebang, even if up to 90% aren't being animated in a specific frame?
Would it be faster to cache one circle as a bitmap and set all others to use the first shape's bitmapdata? Would it be even better to use a "CopyPixel" approach to erase and redraw ("blit") every circle at its new position every frame? I hear conflicting reports of the usefulness of CopyPixel on large mobile device canvases...
If the animation can be looped make a movie from the movie else try everything you can. Usually a CopyPixel approach is faster but I wouldn't expect much. I don't think it pays the bill either hence reduce the numbers of circles.
I'm making a fighting game, so I have giant character sprites (300px X 350px) with lots of frames of animation (~150 per character), so the maximum 2048 x 2048 texture size won't fit all frames of animation for a character. So, I'll need multiple TextureAtlases, right?
Do I need to worry about the costly GPU texture swapping, then, if I'm switching TextureAtlases on a MovieClip?
To change animation frames, would it be sensible to create a manager to select the frame and the atlas?
Or can I combine TextureAtlases so that one atlas stores multiple 2048 x 2048 sprite sheets?
How would you approach this?
A recommendation from Daniel Sperl on the Starling forum:
If you're sprites are so huge, I'm afraid you'll run into problems
with texture memory. Unfortunately, there is no easy workaround for
that at the moment, except creating that animation with "Spriter"
(beta):
http://www.kickstarter.com/projects/539087245/spriter
Consider whether you can reduce your animation demands by doing skeletal animation. Instead of drawing every single frame of your character directly into textures, break the character up into animatable parts, position the parts using transforms and then composite them into your animation frame at runtime. It's a fighting game, so this should be manageable (presumably you only have two animated characters, plus perhaps some relatively inexpensive environmental effects). As a result, you only need each unique part of each character, which should drastically reduce your texture budget (but increases the complexity of your animation engine).
You might look at DragonBones (http://dragonbones.github.com/getting_started_en.html) for help in achieving that.
Where is this 2048 x 2048 limitation documented? I've never read such a thing. The only thing i could find in the Starling 1.1 documentation concerning texture atlas size is:
Any Stage3D texture has to have side lengths that are powers of two.
Starling hides this limitation from you, but at the cost of additional
graphics memory. By using a texture atlas, you avoid both texture
switches and the power-of-two limitation. All textures are within one
big "super-texture", and Starling takes care that the correct part of
this texture is displayed.
Assuming i haven't completely missed this important detail and there is no size limitation on texture atlases, just create a one at 4096 x 4096 or 8192 x 8192.
hmm - my guess is that using textures larger than 2048x2048 has an effect on performance. And i would further posit that shifting between textures of that size will also cause performance to take a hit. Have you looked into scaling down your texture assets and upscaling them in the game?
I have an image of a basic game map. Think of it as just horizontal and vertical walls which can't be crossed. How can I go from a png image of the walls to something in code easily?
The hard way is pretty straight forward... it's just if I change the image map I would like an easy way to translate that to code.
Thanks!
edit: The map is not tile-based. It's top down 2D.
I dabble in video games, and I personally would not want the hassle of checking the boundaries of pictures on the map. Wouldn't it be cleaner if these walls were objects that just happened to have an image property (or something like it)? The image would display, but the object would have well defined coordinates and a function could decide whether an object was hit every time the player moved.
I need more details.
Is your game tile based? Is it 3d?
If its tile based, you could downsample your image to the tile resolution and then do a 1:1 conversion with each pixel representing a tile.
I suggest writing a script that takes each individual pixel and determines if it represents part of a wall or not (ie black or white). Then, code your game so that walls are built from individual little block, represented by the pixels. Shouldn't be TOO hard...
If you don't need to precompute anything using the map info. You can just check in runtime logic using getPixel(x,y) like function.
Well, i can see two cases with two different "best solution" depending on where your graphic comes from:
Your graphics is tiled, and thus you can easily "recognize" a block because it's using the same graphics as other blocks and all you would have to do is a program that, when given a list of "blocking tiles" and a map can produce a "collision map" by comparing each tile with tiles in the "blocking list".
Your graphics is just some graphics (e.g. it could be a picture, or some CG graphics) and you don't expect pixels for a block to be the same as pixels from another block. You could still try to apply an "edge detection" algorithm on your picture, but my guess is then that you should rather split your picture in a BG layer and a FG layer so that the FG layer has a pre-defined color (or alpha=0) and test pixels against that color to define whether things are blocking or not.
You don't have much blocking shapes, but they are usually complex (polygons, ellipses) and would be unefficient to render using a bitmap of the world or to pack as "tile attributes". This is typically the case for point-and-click adventure games, for instance. In that case, you're probably to create path that match your boundaries with a vector drawing program and dig for a library that does polygon intersection or bezier collisions.
Good luck and have fun.