Is there any way to make my app work on ipad 3 without updating to cocos2d 1.0.1 or higher?
I am using cocos2d 0.99.5 and a third party framework (not mine) which uses cocos2d 0.99.5
Updating to cocos2d 1.0.1 or higher would be a colossal work.
My app is working in ipad 1 and ipad 2, but in ipad 3 i just see a black screen (and listen to the music)
Thank you!!
Possibly, if you can retrace what has been done to add iPad 3 support between 0.99.5 and v1.0.1. You can use the github commit history. Though this will not be an easy task, and possibly cost you more time than updating to v1.0.1.
Why would updating be a colossal task? If you tried it and found hundreds if not thousands of errors, this does not mean you'll have to apply the same number of fixes. One renamed cocos2d class can already give you dozens and more errors depending on the class and your project.
To update cocos2d follow the steps described here. Especially important and often forgotten is to actually delete all the old cocos2d files, otherwise you may still be using old version source files in your project causing all kinds of trouble.
From what I recall when I updated the first edition of my book (cocos2d 0.99) to the second edition (cocos2d 1.0.1) there was very little code between those two cocos2d versions that actually forced me to write new code. 99% of the changes are merely renamed classes, methods and properties - renaming them accordingly fixes 80% of the issues, and the rest are new or removed or re-arranged parameters of methods, almost as easily fixed though not as easily because you can't always use refactor respectively search & replace to fix those.
I suggest to fix the easy ones first (renamed classes, methods, properties) and then get to the rest. If you need help, you already know how to use SO. ;)
Related
I have found myself trying to upgrade Apache Superset from version 0.35 to 0.37 or soon 0.38 as is about to get released.
Our version of superset was heavily modified, from code added to the default superset files to creating new one. We are talking about hundreds of files changed with 1 to 1000+ added lines Given this fact the upgrade fails with a lot of conflicts, something that was expected.
I would like to find a way to make the upgrade to the newest version and keep our modifications as well as making the process easier for future upgrades.
So far (until 0.35) we manage to upgrade to the newest version and solve the conflicts but it became more and more difficult.
The modification were from the front-end jsx files to css to python files.
What I tried and failed:
make a patch file using
diff <0.35 files> <our modified 0.35>
and apply the patch to 0.37 but this did not work as the files are very different between versions and the line numbers changed drastically as well as the folder structure is different in the newer versions.
Is there any way to keep our modification separated and make the process easier for future upgrades?
The more you fork and has the main branch evolves, the harder it gets to upgrade, that is simply to be expected when forking software. Given current high velocity and general pace of change in the Superset code base, and the pre-1.0 status of the software, you can pretty safely assume that any work you do in a fork is likely to be fully revisited every time there's a major upgrade.
The way you prevent that is:
extending only the things that were designed to be extended (plugins, extensions, configuration hooks)
contributing your changes back into the main branch
Many of us have learned that the hard way in our careers. The typical realization is that overtime, the progress in the main branch offer much more value than your customization, and upgrading and applying your customization becomes hard or simply impossible. The usual solution is to look into your customization and identify the really important ones, and try to contribute them back so that they can evolve with the software.
I want to use an OpenCV's implementation of the TLD tracker. Internet says that I have to include this file: opencv2/tracking.hpp (e.g. see https://github.com/Itseez/opencv_contrib/blob/master/modules/tracking/samples/tracker.cpp).
But there is no such a file.
Well, what must I do to use TrackerTLD in my C++ project?
(OpenCV 3.0.0 beta for Windows, installed from the .exe package from opencv.org)
As Floyd mentioned, to use TrackerTLD, you need to download OpenCV contrib repo. Instruction is in the link, so explaining it shouldn't be necessary.
However in my opinion using TrackerTLD from OpenCV repo is bad option - i've tested it (about a week or 2 ago) and it was terribly slow. If you are thinking about real time image processing, consider using other implementation of TLD or some other tracker. Right now i'm using this implementation and it's working really well. Note that tracking an object is quite a time consuming task so to perform a real time tracking i have to downscale every frame from 640x480 to 320x240 (Propably it would work well (and definitely faster) in even lower resolution). On the web page of author of this implementation you may find some informations about TLD algorithm (and implementation) and another tracker created by this author - CMT(Consensus-based Matching and Tracking of Keypoints). Unfortunetely i haven't test it yet so i can't tell anything about it.
THE PROBLEM
I'm looking for a way to decrease the 40-50 second wait every time our SASS needs to compile into main.css. I've already gotten it down from over a minute by switching from using Compass for compiling to using grunt-contrib-sass. I need to get it down to 5-10 seconds, or as close to that as possible.
CAN'T USE LIBSASS
I'm a little bit stuck using SASS 3.3 and Compass unless we absolutely have to switch for the performance. We do use bootstrap-sass so it would be hard to get rid of Compass entirely. This means we can't easily switch to libsass. But any code in Compass can also be copied from their repository directly into our _mixins partial so anything is possible with enough effort.
USER THEMES
The worst thing for our speed by far is that we have different usergroups, each with their own set of variables used to compile the SASS with a custom theme. So our SASS needs to compile once for the main theme, main.css, and then once more for each usergroup in the system to make their theme.css. As we add users the compile time that results when any of our main partials are changed increases linearly. Any suggestions to speed this up are also welcome.
REPLACE #IMPORT WITH REQUIRE?
I read on the TreeHouse blog that #import slows things down a lot when using the stock Ruby SASS compiler. We do have a lot of partials, and the user themes as well, and we have bootstrap-sass rigged to compile using our variables instead of bootstrap's default ones. So there are a lot of #import statements. TreeHouse used Sprockets in their Rails project, replacing #import with //=require, to speed up their ~1min SASS compilation to something like 3 seconds. Django has a port of Sprockets called django-gears, could implementing that have the same effect on our SASS? Can we use django-gears together with grunt? There doesn't seem to be much mention of using the technologies together in the Google-sphere.
(edit: found the article I was talking about, updated this section. http://blog.teamtreehouse.com/tale-front-end-sanity-beware-sass-import)
Edit 2: No, Grunt and django-gears don't really work together. I don't think we need to use Gears to achieve this effect though. I'm going to try using some sort of Grunt file concatenation plugin to replace the Sass #import statements, I'll report back here about what it does to our compilation time.
CONCLUSION
Anyway, that's all the research I've done so far, pretty much. We could rewrite our SASS to work with libsass, which would be tough and take a decent amount of time. We can implement django-gears to possibly-maybe speed things up using require. Or, not mentioned yet, we can replace Grunt with Gulp. Gulp seems to have a slightly faster version of grunt-contrib-sass but might cause trouble if we need a plugin later down the line that doesn't exist for Gulp (since Gulp is smaller/not as well-supported as Grunt).
Is there anything that I've missed so far in my research? Any further suggestions? I'm not terribly experienced so any sage advice Stackoverflow has to offer would be greatly appreciated. :)
Posting this as an answer instead of an update to the question because we did find an acceptable solution to our speed problems. There's always room for improvement though (and our compilation time is still hovering at a bit above average). I ended up refactoring everything to work with grunt-sass and our total compile time, including all main and customer themes, dropped to ~5 seconds.
By the way, using grunt-concat or any other way to circumvent the Sass #import statement didn't speed things up at all. I'm not sure what crazy bug the TreeHouse Blog developers experienced that implementing Sprockets fixed, but what worked for them didn't work for me.
The real breakthrough came when I found the article Is Libsass, the lightning fast Sass compiler, ready for prime time?, written by Ben Frain. He mentions a library called sass-list-maps, written by Lu Nelson, that emulates Sass 3.3 maps in lower versions of Sass. Using sass-list-maps and some of the other tips in that article, I refactored our Sass until it resembled a much earlier version. It didn't take a huge amount of time despite our large codebase, I just commented out all the partial imports in partials/_all.scss and added them back in one at a time, compiling with grunt-sass each time and fixing any errors (manually inspected the CSS too, there were some bugs there that didn't cause compilation errors).
The only thing left to work around was Compass, which wouldn't compile with libsass even after I copied it into our project from github. We ended up replacing Compass with Bourbon, a mixin library that will add itself to the file structure of your project so it is easily accessible to import. It also has the side-effect of being very lightweight and sharing most of the same syntax as Compass so almost no changes were in order there. It's fully compatible with libsass/node-sass.
In the end, our Sass compiles way faster, and everyone is happy. 5 seconds is still a little on the long side with grunt-watch running it's only a minor annoyance. If I manage to bring the compile time down more I'll post how I did it here as well.
So Django 1.5 will be out within an Internet-Week (soon) and I'm feeling the pressure to start playing around with it for its vastly improved User model. But like with 1.4 and 1.3 before it, upgrading is not simply a virtualenv change, I've needed to alter (quite heavily in places) the structure of my projects.
I recently jumped from 1.2 to 1.4 and spend hours (over many projects) updating their file structures (and settings) to mirror modern Django preferences. Django 1.5 is going to force me to go through and fix all the CACHE settings and fix practically every instance of {% url ... %} in my templates.. I'm wondering if there's an easier way.
Is there anything out there that can automagically "upgrade" a Django project?
... Or at the very least "scan" a project to show up the larger honking issues so I can kick those out before starting QC.
No. And for good reason.
Some of the changes between versions are minor (such as the whole quotes around variables thing), while some are major (like the new User model).
While automatic detection might be possible (though non-trivial considering you'd have to execute every possible code path in the app), changing them would be fragile. And possible very dangerous.
Instead, when moving between versions, I move up one version (to the last minor version in for that major) at a time and test. Django will issue warnings for features that will be removed between versions, so it's easy to catch them while still having running code that works.
Cocos2d-iphone uses the -hd extension for Retina images (and other assets). The cocos2d Retina guide speaks only vaguely of "some incompatibilities" regarding #2x:
Apple uses the ”#2x” suffix, but cocos2d doesn't use that extension
because of some incompatibilities. Instead, cocos2d has its own
suffix: ”-hd”.
WARNING: It is NOT recommend to use the ”#2x” suffix. Apple treats
those images in a special way which might cause bugs in your cocos2d
application.
Great. I feel well informed.
Through a 2-year old bug report regarding #2x I got the link to a forum thread that supposedly explains the issues with #2x. However, it does not. The only hints I found in there is that there are iOS (4.0/4.1) bugs regarding #2x which I suppose are no longer relevant. It's possible that I might have missed some crucial aspect (there was some talk about caching or repeat loading issues) - the thread is very long after all.
I'd like to know what specific issues might a cocos2d developer encounter if (s)he is using the #2x suffix for images instead of -hd?
Please give concrete examples of things that might go or actually will be wrong.
This seems to be the main reason from this link: http://www.cocos2d-iphone.org/forum/topic/12026
Specifically this post by riq:
I don't know if initWithContentsOfFile was fixed, but in 4.0 it was broken and it wasn't working with #2x, ~iphone extensions.
imageNamed caches all the loaded files so it consumes much more memory than initWithContentsOfFile
Also the #2x extension does something (I don't know exactly what) but it doesn't work OK with cocos2d.
Another good point: Back when the iPhone 4 was just released with the retina display, I am sure some users of Cocos2D were using an older version of it so when the user was using the retina display on a version of Cocos2D that didn't support it, things were twice as large as they should've been. Again this is now fixed to most unless you are using a VERY early version of Cocos2D.
Overview, so it seems that the main issue was with initWithContentsOfFile from iOS 4 but they have fixed this since because I use that exact API with Cocos2D 2.0-rc2 in my app and I do not have any issues whatsoever. I use all Apple specified extensions for images and everything works jolly good! :)
It seems as if this has a historic background.
What makes using -hd graphics still worthwhile is that loading them doesn't rely on Apple functionality but is rather done in framework code. So -hd can be loaded for iPads in iPhone Simulator mode and make use of the higher resolution pictures in 2x mode.
Other than that I couldn't find any more reasons to not use #2x when I was looking into this a week ago.
In case you want all the details it is probably best to drop riq an email.