Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I realize the above question is rather broad so I will narrow it down. I have a simple opengl c++ game engine that lives in a static library (could be converted to a dynamic lib).
I have been thinking of ways of getting it to run in web. From what I can see I could use ActiveX or Google NaCl to run the c++ code in browser. But these technologies do not seem easily cross platform? Or maybe I have misunderstood.
Another option I have seen is converting the engine to javascript and WebGL and running in an HTML5 canvas. Would this be slower than c++? It would be very cross platform though.
What do you think is the best option, or better yet is there any other option I have missed?
EDIT: what about a custom plugin similar to the unity webplayer?
There is a library created by #kripken which is still under development. It takes LLVM bitcode and convert into Javascript.
You can see the project page here, with working examples.
https://github.com/kripken/emscripten/
I would strongly suggest porting to NaCl.
Advantages:
Performance: You can use the full power of the CPU to render your game. If your game uses good 3d graphics or physics, you can make it look smooth even on old system configs. The performance of NaCl is comparable to Native OS applications, it only looses nearly 5 to 10% of FPS when I compared the same game to Win32 version.
There are a lot of already ported examples, games for NaCl that can help you do it easily.
It is already cross-platform. Chrome runs on Windows, Linux, Mac OSX.
Disadvantages:
Might take you around a week to port. You have to port to OpenGL ES 2.0 (However, it should be the same with any browser based methods, especially HTML5)
Runs only on Chrome.
If you want something portable in a browser, then it has to rely on Javascript (and likely WebGL, although IE does not support that).
ActiveX and NaCL are just not portable in any way, shape or form.
I can't say which is easier, but you have an option of rewriting your game in Javascript, or using a tool like Emscripten to compile your C++ to JavaScript.
Note that if you use the latter, it's still not a silver bullet. You'll likely have to make lots of changes to your code (for example because the libraries and APIs used in your C++ game won't be available on the browser)
Related
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 6 years ago.
Improve this question
At first glance this question may seem like I'm looking for opinions or a discussion, but hear me out. While I'm sure everyone has their own opinion of which tools are best to use, there have got to be some factual reasons why Flash's popularity faded away. I'm sure there were certain events and inventions that caused people to prefer other tools, and I'm dying to know what those events are. So I am looking for answers that are based on facts and events. All I can gather from the research I've done and the projects I've seen is that Flash used to be really popular for creating interactive media or cartoon-like movies, but now it's not.
The background story to this question is that over the past few months I've been creating a project with Adobe Animate and Actionscript for a college class. It's been fun and I find that Animate is extremely useful. I would like to think that the skills I've learned will be useful in the future, but I've heard from several different people that Flash is pretty much irrelevant now and I can't figure out why.
I know that front end developers are using Javascript and HTML/CSS for most things, and I do understand some of the advantages. Javascript programs seem to have more open-source availability, and of course no one wants to pay a subscription for Adobe products forever. But what I don't get is what replaced the visual aspect of the "stage". Something as simple as drawing a circle could become hard really quick, or tedious at the least, if you're just using code alone. And if you draw two or more objects, you have to worry about their relative positions. Flash makes that super simple by allowing you to just drag them to where they need to be. But once again I imagine it would be really boring to have to use trial and error to position things solely with code.
So are the Javascript coders using something similar to Flash for their animations that I'm just not aware of, or are they really just using code alone? If they are just using code, WHY would they give up the stage aspect of design?
Politics, sadly. Flash was/is superior to HTML5 in almost every way (explained below), but there were a number of non-technological factors that ushered in its demise. Below are a few that come to mind:
1) Ads. This was the way most people grew to recognize Flash content; if it was flashy and annoying, it was probably Flash. This was unfortunate as it was not the technology itself that was the problem, but the use of it. (the fact that Flash was used so much for this type of content says something about how effective Flash was at creating this type of content).
2) Full Flash websites/games. Again, this was not so much a problem with Flash, but those who used it to create the content. Often devs will produce content on machines that are significantly faster than the average user's, and do most, if not all, testing locally.
3) The 1st iPhone was quite slow compared to those that exist today, and it was slow compared to a majority of computers as well. It is no surprise then that a technology that specializes in multimedia, running in a virtual machine, may have problems running on such a device; however, to say this would be to say something negative about the device, and rather than do that a 100% of the blame was put on the technology. The average consumer's experience with my previous points made this tactic easy to pull off.
4) Adobe gave up after losing the PR battle. There were many things they could have done to save Flash, such as: not dropping Android support, not dropping Flex support, not dropping Flash Builder support, and not ignoring the dwindling Flash engineer community. There is no reason why the iPhone could not run Flash today (and run it well), and there is no reason why Adobe couldn't create a transcompiler to convert content; I already did this (flash api, full as3 language support, e4x, etc.), but it's not open source as of yet. If one engineer could do this, they certainly could have!
5) Overblown publicity of Flash vulnerabilities. Critical vulnerabilities are found in programs all the time, browsers, operating systems (yes, even OS X), etc. But due to the growing discontent for Flash in the general public, issues found in Flash were covered as if Flash was the only program that was exposing people to vulnerabilities.
Technology: Is/was Flash tech superior? Absolutely, HTML5 was actually a huge step back, and here is why:
1) Flash was stable. If you got your app to work, it would almost be guaranteed not only to function exactly the same in all browsers and operating systems, but also to look identical as well. Want to develop an HTML5 app? Either use a javascript library to fix all/most browser inconsistencies, or welcome yourself to a debugging nightmare. So, of course, you add that abstraction layer, but now what happens when you still have an issue? Well, now you have to dig through that layer..
2) Flash/AS3 does it better. Want to have pixel perfect text across all devices? Flash, yes. HTML5, nope. Want REAL classes, typing, Vectors, weak references, interfaces, objects as keys, namespaces, private variables, asset embedding, etc. ? Flash, yes. HTML5.. while it's possible to create a compile-to-JavaScript language to pull most of this off, now you have to deal with that output when you're debugging. How about complex, nested, animations? How easy/fast is that to do in Flash... Sure, editors can be made to output the equivalent in HTML5, but most will not stream like Flash did, and will have severe limitations compared to what Flash can do.
3) The Flash API. The Flash API was well documented, powerful, and pretty simple to use. Compare this to the joy of searching online looking at compatibility lists and vendor prefixes for HTML5.
4) todo... there is quite a bit more.
HTML5 is better only in the fact that it is 100% open (and it's not a plugin, which people tend to dislike). The SWF specification is open, and there was an open-source Flash player (the Tamarin project); so, it is not as if Flash was completely closed like some would suggest; personally, I would trade the openness of HTML5 for stability and consistency any day.
However, if openness is one's primary concern, then one would probably view the step backwards in capability and efficiency as worth it.
BTW: I actually write all my HTML5 and NodeJS code in Flash/AS3 and compile to HTML5/JS. I can still use Flash for debugging (and as my gold standard if you will), which is fantastic..
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
[I have Edited my question to narrow down the scenario to only Node.js. Please Re-Open it. It is a helpful question and Proper answers might come in future and not sooner as ChakraCore is still at very young age. But this question is Valid and Should be here]
We all have known / read / heard about the glory of Google's V8 Engine and how it has made node.js the beauty it is, for years.
But now that we have an option to choose between Microsoft's ChakraCore and Google's V8 as our preferred JavaScript Engine, I am wondering if someone has any evidence, or test cases where they have found one to be more efficient than another for nodejs.
Please back your answer with some facts and results, because someone should not be using/choosing Chakra only because he/she loves Microsoft or and same applies for V8 and Google.
Thanks.
How they are different?
Whereas most modern JavaScript engines translate all JavaScript code into efficient machine code (source), Chakra has an intelligent and high-performance interpreter. This interpreter has intelligent heuristics that can determine whether to compile your code into machine code or interpret it. An interpreter is usually faster to start and requires less memory to run, which makes Chakra very attractive for resource-constrained environments (such as a Raspberry Pi).
In 2015 Microsoft introduced support for Node.js with Chakra to allow developers to target the Windows IoT Core platform. The recent open-sourcing of ChakraCore has allowed Microsoft to develop in the open and align better with Node.js release schedules.
In a recent JavaScript Air episode, Steve Lucco mentioned that the Chakra team are planning to "really take the community seriously and take their input seriously in terms of the direction that the engine will go [and] give the community a lot more input than, for example, they have had in the direction of V8".
In striving to build a memory efficient JavaScript engine, Microsoft have actually built a competitively fast one. At the time this article was written, Chakra outperformed V8 in some cases:
(source: msecnd.net)
Benchmarks aren't necessarily indicative of real-world performance but this competition in VM performance will eventually lead to a faster Node.js runtime for users of all VMs.
It's also worth mentioning that having their own JavaScript engine will allow Microsoft to freely innovate. One early innovation is time-travel debugging.
How they are different?
Well the question is bit too broad to answer currently in the format but i will try answering it.
Google's V8 engine has all the features which is required to have a blazing fast performance out of it. So, basically this one is the base for the nodejs for quite a while and it will be there for long run.
On the other hand Microsoft's ChakraCore is also been actively developed and it has two layer structure (unable to name it) with Chakra Shim and ChakraCore.
Thing to notice Chakra Shim implements the most essential V8 APIs so that the underlying JavaScript engine change is transparent to Node.js and other native addon modules written for V8.
Source: NodeJs-ChakraCore
For OP: Look for webassembly too.
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 8 years ago.
Improve this question
I'm searching for the best open source technologies to use to implement a bidirectional audio/video communication between two browsers.
For now I have unearthed these tracks:
WebRTC W3C spec and an Ericsson's implementation
Red5 and the BigBlueButton implementation as an example
Cumulus A Red5 implementation of Cirrus
HTML5 and his many new features (but not before 2014-2015 aparently)
Maybe some Jabber/Speex kind of implementation that I'm missing
Is there something I'm missing ?
What can be the best solution to use ?
Also (to be more precise), I'd like to implement this feature in my application developped using Django/Python.
The hardest question is what you should use on the client side to capture and stream video from the user's webcam. For that, you have relatively few options, since whatever you use has to be widely supported by modern browsers, whereas you can do whatever you want on your own servers.
There are three general approaches you can take: use HTML5, use an existing plugin technology, or create your own plugin.
The third is probably the most difficult, and I don't recommend it. You'd need to maintain at least five different versions of your plugin (one for each major browser), and users would have to install it.
For the second option, there are three major plugin techologies now that ActiveX is dead: Flash, Silverlight, and Java applets. I'd advise you away from Silverlight, as it's not exactly portable.
That leaves you with Flash, applets, and HTML5 as your choices. Of these, Flash is the most widely used—but it has its disadvantages and the world is moving away from it. HTML5 is the wave of the future, and although the standard won't be finished until 2014, it's not expected to change (Last Call was in May 2011) and the major browsers already support much of it—though apparently not yet the WebRTC API, though I'm sure it'll be in Firefox and Chrome soon.
Are you trying to build something similar to Chatroulette? They support bi-directional video streaming and microphones. They use Flash Player 10's peer-to-peer ability and Wowza Media Server to power their site.
Unfortunately, the realistic answer for where we're at today is Flash. Fortunately, there is haxe, an open source compiler for the Flash SWF format. You could use it to make all kinds of stuff.
The server in the linked example is written in haxe (basically AS3) and compiled to instructions for NekoVM (an apache module) but it should provide a pretty good example if nothing else.
I need to implement a paint type program that will run on all major browsers as well as can be packaged as an app on the iPad/iPhone. After some investigation I have learned the following facts (correct me if any are wrong):
Javascript is entirely too slow to handle an app of this type by itself
HTML5 seems like a good solution, it has a canvas tag and everything and can easily be packaged into a UIWebView for a Cocoa app. However, I need to be able to reach the majority market for web users, which unfortunately includes most IE users who aren't using the public beta for IE 9.
Flash vs. Apple
Right now I'm debating just making two completely separate apps, one in OpenGL ES for iPad/iPhone and another in something like Flash for web browsers. I was just wondering if anyone had an immediate solutions in mind to make one app instead?
I'd question the accuracy of your first point (Javascript is too slow). Since it's possible to run Quake II in pure Javascript, it's likely that your paint application is less resource-intensive and thus could also run. Of course, one could ask how much optimisation effort and/or experience is required to write performant Javascript of this standard - I can't give you an answer there.
But I'm certainly sure that it's possible to get enough performance out of Javascript to implement such a paint tool, in any modern browser. That doesn't preclude the other options, though; using JS along with HTML 5 sounds like the ideal solution here for "out of the box" cross-platform compatibility.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I was thinking, would it be feasible to create a Cocoa app that is essentially just a an interface with a web view? Or is there some serious limitation when doing something like this?
If it is "feasible", would that also mean that you could do the same for Windows applications?
It's certainly possible to create an application that's just a Cocoa window with a web view inside it, sure. Whether that can meaningfully be called a "Cocoa app" is debatable. Obviously things like the app menu would require some Cocoa glue code, so yes, there are limits to how much you could do in just HTML and JS.
You'd also have to think carefully about how you would handle localization (duplicating the entire HTML and JS source for each language isn't going to be desirable), and there are lots of interface constructs that would be much harder to create than they would be using Cocoa, and/or wouldn't feel native to someone used to the OS X look and feel. And you'll be giving up some performance by using an interpreted language, which may or may not matter for your application.
There are applications for OS X that are built that way, and they generally feel like bad ports; if your goal is to make something that feels like a real Mac application, it's probably not a good way to go.
iPhone OS has fantastic facilities for making web apps act as first class citizens on the device. You can have your web apps icon added to the springboard just like a Cocoa App, you can store data locally and lots of other really neat stuff... Check out these examples or the ADC documentation.
Sure. PandoraBoy is exactly this. It's a thin wrapper around an existing flash app with Javascript bridges. I've worked on other UIs that are programatically controlled WebViews using direct DOM manipulation to get very nice effects (without ever giving the feel of "a web app"). You can use the ObjC/Javascript bridge to let Javascript call ObjC, and WebKit makes it straightforward to run Javascript from ObjC.
Related, but in the opposite direction, there's Cappuccino, which is a Cocoa-like framework in Javascript.
I'm not clear what you mean by "do the same for Windows applications."
Titanium could help you a lot, it is basically a Cocoa window with WebView (the thing you are looking for), but (the good part) with JavaScript bindings to native stuff like access to filesystem, Menubar, Dock icon (ie. badge), sound, etc. Plus it will run on Mac, Linux, Windows, iPhone and Android!
Yes, there are quite a few apps that do it. I think they usually store the html files and use jquery to fetch the updated data. It mainly just gives the user a marginally faster experience, since you are only retrieving data and not the bulk of the HTML.
The limitations are mostly due to the fact you don't have access to all of the iPhone controls and libraries. MapKit, Mail etc.
Of course it's possible. There would be pretty big limitations. Such an app couldn't do anything that a Web page couldn't do. So, for example, using the standard systemwide document-handling support would be out unless you wrote supporting Cocoa code.
Not quite what you were asking but...
mProjector is an OS wrapper for Flash. It's like an extended version of a Flash projector with a system API giving you access to Mac/Win OS features.
This will give you the abiliy to use web skills to build a cross platform desktop app. It's cheaper and better than the other main option, Zinc.
You can write Cocoa apps with HTML in 2 ways.
Electron
Electron is a framework that turns html, css, js into a cocoa app.
WKWebview
WKWebView is a web browser used in Safari Web Browser.
If you chose WKWebView, make sure you put your html app in a webpage because people can go into the app resources
Titanium bills itself as open source software, but developers are required to register an account and maintain an internet connection to proprietary server software in order to make use of the platform.