Do Adobe apps support multiple cores or do they still use single core?
So will it make a difference in speed (in performance of the application) if I'm using a Pentium 4 processor (3 ghz) v/s a Dual Core Processor (2.7 ghz)
Edit:
As mentioned by AndrejaKo in his comment below, I have already asked this question on SuperUser but I was hoping that some Air developers here would have more information regarding this question.
I'm not an Air developer, but all the documentation I was able to find indicates that, no, Air does not currently support true concurrency... though they're considering the ups and downs of leaving Web Workers in their borrowed copy of WebKit for a future release.
Is multi-threading possible in Flash or ActionScript?
WebKit features not supported in Air 1.x
Adobe AIR 2 Beta Now Available: "Does that mean we can use web workers in Air?"
I think that last one covers the version of AIR you're asking about.
Adobe does not provide any ActionScript or JavaScript APIs for working with threads. So, everything written in one of those languages will definitely be executed single-threaded.
With adobe air 3.4 release, adobe will support concurrency using a new workers api.
http://www.bytearray.org/?p=4423
Related
It is mentioned on MSDN page,is the requirement strict?My system has 3 GB of RAM and I am not thinking about upgrading my system's ram anytime soon.
Also can I ignore Visual Studio,Windows phone 8 sdk on the whole if I pick up marmalade sdk as the primary development tool?
As someone who has to estimate system requirements with some regularity, I take minimum system requirements with a grain of salt. The minimum requirements have some padding, because nobody really knows where the edge really is, and as estimators we have to play it safe.
Usually, you can get stuff to run even if you don't meet the minimums.
Note that this doesn't mean that it will run well.
Not sure about Marmalade. You should consider separating these two questions into separate postings.
For successfully developing windows phone application minimum hardware requirement is necessary.
I've got a question for Flash Developers.
I would like to know if current Flash Player 11.x can force old apps/games (written for version below 10.2) to use Hardware Acceleration?
If you got any answer, please provide the reliable source.
Thanks in advance.
HWA is a feature of Flash Player, not a method in a particular app. So, it'll work even in flash6-written swf, if you hardware supports this technology.
Where do they differ?
What are the advantages of choosing libfreenect or OpenNI+SensorKinect, for example, over the Official SDK, and vice-versa?
What are the disadvantages?
Please note that the below answer is per date and some facts may very well be outdated in the near future. Current state of the Official Kinect SDK is beta 1.00.12.
The first obvious difference is that the official SDK is maintained by the Microsoft Research team while OpenKinect is an open source SDK maintained by the open source community. Both has its cons and pros.
The Official SDK is developed by Microsoft which also develops the hardware and therefore should know internal information about the device that the open source society must reverse engineer. Obviously this is to Microsoft's advantage.
Microsoft is pouring a lot of money into this device and I am sure that they will do what they feel is necessary to keep their SDK up to par. Having economy behind it gives many advantages.
On the other hand, never underestimate the force of the open source society: "The OpenKinect community consists of over 2000 members contributing their time and code to the Project. Our members have joined this Project with the mission of creating the best possible suite of applications for the Kinect. OpenKinect is a true "open source" community!" - http://openkinect.org/wiki/Main_Page.
OpenKinect was released long before the official SDK as the kinect device was hacked on the first or second day of its release. Kudos to OpenKinect!
Programming languages supported:
Official SDK: C++, C#, or Visual Basic by using Microsoft Visual Studio 2010.
OpenKinect: Python, C, C++, C#, Java, Lisp and more! Obviously not requiring Visual Studio.
Operating systems support:
Official SDK: only installs on Windows 7.
OpenKinect: runs on Linux, OS X and Windows
Clearly advantage OpenKinect.
License:
The Official SDK is in its current beta state only for testing. The SDK has been developed specifically to encourage wide exploration and experimentation by academic, research and enthusiast communities. commercial applications are not permitted. Note however that this will probably change in future releases of the SDK. Visit the FAQ for more information
OpenKinect appers to be open for commercial usage, but online sources state that it may not be that simple. I would take a good look at the terms before releasing any commercial apps with it. Read Kinect – Licensing implications of open hardware projects for more info.
Documentation and support:
Official SDK: well documented and provides a support forum
OpenKinect: appears to have a mailing list, twitter and irc. but no official forum/QA? Documentation on website is not as rich as I would like it to be.
Device calibration:
Different Kinect devices may differ slightly depending on the batch that they were produced in. Thus device calibration is sometimes required. But:
the Official SDK does not provide any calibration settings but I have so far not had to calibrate the device I am working on. According to something I read online (link lost) at production time the calibration parameters are written to the kinect device, so with the Official SDK calibration is not needed.
OpenKinect features device calibration: http://openkinect.org/wiki/Calibration. Thus I believe that you should calibrate your device if you go with OpenKinect.
If its true that calibration is only needed for OpenKinect that is a big advantage for the official SDK as it is easier to distribute and install applications without such need.
Personally, after a failed try with the OpenKinect SDK I went with the official SDK, which
came with drivers that installed out of the box
came with examples and code for easy getting into business
All-in-all: I could start my own development within 15 minutes or so.
Now, after working with the Kinect for a few months, I have to say that I am quite satisfied with the API provided. I cannot however compare it to the OpenKinect SDK as I in fact never got it working (but perhaps it didn't give it a fair try).
UPDATE: As of February 1st 2012 there is a commercial license for the official SDK:
"The commercial license for this release authorizes development and distribution of commercial applications. The prior SDK was a beta, and as a result was appropriate only for research, testing and experimentation, and was not suitable for use with a final, commercial product. The new license will enable developers to create and sell their Kinect for Windows applications to end user customers using Kinect for Windows hardware on Windows platforms."
Developer Frequently Asked Questions
As explained by Avada Kedavra in his/her answer, these are some interesting differences:
supported operating systems: you can only use Microsoft SDK on Windows, while open source solutions are usually able to work on other operating systems;
programming languages: you have a wider choice with open source solutions, while Microsoft only supports C++ and C# (Visual Basic is no more supported with SDK 2.0);
documentation and support: Microsoft offer a good forum and a well done documentation (with a lot of samples); but there are several open source solution well documented;
license: Microsoft is less or more proprietary, open source is less or more free. Consider also that open source ideas have sometimes been bought by big companies, and transformed in something that is no more open. Probably yours will not be the case, but keep in mind this additional eventuality.
In my personal opinion, the most significant difference between open source solutions and Microsoft SDKs is strictly related to the skeletal tracking algorithm.
While depth and RGB data can be effectively provided by both open/free APIs and Microsoft SDKs, implementing skeletal tracking capabilities is not only a matter of reverse engineering.
To implement such an algorithm, developers must have strong competences in pattern recognition and machine learning areas, and I am quite sure that such kind of knowledge is available among the open source community. But the implementation of skeletal tracking is based on a "trained" algorithm, that requires a lot of experiments to collect very large amount of data. These data are then used to "train" the algorithm, that can recognize the skeletal joints.
Getting enough data, but also adjusting and properly using them, requires a lot of time and money. Microsoft researchers and developers are in the best conditions to work on this kind of stuff, simply because it is their job.
In my previous experiences, I noticed that open source solutions provide good skeletal tracking capabilities, but they are not at the same level of what Microsoft offers with its SDK.
Remember also that Microsoft SDK provide a lot of additional capabilities, like facial recognition or joint orientation, and several widgets very useful if you want to fastly build a gestural GUI.
So what I suggest is: if you are working on a project in which you simply need depth and/or RGB data, or if you have the necessity to use a programming language that is not supported by Microsoft SDK, then you should opt for open source solution. Otherwise, Microsoft SDK would be my best choice.
I would strongly recommend the Cinder framework. (libcinder.org)
It supports both OpenNI and Kinect develoment, if you're using C++. It now supports Kinect SDK 1.7 and OpenNI 2, via these Cinderblocks:
MS Kinect SDK 1.7 (stable)
https://github.com/BanTheRewind/Cinder-MsKinect
OpenNI 2 / NITE 2.2 (alpha)
https://github.com/wieden-kennedy/Cinder-OpenNI
Both can do skeletal tracking out of the boz, OpenNI being capable of tracking up to six skeletons simultaneously. OpenNI 2 is gaining rapidly on the Kinect, although the new Kinect will probably change that when it comes out next month. However the basic underlying principles are unlikely to change.
The main drawback with the initial release of OpenNI was that it required a full body activation pose to recognise a user, which was a deal breaker for a lot of applications - however this seems to have been solved in the newer versions and OpenNI 2 also supports robust hand tracking at close range, although it still requires a focus gesture initially. If you work on Mac or Linux, it's pretty much your only choice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When we develop web pages we can broadly work out which browsers to support based on market share.
When we develop in .NET we can broadly work out which .NET version to develop for based on which Windows versions have it installed.
But when developing OpenGL or Direct3D applications, how do we know which video cards people (I mean "people" as opposed to "hard core gamers" or "companies using CAD" :P) are using? Are there statistics on such things? Is there some common logic that people use to work out what version to support? Just as most companies have supported (perhaps until just recently) a minimum of IE6 in web pages, is there a general consensus to support a minimum of, say, OpenGL 1.5, or DirectX 8 or something?
I note that we can find out which specific video cards support which versions of these APIs, but how do we know which video cards people are actually using, is there any kind of research on this?
N.B. I'm more interested in OpenGL because that's what I'm using, but I mention Direct3D because I assume the same problem applies.
Market fragmentation for 3d hardware has always been a huge problem. There is no simple answer.
You need to define who your uses are. Is this a casual-oriented game that you intend to sell to people who haven't updated their computer in years? Is this a business application that is aimed at workstation-grade hardware? Are you just looking for an average middle-of-the-road game-buyer? Is this something simpler than a game like a screensaver that you plan to sell to people who don't buy games at all? Do you need to support laptops? Netbooks?
The market fragmentation is considerably worse with OpenGL than it is with DirectX. The official standard requirements from the Khronos Group are all well and good. But the hardware vendors tend to be very slow to update their drivers to match the standard. Many features are required by the GL spec, but are only implemented in a fallback software path that is absolutely unusable in commercial software. The new OpenGL 3.1 spec tries to improve this situation by removing support for most older, poorly supported features. But if you need to support hardware more than a couple years old (or most modern Intel integrated GPUs) then GL 3.1 would be aiming too high.
A good place to start for general hardware usage stas among game purchasers is the Steam Hardware Survey ( http://store.steampowered.com/hwsurvey ). Steam is the most popular digital game distribution service that covers a variety of games from casual to core. They reset the numbers periodically to keep it current. Last year they reported that they had 25 million active users, so the sample population is pretty good.
So you probably need to narrow your target customer group down more. I would recommend picking some recent competing applications that you consider to have a similar customer base to yours and basing your target hardware around what they require.
OpenGL 2.1 is a good bet. The newer OpenGL 3 doesn't offer that much more functionality. You have to check for the availability of all of the OpenGL extension anyway,so you don't loose much by sticking with 2.1.
For DirectX: Use DirectX 9c. That is the latest version that still runs on WindowsXP. Drivers are stable and very mature. DirectX 10 offers more functionality but you will lock out the user-base that still runs WindowsXP.
About compatibility for non-gamers: Graphic cards that don't support these APIs (at least to a usable degree) have died out more than five years ago. Given the typical life-cycle of a PC you can be almost sure noone will have problems.
If any user complains that the software doesn't run on his 10 year old matrox-parhelia card he should just buy the cheapest graphic card he can get. It will run much faster and will cost a fraction of the software.
It depends on the timeframe of the project on the DirectX side.
If the project is to be ready in months, then follow the advice from Nils.
IF the time is over a year, I would reconsider limiting to DirectX9 as the XP machines are getting lesser and lesser with the time. DirectX11 would be a good idea, especially with retrocompatibility till feature level 9.0.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to develop a mobile application that is able to access all the features of the mobile device it runs on (camera, files, phone and network connectivity). I intend to build a series of applications that each have a specific function to perform, rather than a single application with a large feature set. My programming background is C, C# and web applications.
What would be the best tool set to use to do this? I have looked at using the NetBeansIDE to create a Java ME applications using LWUIT - this looks promising, but what are the caveat's?
I want to target the largest universe of mobile devices possible.
J2ME is the way to go to reach the masses, in the consumer or the business market. From a consumer standpoint, most of the world's mobile phones support J2ME. From a business standpoint, most of the world's smart phones support J2ME.
Nokia owns a 40% share of the smart phone market (and the whole market) worldwide. Next in line is Blackberry with a 13% share. Both have standard implementations of J2ME on their devices (though Blackberry also has a proprietary version of Java as well). On top of this, most devices that run Windows Mobile come with a JVM as well (I developed a game recently that initially targetted the Sony Ericsson W810i and it ran flawlessly on my HTC Tilt's JVM). Add in the fact that Android has a Java SDK and the only segment you are really missing out on are the BREW only phones and the iPhone.
I'm not a huge backer of J2ME. I just know that every other mobile platform has disappeared from my life over the last 3 years as it just makes financial sense for companies to only target the J2ME segment of the industry.
You are facing the usual main issue of mobile development : targetting as many handsets as possible with only one programming language means using J2ME, which doesn't quite give you access to all the features of the handset.
Most open handsets will support J2ME but different phone manufacturers implement it in different ways and fragmentation is enourmous accross the board. Unfortunately, the majority of open handsets (the ones where you can install third-party applications) only allow you to develop in J2ME
The only good news is that your intent to only write small applications will provide large relief from fragmentation issues.
J2ME also has huge limitations in terms of file system access, complete lack of a telephony API, very poor interaction with the system applications management...
In order to get full features, you always need to use the native technology of the open platform you are targetting, be it Android, iPhone, the several variants of Symbian OS, Brew, Windows Mobile or Palm OS handsets. Each of these has its own native technology.
Writing your application many times in many different languages in the costly price of wanting both a large number of targetted handsets and access to the full features of each of them.
I'm a Symbian/J2ME veteran myself and, given your stated background and goals, I suspect that you are trying to learn about mobile technologies. I'll therefore shamelessly plug my book, which is meant as an introduction into the Symbian development ecosystem :
http://www.amazon.com/Quick-Recipes-Symbian-Smartphone-Development/dp/0470997834/
Good luck
If your primary goal is to reach the consumer market, Java 2 Micro Edition (J2ME) is probably your best bet. All popular mobile phones (from Nokia, Sony Ericsson, Samsung) come with a Java Virtual Machine installed. If you look at Google, for example, they are developing all of their mobile applications (like Gmail and Google Maps) in Java.
If you instead are targeting business customers, the Microsoft .NET Compact Framework is the way to go in my opinion. The Windows Mobile operating system holds a strong position in the business market, mainly because of Outlook Mobile and its integration with Exchange.
I respectfully disagree with Fostah.
If you want to reach the masses, the Web is your best bet. It's far easier to write a simple Web application that will work on millions of devices.
And the best bit is that you can easily update your application and improve the user experience everyday with the Web.