I'm making an action game and I'd like to know what should be the maximum size of the stage (mine is 660 x 500).
Also I'd like to know how big a game-sprite should be. Currently my biggest sprites have a size of 128 x 128 and I read somewhere on the internet that you should not make it bigger because of performance issues.
If you want to make e.g. big explosions with shockwaves even 128 x 128 does not look very big. What's the maximum size I can definitely use for sprites? I cannot find any real solution about this so I appreciate every hint I can get because this topic makes me a little bit nervous.
Cited from:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/DisplayObject.html
http://kb2.adobe.com/cps/496/cpsid_49662.html
Display objects:
Flash Player 10 increased the maximum size of a bitmap to a maximum
pixel count of 16,777,215 (the decimal equivalent of 0xFFFFFF). There
is also a single-side limit of 8,191 pixels.
The largest square bitmap allowed is 4,095 x 4,095 pixels.
Content compiled to a SWF 9 target and running in Flash Player 10 or
later are still subject to Flash Player 9 limits (2880 x 2880 pixels).
In Flash Player 9 and earlier, the limitation is is 2880 pixels in
height and 2,880 pixels in width.
Stage
The usable stage size limit in Flash Player 10 is roughly 4,050 pixels
by 4,050 pixels. However, the usable size of the stage varies
depending on the settings of the QUALITY tag. In some cases, it's
possible to see graphic artifacts when stage size approaches the 3840
pixel range.
If you're looking for hard numbers, Jason's answer is probably the best you're going to do. Unfortunately, I think the only way to get a real answer for your question is to build your game and do some performance testing. The file size and dimensions of your sprite maps are going to effect RAM/CPU usage, but how much is too much is going to depend on how many sprites are on the stage, how they are interacting, and what platform you're deploying to.
A smaller stage will sometimes get you better performance (you'll tend to display fewer things), but what is more important is what you do with it. Also, a game with a stage larger than 800x600 may turn off potential sponsors (if you go that route with your game) because it won't fit on their portal site.
Most of my sprite sheets use tiles less than 64x64 pixels, but I have successfully implemented a sprite with each tile as large as 491x510 pixels. It doesn't have a super-complex animation, but the game runs at 60fps.
Bitmap caching is not necessarily the answer, but I found these resources to be highly informative when considering the impact of my graphics on performance.
http://help.adobe.com/en_US/as3/mobile/WS4bebcd66a74275c36c11f3d612431904db9-7ffc.html
and a video demo:
http://tv.adobe.com/watch/adobe-evangelists-paul-trani/optimizing-graphics/
Also, as a general rule, build your game so that it works first, then worry about optimization. A profiler can help you spot memory leaks and CPU spikes. FlashDevelop has one built in, or there's often a console in packages like FlashPunk, or the good old fashioned Windows Task Manager can be enough.
That might not be a concrete answer, but I hope it helps.
Related
What size for my textures should I use so it looks good on android AND desktop and the performance is good on android? Do I need to create a texture for android and a texture for desktop?
For a typical 2D game you usually want to use the maximum texture size that all of your target devices support. That way you can pack the most images (TextureRegion) within a single texture and avoid multiple draw calls as much as possible. For that you can check the maximum texture size of all devices you want to support and take the lowest value. Usually the devices with the lowest size also have a lower performance, therefor using a different texture size for other devices is not necessary to increase the overall performance.
Do not use a bigger texture than you need though. E.g. if all of your images fit in a single 1024x1024 texture then there is no gain in using e.g. a 2048x02048 texture even if all your devices support it.
The spec guarantees a minimum of 64x64, but practically all devices support at least 1024x1024 and most newer devices support at least 2048x2048. If you want to check the maximum texture size on a specific device then you can run:
private static int getMaxTextureSize () {
IntBuffer buffer = BufferUtils.newIntBuffer(16);
Gdx.gl.glGetIntegerv(GL20.GL_MAX_TEXTURE_SIZE, buffer);
return buffer.get(0);
}
The maximum is always square. E.g. this method might give you a value of 4096 which means that the maximum supported texture size is 4096 texels in width and 4096 texels in height.
Your texture size should always be power of two, otherwise some functionality like the wrap functions and mipmaps might not work. It does not have to be square though. So if you only have 2 images of 500x500 then it is fine to use a texture of 1024x512.
Note that the texture size is not directly related to the size of your individual images (TextureRegion) that you pack inside it. You typically want to keep the size of the regions within the texture as "pixel perfect" as possible. Which means that ideally it should be exactly as big as it is projected onto the screen. For example, if the image (or Sprite) is projected 100 by 200 pixels on the screen then your image (the TextureRegion) ideally would be 100 by 200 texels in size. You should avoid unneeded scaling as much as possible.
The projected size varies per device (screen resolution) and is not related to your world units (e.g. the size of your Image or Sprite or Camera). You will have to check (or calculate) the exact projected size for a specific device to be sure.
If the screen resolution of your target devices varies a lot then you will have to use a strategy to handle that. Although that's not really what you asked, it is probably good to keep in mind. There are a few options, depending on your needs.
One option is to use one size somewhere within the middle. A common mistake is to use way too large images and downscale them a lot, which looks terrible on low res devices, eats way too much memory and causes a lot of render calls. Instead you can pick a resolution where both the up scaling and down scaling is still acceptable. This depends on the type of images, e.g. straight horizontal and vertical lines scale very well. Fonts or other high detailed images don't scale well. Just give it a try. Commonly you never want to have a scale factor more than 2. So either up scaling by more than 2 or down scaling by more than 2 will quickly look bad. The closer to 1, the better.
As #Springrbua correctly pointed out you could use mipmaps to have a better down scaling than 2 (mipmaps dont help for upscaling). There are two problems with that though. The first one is that it causes bleeding from one region to another, to prevent that you could increase the padding between the regions in the atlas. The other is that it causes more render calls. The latter is because devices with a lower resolution usually also have a lower maximum texture size and even though you will never use that maximum it still has to be loaded on that device. That will only be an issue if you have more images than can fit it in the lowest maximum size though.
Another option is to divide your target devices into categories. For example "HD", "SD" and such. Each group has a different average resolution and usually a different maximum texture size as well. This gives you the best of the both world, it allows you to use the maximum texture size while not having to scale too much. Libgdx comes with the ResolutionFileResolver which can help you with deciding which texture to use on which device. Alternatively you can use a e.g. different APK based on the device specifications.
The best way (regarding performance + quality) would be to use mipmaps.
That means you start with a big Texture(for example 1024*1024px) and downsample it to a fourth of its size, until you reach a 1x1 image.
So you have a 1024*1024, a 512*512, a 256*256... and a 1*1 Texture.
As much as i know you only need to provide the bigest (1024*1024 in the example above) Texture and Libgdx will create the mipmap chain at runtime.
OpenGL under the hood then decides which Texture to use, based on the Pixel to Texel ratio.
Taking a look at the Texture API, it seems like there is a 2 param constructor, where the first param is the FileHandle for the Texture and the second param is a boolean, indicating, whether you want to use mipmaps or not.
As much as i remember you also have to set the right TextureFilter.
To know what TextureFilter to you, i suggest to read this article.
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 making a 2D tile based game and I expect to have a really big world.
As I want movement between areas to be seamless I will obviously need to load the world in chunks.
So the question is :
Is it better if my chunk's size is based on my game's resolution
Is it better if my chunk's size is a perfect square
Let's have an example with simple numbers ;
If my game's resolution is 1024x768 and my tiles are 32x32,
I can fit 32x24 tiles in one screen.
Let's say I'd like my chunks a bit bigger than the screen,
Is it better to have a 128x128 tiles chunk
Is it better to have a 128x96 tiles chunk
As far as I know my question is irrelevant and either would do but I'm afraid I might end up facing an unexpected error if I choose the wrong one.
I think either direction you decide to take with handling chunk size, it is definitely going to be a wise decision to leave it abstracted enough to allow for some flexibility in size (if not for your own unit tests).
That being said, this is a question of performance really and doing textures/assets in powers of 2 was a good restriction back before dedicated GPU's were around. I'm not really sure if you'll see a huge difference between the two nowadays (although you might with it being flash) but it's usually a safe route to keep the tiles as a power of 2. In the past when working with rendering, keeping assets to a power of 2 meant it would always divide evenly and that saves on some computations.
Hope this helps! :)
I am creating an AS3 game which will be ported to iOS and I am using the parallax feature but I can't get a layer to go any slower than 0.1. Is that the slowest it will go or is there a way to make it slower still?
I want a sky layer to go 0.05 or slower.
Thanks
I am not sure you completely understand the mechanism
The idea:
The speed is given by the number of pixels moved in a frame and framerate. if you have a fps of 50, and a speed of 0.02 then your game should move the background 1 pixel in 1 second.
Since 1 pixel is the minimum unit you can move, moving the background by 0.1 or 0.0000001 pixels will not affect at all the view until the unit is reached (for user x=12.1212 is same as x=12.1213). Sure we must exclude any anti-aliasing.
So, as an answer: setting any speed should work!
Suggestion: when you set x, y, width and height properties, convert the values to int for performance reasons. Anyway if you do not use any level of anti-aliasing the visual result will be the same.
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?