I'm writing iPad cocos2d game with animations.
Designer gave me frames for each animating character in png. I'm using TexturePacker to pack my textures. But one of character is very big (600x600 pixels). And there 200 frames of animation. So, it will be very big memory part if I will pack it with TP to some atlases. But really not all 600x600 pixels are changing. Character has only moving hands and legs.
I think, I should cut static part from frames and cut dynamic parts from each frame to decrease memory usage. Is there some existing instrument for this? Or there is some better way to do in my situation?
AFAIK, there is no instruments for such task. And 200 frames 600x600 pixels.... I am sure that you will not be able to place all these frames to memory with other textures as backgrounds, other effects, etc.. It is too much for mobile device. Even for iPad. You should ask your artist to reduce frames number and size as possible.
For example, few months ago I got animation with 200x300 pixel frames. And actually content was only about 100x100 pixels. All other place in these frames was filled with glow. After glow was removed, it was not look such cool as before, but it was good too. And reduced memory problems.
For others with same problem:
After all I refused Cocos2d and write game with video. Huge animations was prerendered in video file, small animations I overlayed with imageView.animationImages.
You can change video playbackTime to add interactions.
Related
Since most devices today have a CPU and a GPU, the usual advice for programmers wishing to do animated vector graphics (like making a circle grow or move around) is to define the graphical item once and then use linear transformations to animate it. This way, (on most platforms and frameworks) the GPU can do the animation work, because rasterization with linear transformations can be done very fast on a GPU. If the programmer chooses to draw each frame on the CPU, it would most likely be much slower and consume more energy.
I understand that the Watch is not a device you want to overload with complex animations, but at least the Home Screen certainly seems to use exactly this kind of animated linear transformations:
Also, most Watch Faces are animated in a way, e.g. the moving seconds and minutes hands.
However, the WatchKit controls do not have a .transform property, and I could not find much in the documentation - the words "animation" and "graphics" are not even mentioned there.
So, the only way I currently see is to draw the vector graphics to a CGContext and then put the result as an UIImage to a image control, as described here. But this does not really seem energy-efficient. It is exactly the kind of "CPU pixel drawing" that we usually want to avoid if possible. I think it is not energy-efficient because if I draw on a 100x100 pixels image buffer, the image has to be scaled to the actual Watch screen size, so we have two actual drawing processes per frame.
Is there a officially recommended, energy-efficient way to do animations on the Apple Watch?
Or, in other words, can we animate things like they are animated on the Home Screen or Watch Faces?
Seems SpriteKit is the answer. You can create SKScene and node objects and then display them in a WKInterfaceSKScene.
An HTMLVideoElement can be resampled in order to get different frames into a texture over time.
For example, as shown at https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL
However- when loading an animated gif into a HTMLImageElement, resampling does not show the updated texture. This is true even if the image is mounted on the dom and the different frames show on that copy.
Is there a standard way to display an animated gif in webgl, or must it be somehow rewritten into a spritesheet (or series of textures) at runtime?
GIFs aren't automatically animated with WebGL (or regular canvas for that matter) and there is no standard way of doing this.
Contrary to video elements GIF images will only draw the first frame via drawImage() while drawing video elements will draw current frame. This is in part because we don't really have access to any of the image's frames via API (this also applies to animated PNG files, aka APNG) and animated images will be handled only as an internal process conducted at the discretion of the browser and only when in DOM.
With video elements though we do have access to "frames", that is, time via currentTime so it's sort of implies that we want to deal with what we see or what exist at the current time.
You have to manually animate a GIF image though. This means you have to extract each frames as separate images/buffers first then show them at the rate you chose. The browser won't help you a bit here, but you can do this by parsing the file format manually.
Of course, this can be a bit tedious, but luckily there are people out there that has done all the lifting and hard work. For example gifuct (I have not tested it myself but there are others out there as well) will allow you to extract each frame from a GIF
Then render each frame you got from that into the frame buffer and upload to the GPU at the frame rate you choose.
Or:
pre-process the GIF into a spritesheet as you mention
or load it as an image sequence instead
or convert the GIF to a video (this may even reduce the total size)
And as a shameless plug if you should consider APNG instead: I have made apng-parser which does the same for APNG files.
My recommendation though is to convert the GIF/APNG to a video file which gives the animation capabilities for free, potentially smaller files, can be buffered and streamed for long animations, less code to include and typically a single file to deal with (you may have to provide different video formats for older browsers). Free software such as FFMpeg can help you with the conversion.
At work, I work with very large images.
I currently do my rendering via SDL2.
The max texture size on the graphics card my machine uses is 8192x8192.
Because my data sets are larger than what will fit in a single texture, I split my image into multiple textures after it is loaded, and tile them.
However, I have found that this comes at a very steep cost. Rendering only 4 textures around 5K by 5K (pixels) each completely tanks the framerate!
Conventional wisdom tells me that the fewer texture swaps the better, but with such large images I've found myself between a rock and a hard place.
One thing I've considered is that perhaps if I were to chunck the images up into many small textures, I could take advantage of culling which would hopefully be a net win. But there's a big problem with that approach - I need to be able to zoom out.
Another option would be to down scale the images. This seems promising as the analysis I am doing on the images do not require the high resolution that the images provide.
I know that OpenGL has mipmapping, but I am inexperienced with OpenGL and am weary of diving into it for a work project. I am not aware of a good way to downscale the images within the confines of SDL2, and for reasons specific to the work I am doing, scaling the images down offline (before I load them) is not appealing.
What is the best approach for me to get the highest framerate in this situation?
I would like to implement the effect that a short line segment revolving around a square (not knowing the exact effect name, it's just like the one in war3 to indicate auto-cast spell or in fishingjoy to indicate equipped weapon). Any advise/hint is welcomed. Thanks!
You have several variants. The first one, the easiest, to create frame animation of desired effect and run it on the empty CCSprite instance, that will be placed over your weapon icon. I think, 5 or 6 frames of animation will be enough. Big plus - you can create any desired effects on these frames in photoshop, and it is easy to add existing frames as animation to your project. Minus - it will take additional place in your texture cache, spriteframe cache and it will increase the size of your app. This is the good solution, if your square is quite small, because if your square will have large contentSize, it will take a lot of useless memory. For example, 6 frames of such animation with the size of screen( 640x960 pixels on retina screen ) wil take additional 16Mb of your memory.
The second variant, IMHO, much more interesting)) And it can help to save memory) This variant is to implement this animation with OpenGL) But it seems to be much more complicated)
I am working on a gameplay which needs load 27 texture altas (each one 1024 * 1024) before enter the game scene
but sometimes my game crash because receiving memory warning
I know 27 texture altas will use:
4 * 27 * 1024 * 1024 = 108mb memory
which is huge amount, but I really need to load them before entering game.
Is there anyway to solve my issue?
Any ideas will be very appreciated!
BTW:
I am using cocos2d 1.0.1
Best suggestion is to review your design, and the 'need' for preloading all these textures. I tend to pre-load only the textures that are most frequently used (animations and static map objects).
For example, I have textures for animating walks on a map for 16 character classes. I regrouped the 'idle' animations in 4 textures, and preload these, because initially, when a soldier enters the scene, it idles. The moving animations are in separate textures that are loaded in real time, as a function of the direction of travel, for each character class in movement. When the characters stop walking (idle), i remove unused textures from the cache, as well as unused sprite frames.
Also: there are other avenues for memory management. You could use a 16 bit format for certain textures (RGB88888 is the default). You may gain by converting to compressed PVR format (once again this is lossy, but could be fine for some textures)
Look here and there to learn more about picture formats in coco, and the relationship to memory consumption (as well as load, rendering speeds). But once again, before you start optimizing, make certain you have no alternative to the pre-load all approach.
use jpg instead of png it will make that non transparent you can make that transparent by alpha image of that image it will help you reducing size almost half of you are using now.