So created a Sprite to which I add other Sprites which are game tiles. Each tile is 60 x 60 px big. In result I've the Sprite with about 200 childs (those tiles).
When I try to startDrag() the container sprite the lag when moving it is very noticeable..
Is there a way like to join the tile Sprites so the container would have only 1 child Sprite instead of 200? Because it lags so much probably cause it needs to move (change the x and y) all those 200 tiles.. Am I correct?
In this case I can't use the cacheAsBitmap property, cause user can zoom in or zoom out the map..
Glycerine & Aurel do touch the crux of the real solutions. However I'd like to add.
You are correct by the way, when you said it has to manage so many sprite locations when you move the container around. CacheAsBitmap sure does does tackle this to great extent but the real solution is blitting. Try this link for that :
http://www.adobe.com/devnet/flash/articles/blitting_mc.html
It doesn't matter if a user zoom or something of that sort is required cause you can always switch between bitmap data & the original vector sprites. Your problem arises in moving.managing lotsa sprites, so just before doing that use optimizations, after that let them be back to their selves.
I've had the same issue before. Is it possible to 'join' them together - in a sense.
When you add your 200 sprites onto a screen - I assume you put them all into another parent sprite.
A this point - you will take a snapshot, or a screenshot - or a photographic replica (whatever you want to call it) of all the sprites and write the image (bitmapData) to a parent sprite. At this point. delete/remove/hide/nullify the original sprites and you'll be left with a sprite containing bitmap data.
One big image to move about and zooming and the like is no bother.
If you need code - ask. It's time consuming code so you tell me first then I'll write it :P
Hm, joining them would actually be quite hard... You would need to get the graphics, the code and all and put that into the parent...
I don't think that is the problem - you should do something else... In this case, I think that by "tiles" you mean that the parent would be a tile map, correct? So, you probably have a 2-dimensional array (array of arrays) with tile types - instead of parsing that array at initialization, creating A LOT of Sprites, try re-parsing it in each frame (it is faster), but add only the Sprites that are possible to see. That is - their X position (after adding the zoom and camera X) is greater than -sprite.width, where the height is also scaled by the zoom, and lesser than stage.width + sprite.width (again, width after zoom). Same goes for Y, only with the height attributes.
Related
In libGDX, which is more efficient to position the camera on the sprite?
Move the camera for the same amount on the input that moves the sprite or set the camera's position equal to the sprite's position on update?
I can't really tell if the input handler is more consuming than a regular get/set position.
Some trivial math that you do only once a frame is not worth thinking about. Moving a camera to follow a sprite only happens once a frame, so you should only be concerned with code clarity.
If you have a large object (like SpriteBatch or a big array) to instantiate, you want to avoid doing that in the render loop because that is slow. You can instantiate it when creating something instead.
It's good practice to focus on code clarity, not premature optimization. Only optimize if you actually have a frame rate problem. If that happens, the issue is usually something that happens in a big loop, like if you're cycling through 200 enemies to update them.
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 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 am building a survival horror like game and am hoping to make a very nice camera system to compliment the mechanics. Part of this is the fact that you will be able to crouch down and cover your face. The camera work I want to do with this is to zoom in to the character in order to constrain the view for the player as well.
The current MC structure that I have is:
GameMaster
>
Spawner (this is for the player and all enemies)
>
Player
The issue I'm having is that scaling the GameMaster (which is where side scrolling and other global game effects are happening) causes the centering of the camera to offset based on how far away the player is from 0,0.
You can see the issue clearly in this video. The red arrows point to the 0,0.
On this stackoverflow question the answer says to make a container for everything and center the containers 0,0 over the target that you want to zoom around. This poses a challenge for me because I would then have to get proper coordinates for an object nested 4 MC's in. I'm also unsure what that will then do for my current side scrolling camera.
Is there a way that I could mathematically figure out the offset when the character ducks? It seems like a viable option because you can't move until you let go of crouch and the camera zooms out.
If not, is the container MC a good option or is it just one of those "you gotta do what you gotta do." type situations?
[Added]
I also see something about Transform Matrices or something. Is that something that would work? I know NOTHING about them but I assume they are CPU heavy and wouldn't be a good option for a mechanic prevalent throughout the whole game.
[Added 2]
ALSO, I want to do a rotation camera effect that suffers from the same 0,0 issue. Blatantly showing up as the player and level rotating around some far off pivot point.
If a Transform Matrix can swiftly and functionally offset the 0,0 to the players location so that I can do all the camera effects and alterations. I think that may be the best way to go.
----Close to Conclusion----
In regards to Vespers answer. Would I then be able to tween the resulting transform?
If so then that completely answers my entire problem. If not, I have no clue how to get the result I want.
I think the container is the cleanest solution. Since it'll be centered on the player, rotations and scaling will work normally. You mention getting the coordinates for the nested MC is hard, but there is a built-in function to do exactly that: localToGlobal()
To get the player position in global coordinates, just do player.localToGlobal(new Point(0, 0)). This should return the Player's center in global coordinates. If your main container is not in global coordinates (because it's nested inside another transformed MC, for example), you can use the opposite function on the container to convert from global to local:
container.globalToLocal(player.localToGlobal(new Point(0, 0)))
Now you just need to center the container. That could also be used to simulate the camera movement. If you update the container position at every frame, it'll give the effect of the camera following the player.
Stupid question I guess, but I haven't managed to find the answer yet :)
If I change some value for a parent sprite, the same value will affect all of its children. So if I set alpha or width on the parent, the child will automaticly get the same value.
Is there some way I can prevent that from happening?
Short answer: no
Longer answer: for alpha there is no work around that I know of. For width, you could hack something to work so that the child clips looks to see what the parent scaleX is and then increases its own scaleX if it is less than one but this isn't something that I'd do.
The best way to do this is to create a holder clip that contains no graphical assets but you can use to move other clips around together.
It seems that doing alpha = 1/alpha of parent works fine. That means setting the alpha to higher than 1 on the child. At least this work with AS3/Flash 10.
If You want not to avoid changing alpha of the children at all (like David suggested), but to prerender sprite before it's faded (so You can fade out a human without showing his bones), then set blendMode = BlendMode.LAYER;
This is not available on GPU rendering, so on mobile devices You probably need to create a bitmap, draw the sprite to the bitmap and then fade the bitmap. Maybe it's even easier, as AIR has some upgraded feature of cacheAsBitmap (it's named differently, that is, You have both cacheAsBitmap and the other one I'm talking about), that maybe will work, but I don't know as I don't use AIR.
if you are after the dimensions then then you can simply get the inverse of the parent transformation matrix and apply it to the child, there is a pretty good tutorial here for example:Transoform Matrix.
see applications -> Shaking Smilies section for what you are after.
other things like alpha i dont know a way to get around.