I am currently using Cocos2dx C++ version 2.0.1. I understand this is an older version of cocos2dx but I originally started using it and already made most of my game with it and I really would rather not switch versions at this time. The problem I am currently having is that my whole game has about 3 full songs, 6 sound effects, and LOTS of textures. I have about 4 sprite sheets using the .plist/.pvr approach that have about 70 frames each. Now I feel I must be doing something wrong because I feel like so many games have way more data then this and they can load up just fine. I have tried many ways to make this work efficiently. I will describe each approach and the problems I have had with each.
I made A load up screen on start of the application but I found out that there seems to be no way to load .plist/.pvr asynchronously so I had no choice but to load each .PNG image one by one and no longer use sprite sheets. I feel that this is a ridiculous way but I have no found another solution. so by using this approach the game does load up (it takes some time but it does work) and since all images are preloaded the game runs smoothly. The problem here is that when I hit the home button and tap on my game icon to resume It takes a lot of time to reload all the textures and I have a very long wait before the application resumes. To fix this I have tried the following approach: I learned about setPreserveEGLContextOnPause() and how I can make textures not be lost when pressing home button. So I finally figured out how to set that up and it actually fixed the problem but I tested this with using only about a fourth of my sprites just to see how much memory it was using and I saw that it was already using 345MB of RAM! This means my full game would probably make the phone run out of RAM.
After all the mishap with the first approach I am really convinced I am doing something terribly wrong because I have not seen one android game that has trouble with coming back after hitting home button. I understand I am using many sprites but I can only but them down so much. I would love to go back to using the .plist/.pvr approach but I can't seem to find a way to load these file types while presenting a loading screen.
I have also tried just simply loading each thing per scenes init method. This causes the same time delay between switching scenes also.
Overall I am really stuck. I feel like I must be doing something very wrong because my game is a very simple puzzle game that is not huge by any means. I also want to find a solution that will work for iphones as well as android phones. Any help would be highly appreciated. Thanks.
1* use .mp3 format for Sound.
2* load All texture in app delegate like that.
#if (CC_TARGET_PLATFORM == CC_PLATFORM_MAC)
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile( gsd->getFullPath("name.plist")->getCString() )
#endif
#if (CC_TARGET_PLATFORM == CC_PLATFORM_IOS)
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile( "name.plist" );
#endif
#if (CC_TARGET_PLATFORM == CC_PLATFORM_ANDROID)
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile( "name.plist" );
#endif
Related
So I'm doing a 3D game for kids for Android and iOS in Unity, but i'm new in game developing and it's been really difficult to plan the assets.
We need to create 2D animations (paper like characters) and the characters have to be really detailed with great animations.
We have been thinking of several options:
We could create frame by frame animations but our designer says there has to be at least 24 images per second (because of 24 fps per second) with this the app will be very big.
Other option is to create 2D models in Blender and animate them there, but it's a lot of work and could take a lot of time.
The last option is to have the pieces of the model an animate it throughout code but it's a lot of work and I believe the quality of the animations would be low.
What's the better way to create 2D animations in Unity?.
Thank you!
Have you explored the 2D sprite engines that are available in Unity? Whoever said "Unity isn't really an engine designed to work with 2D stuff" is talking guff. I have just started working on a hobby 2D game and am using a Unity plugin called Orthello (see WyrmTale website for info). It handles sprite sheets, animations, collision detection and more without you having to write loads of code to do this. The learning curve is a bit steep and the examples on their website aren't the best but I found replicating the sample solutions that come with the download the best way to get something working.
There's also a similar tool called Sprite Manager 2 but you have to pay for that (I think). Check out the asset store for more information.
I would be really interested to hear if Orthello is what you're looking for and how you find working with it - please let me know via http://markp3rry.wordpress.com if you can.
Just because the app runs at 24fps doesn't mean you can't just display the animations for more than one frame of the main loop. It might not be smooth, but then again looking at the sprite sheets of games like super street fighter it doesn't look like they're at anywhere close to 24fps (the sprite sheet for Dhalism in SF3 Alpha is a 210kb .gif file on my computer, and there's less than 252 frames of animation on it. Likewise, the total storage space take up by every character sprite in Dustforce takes up a mere 7mb, though those sprites are just 192x192, maybe too low-res for you. They do look like paper though). I doubt that anything involving blender would take longer than hand animating -- Blender does key frames for you.
I am wondering if it possible to use Android renderscript to manipulate activity windows. For example if it is possible to implement something like 3dCarousel, with activity running in every window?
I was researching for a long time, and all the examples I found are for manipulating bitmaps on the screen. If it is true, and renderscript is only meant for images, than what is used in SPB Shell 3d, or these panels aren't actual acitivites?
It does not appear to me that those are activities. To answer your question directly, to the best of my knowledge there is no way to do what you want with renderscript as the nature of how it works prevents it from controlling activities. The control actually works the other way around... You could however build a series of fragments containing renderscript surface views, however the processing load of this would be horrific to say the least. I am unsure of how to take those fragments or activities and then draw a carousel.
What I *think * they are doing is using render script or open gl to draw a carousel and then placing the icon images where they need to be. But I have never made a home screen app so I could be and likely am mistaken in that regard.
(I tried to stuff the question with keywords in case someone else has this issue - I couldn't find much help.)
I have a custom View in Android that contains an LED bargraph that displays levels received via socket communication. It's basically just a clipped image. The higher the level, the less clipped the image is.
When I update the level and then invalidate the View, some devices seem to "collect" multiple updates and render them in chunks. The screen visibly hesitates for say 1/10th of a second, then rapidly paints multiple frames, and then hesitates again. It looks like it's overwhelmed and dropping frames.
However, when changing another UI control on the screen, the LED bargraph paints much more frequently and smoothly. I'm thinking Android is trying to help me by "collecting" multiple invalidations and then doing them all at once. Perhaps by manipulating controls, I'm "increasing" my frame rate simply by giving it "more to do" so it delays less between actual paints.
Unlike animation (with smooth transitions) I want to show the absolute latest value as quickly as possible. My data samples aren't faster than 10-20fps anyway.
Is there an easy way to "force" a paint at certain points, or is this a limit of how Views work? Should I be implementing this in a SurfaceView instead? (I have not played with that yet... want advice first.) Thanks in advance for suggestions.
(Later that same day...)
Update: I found a page in the Docs that does suggest implementing my widget as a SurfaceView is the way to go:
http://developer.android.com/guide/topics/graphics/2d-graphics.html
(An hour after that...)
SurfaceView seems overkill for what I want to do. The best-practice method is to "own" the whole canvas, but I have already developed the rest of my controls and layouts and they work well. It must be possible to get some better performance with what I have, especially since interacting with the UI makes the redraw speed satisfactory.
It turns out SurfaceView was the way to go. I was benchmarking on an older phone which didn't help. (The frame rate using a standard View was fine on an ASUS eeePad). I had to throw away some code, but the end result is smoother and faster with SurfaceView. Further, I was able to re-use more code than I expected and actually dramatically simplified my multitouch handling code (since everything I want to touch is in the same SurfaceView.
FYI: I'm still only getting about 15fps on Droid X, but half of the CPU load appears to be data packet processing. The eeePad is doing almost 40fps now -- and my data rate is only 20 samples/sec.
So... a win I guess. I want the Droid X to run better, but it flies on a real tablet.
Long version:
I have a very particular issue. I'm a multimedia artist working at the moment together with an animator - we are trying to create an interactive animation that I want to make available online as a website and as free app on the App Store and the Android Market.
But here's the key problem I am faced with now.
The output video of the actual animation will be massive in resolution - probably something like 4 or more times the HD resolution, but it's for a reason. The idea is to let the viewer only watch a part of the video at one time - like when panning around in Google Maps or any other canvas-like view (eg. MMORPG or strategy computer games). So you only see a part of the whole image at one time, and then you can move around to see what's "behind the corner".
So the animation would be a Google Maps-alike canvas (panning and perhaps zooming if there's enough time to implement it) but with video instead of images.
The big problem that comes up is performance. I was thinking that the best way to make it run would be to scale down the video for different devices accordingly. But then even just considering desktop computers for now - scaling down to 720p for HD screen means there is in total of about 4 times 720p in resolution, which is probably too much for an average computer to decode (Full HD is quite often already problematic) - and the output resolution would be more than the 4K standard (5120 by 2880, whilst 4K is 4096x2160). Anyhow, that is unacceptable.
But I reached the conclusion that there is really no point in decoding and rendering the parts of the video which are invisible to the user anyway (why waste the CPU+GPU time for that) - since we know that only about 1/6th of the full canvas would be visible at any given time.
This inspired an idea that maybe I could split the output video into blocks - something between 8 to 64 files stacked together side by side like cells in a table, then have a timecode timer playing in some variable and enabling the video-blocks on demand. As the user drags the canvas to the visible element it would automatically start the playback of the file at the given timecode read from the global variable. There could be some heuristics anticipating users movement and prematurely activating the invisible blocks in order to remove any delay caused by seeking within video and starting the playback. Then blocks which are no longer visible could deactivate themselves after a certain amount of time.
So my first attempt was to try and see what are my choices platform-wise and I really see it comes down to:
HTML5 with JavaScript (heavily using <video> tag)
Adobe Flash (using Flash Builder to deploy the apps to all the different devices)
And HTML5 would really be more preferable.
So I did some research to see if it would be at all possible to even synchronize more than one video at a time in HTML5. Unfortunately it's far from perfect, there are two available "hacks" which work well with Firefox, but are buggy in Webkit (the videos often get out of sync by more than a few frames, sometimes even up to half a second, which would be quite visible if it was a single video split into blocks/segments). Not to mention the fact that I have not even tried it on mobile platforms (Android / iOS).
These two methods/hacks are Rick Waldron's sync as shown here:
http://weblog.bocoup.com/html5-video-synchronizing-playback-of-two-videos/
And the other one, also developed by Rick is the mediagroup.js (this one doesn't work in Chrome at all):
https://github.com/rwldrn/mediagroup.js
My test here: http://jsfiddle.net/NIXin/EQbAx/10/
(I've hidden the controller, cause it is always playing back earlier than the rest of the clips for some reason)
So after explaining all that I would really appreciate any feedback from you guys - what would be the best way of solving this problem and on which platform. Is HTML5 mature enough?
Short version:
If I still haven't made it clear as to what I need - think of a video zoomed in at 600% so that you can't see everything (some bits are off screen) and you need to pan around by dragging with your mouse (or flicking your finger on mobile devices) to see what's going on in different places of the video. How could I do that (have the video run smoothly) across platforms, while retaining the high quality and resolution of the video?
Thanks a lot, let me know if you need any more details or any clarification of the matter.
I am almost done creating a game for android using a port of irrlicht 3d engine to android.
All code except a minimal frame work to make the native calls and play sounds is written in C++.
Even the opengles display is created in c++ code using eglGetDisplay and eglCreateWindowSurface
The problem I need to solve is that when home is pressed then relaunch the game the screen is all white.
From other answers I have found that the opengl context is lost then recreated when onSurfaceCreated is called. I thought that I could just reload textures but that seams to work for only some textures. Also the background color is changed which is not a resource.
It seams I would have to completely restart the game but this could be really annoying to a user.
the port of quake 3 has notes about this problem be has no solution.
Is there a example anywhere of a game written in native code which correctly handles this situation?
The way I handled the situation is to recreate everything. I made sure that all generated stuff like textures and buffers where deleted before recreating everything as if it happened for the first time.