I've made a bunch of games from my own homegrown C++/DirectX 2D engine. I was thinking some of them would be more fun with the introduction of multi-player and at the very least it would be easier to distribute them and get people to play if they could run in a browser.
I'm looking to port my games into a web format and I don't think there is anything I'm doing that Flash or Silverlight can't handle. However I don't know either of those so while I could learn something new it would save time and make porting easier if I could find something in C++. Does anyone know of a preferably open source, or otherwise freely available, library I could use to give myself a leg up?
I've heard of Haxe and it seems to be similar to what I want although it introduces a new language that can be converted to C++, ActionScript, etc. I'd prefer C++ so I can reuse some code without much of a fuss.
I also found something called RakNet which may only be useful as a networking layer to my existing C++/DirectX games but less useful for a browser based games. Has anyone used this with success? How was it to implement and integrate with existing projects?
The short answer is no. C++ requires the code to be compiled into a binary executable, and for various reasons, such code is not allowed to be run in the browser.
The long answer: The native client by Chromium/Google allows you to write native C++ code and run it in the browser. However, support is very limited, in the sense that almost no browser allows it (beyond some experimental nightly builds of Chromium and such), and you're likely going to face the same issues when porting C++ code to a different OS (aka, just because it's in the browser doesn't mean it's going to run on that obscure Linux OS).
If you want to port your games to the web, you options are either re-write it for the web, or wait a few years/decades for the native client to become widespread.
Funfact: Most mobile devices allow for C++ code to be run with a minimal wrapper. It's not the web, but it's an option if your goal is to get more people playing your games.
Related
What's this about?
We have a C++ application dealing with image processing and computer vision on videos using OpenCV, we're going to rewrite it from scratch and need some help deciding what technologies to use. More specifically, I need help on how to choose the technology I'd use.
About the app
The app's functionality is divided in modules that are called in an order defined by a configuration XML file and can also be changed in runtime, but not in realtime (i.e. the application doesn't need to close, but the processing will start from scratch). These modules share data in a central datapool.
Why are we starting from scratch?
This application wasn't planned to be as dynamic as it currently strives to be, so it's grown to be a collection of buggy patches, macros and workarounds; it's now full of memory leaks, unnecessary QT dependencies, slow conversions between QT and OpenCV image formats and compilation and testing times have grown too much.
Language choice
The original code used C++, just because the guy who originally started the project only knew C++. This may be a good choice, because we need it to be as fast as possible, but there may be better choices to account for the dynamic nature of the application.
We're limited by the languages supported by OpenCV (C++, Java and Python mainly; although I've read there is also support for Ruby, Ch, C# and any JVM language)
What is needed
Speed: We're aiming for realtime tracking. This may rule out Python and Ruby.
Class Instantiation by name: Although our C++ macros and class registration system work, a language designed to be dynamic that has it's own runtime would be nice. Maybe Objective-C++, or Java.
What would be ideal
Module/Plugin/Extension/Component Framework: Why reinvent the wheel, using a good framework for this would let us focus on what's special about our app. There are many options here. Objective-C has it's NSBundles; C++ has libraries like Boost.Extension, Pluma, DynObj, FxEngine, etc; C has C-Pluff; I'd even say there are too many options.
Runtime class loading and reloading: From a developing point of view, it would be interesting to be able to compile and reload just one module. I've seen this done in via code injection in Objective-C and using Java's reflection.
What am I missing?
I have too many interesting options!
Here's where I need help, based on your experiences in modular app development, with this constraints, what kind of language/framework feature should I be looking for?
What question should I make myself about this project that would let me narrow my search?
Edit
I hadn't noticed that OpenCV had GPU bindings only for C++, so I'm stuck with it.
Now that the language is fixed, the search has narrowed a lot. I could use Objective-C++ to get the dynamism needed (Obj-C runtime + NSBundle from Cocoa/GnuStep/Cocotron), which sounds complicated; or C++ with a framework.
So I'll now narrow my question to:
Is using NSBundle in a crossplatform way with Objective-C++ easier than it sounds?
What C++ framework will provide me with hot-swappable modules?
The main reason for swapping modules in runtime is to be able to change code in a fast way, would Runtime-Compiled C++ be a better solution?
Meta: I did my research on how to ask a question like this, I hope it's acceptable.
"What question should I make myself about this project that would let me narrow my search?"
if you need gpu support(cuda/ocl), your only choice is c++.
you can safely discard C, as it won't be supported in the near future
have no fear of python, even if you need direct pixel access, that's all numpy arrays (running c-code again)
i'd be a bit sceptical of ruby, c# ch and the like, since those bindings are community based, and might not be up to date / maintained properly, while the java & python bindings are machine - generated from the c++ api, and are part of the official distribution.
If you're looking for portability and have large memory for disposal then you can go with Java.
The performance hit between C++ and Java is not that bad. For conversion between Mat and other image format I'm still not sure, coz it needs deep copy to perform that, so if your code can display the image in openCV native format then you can fasten the application
pro :
You can stop worrying about memory leak
The project is much more portable compared to C/C++(this can be wrong if you can avoid using primitive datatypes which size is non consistent and for example always use int*_t in C)
cons:
slower than C/C++
more memory and CPU clock needed
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
I know it's possible to write your code in C++ and use Objective C to make native Mac UI and Visual C++ to make native Windows UI.
Can someone please point me to a tutorial or write a sample code that teaches how to do this?
NOTE
I know about Qt or wxWidgets but that isn't the solution I want. I really really want to give a native feeling.
Although you say you know about Qt and wxWidgets, I still recommend you use them. You can do native-feeling apps with them.
You will always have to implement some kind of abstraction layer since the Windows and Mac are vastly different in how their UIs are implemented. You would need to find common patterns, find ways on how to abstract things so that different things can be accessed in a similar way. For this, you need to know both Windows and Mac programming very well. You will spend a lot of time trying to find workarounds and searching bugs. With every new iteration of Windows or Mac OS X, you would need to start working around bugs and/or integrating new behavior yet again.
Using a cross-platform library will save you lots of time and trouble and thus money, if you're writing a commercial application.
Edit: Well, if you're forced to go that route, I'd recommend to do it like this:
Separate the app into two parts: a backend that doesn't know anything about UI which does all the business logic and then the UI part. You would need to implement the UIs completely separate from each other and wouldn't be able to share much code between them. After all, if you would try to find common grounds (for example, if you would like to unify creating and using a button) you could as well use a cross-platform UI library again...
The upside would be that you could use every obscure UI feature available to each OS. The downside would be that you need to maintain two UIs, so if you add a feature to one UI you'd need to reimplement it in the other as well.
But you might want use a cross-platform library for the backend to unify things like file handling, networking and threading.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
I have read a few articles in the cross-platform tag. However, as I'm starting a fresh application (mostly a terminal/console app), I'm wondering about the easiest way to make it cross-platform (i.e. working for Linux, Mac OS X, and Windows). I have thought about the following:
adding various macro/tags in my code to build different binary executables for each operating system
use Qt platform to develop a cross-functional app (although the GUI and platform component would add more development time as I'm not familiar with Qt)
Your thoughts? Thanks in advance for your contribution!
Edit: Sounds like there are a lot of popular responses on Java and Qt. What are the tradeoffs between these two while we're at it?
Do not go the first way. You'll encounter a lot of problems that are already solved for you by numerous tools.
Qt is an excellent choice if you definitely want C++. In fact, it will speed up development even if you aren't familiar with it, as it has excellent documentation and is easy to use. The good part about it is that it isn't just a GUI framework, but also networking, XML, I/O and lots of other stuff you'll probably need.
If not necessary C++, I'd go with Java. C++ is far too low level language for most applications. Debugging memory management and corrupt stacks can be a nightmare.
To your edited question:
The obvious one: Java has garbage collection, C++ doesn't. It means no memory leaks in Java (unless you count possible bugs in JVM), no need to worry about dangling pointers and such.
Another obvious one: it is extremely easy to use platform-dependent code in C++ using #ifdefs. In Java it is a real pain. There is JNI but it isn't easy to use at all.
Java has very extensive support of exceptions. While C++ has exceptions too, Qt doesn't use them, and some things that generate exceptions in Java will leave you with corrupt memory and crashes in C++ (think buffer overflows).
"Write once, run everywhere." Recompiling C++ program for many platforms can be daunting. Java programs don't need to be recompiled.
It is open to debate, but I think Java has more extensive and well-defined library. The abstraction level is generally higher, the interfaces are cleaner. And it supports more useful things, like XML schemas and such. I can't think of a feature that is present in Qt, but absent in Java. Maybe multimedia or something, I'm not sure.
Both languages are very fast nowadays, so performance is usually not an issue, but Java can be a real memory hog. Not extremely important on modern hardware too, but still.
The least obvious one: C++ can be more portable than Java. One example is FreeBSD OS which had very poor support for Java some time ago (don't know if it is still the case). C++/Qt works perfectly there. If you plan on supporting a wide range of Unix systems, C++ may be a better choice.
Use Java. As much bashing as it gets/used to get, it's the best thing to get stuff working across any platform. Sure, you will still need to handle external OS related functions you may be using, but it's much better than using anything else.
Apart from Java, there are a few things you can run on the JVM - JRuby, Jython, Scala come to mind.
You could also write with the scripting languages directly( Ruby, Python, etc ).
C/C++ is best left for applications that demand complete memory control and high controllability.
I'd go with the QT (or some other framework) option. If you went with the first you'd find it considerably harder. After all, you have to know what to put into the various conditionally compiled sections for all the platforms you're targeting.
I would suggest using a technology designed for cross-platform application development. Here are two technologies I know of that -- as long as you read the documentation and use the features properly -- you can build the application to run on all 3 platforms:
Java
XULRunner (Mozilla's Development Platform)
Of course, there is always the web. I mostly use web applications not just for their portability, but also because they run on my Windows PC, my Ubuntu computer, and my Mac.
We mainly build web applications because the web is the future. Local applications are viewed in my organization as mostly outdated, unless there is of course some feature or technology the web doesn't yet support that holds that application back from being fully web-based.
I would also suggest Github's electron which allows to build cross platform desktop applications using NodeJs and the Google's Chromium. The only drawback for this method is that an electron application run much slower than a native C++ application due to the abstraction layers between Javascript and native C++.
If you're making a console app, you should be able to use the same source for all three platforms if you stick to the functions defined in the POSIX libraries. Setting up your build environment is the most complicated part, especially if you want to be able to build for multiple platforms out of the same source tree.
I'd say if you really want to use C++, QT is the easiest way for cross-platform application, I found myself using QT when I need an UI even though QT has a large set of library which makes pretty much everything easier in C++.
If you don't want to use QT then you need a good design and a lot of abstraction to make cross-platfform application.
However I'm using more and more Python bindinq to QT for medium size application.
If you are working on a console application and you know a bit of python, you might find Python scripting much more comfortable than C++. It keeps the time comsuming stuff away to be able to focus on your application.
Performance considerations aside, is there any known way to take existing C, C++, or Objective C code and run it directly in the browser? For example, a compiler that converts all the code into some interpreted language that can be run in the browser. Like Javascript, or Actionscript and the Flash player, or I suppose Java and the JVM.
I recognize there are higher level languages like Haxe that can be compiled to different targets. And on the other side there are projects like Cappuccino and GWT that attempt to make Javascript development more like traditional desktop development.
But I was wondering if you had an application that worked on a desktop or an existing code base done in C, C++, or Objective C could it easily be converted to a web based application?
Is there work being done on this front? Is there any practical reason to do this? Basically turn the browser into the OS?
Beside the performance issues, and the entrenchment of OS vendors, are there any technical reasons this couldn't be accomplished? Could this kind of C like code be shoehorned into a virtual machine hosted in a browser?
Google's Native Client (NaCl) uses a tweaked compiler to create x86 object code that can be verified by the browser and run in a sandbox, without a major performance hit - pretty cool stuff. They've compiled Quake under it.
This Matasano article has a good run-down on how it works.
Here is a C compiler which targets a number of other languages, including Javascript:
http://cowlark.com/clue/
Not sure what state it's in - last I spoke to the author, it handled pure C89 (subject to the limitations of the compiler frontend). AFAIK there are no plans for it ever to support a GUI.
I was wondering if you had an application that worked on a desktop or an existing code base done in C, C++, or Objective C could it easily be converted to a web based application?
That's sort of what Silverlight is for (C# rather than Objective-C, of course), since it makes the .NET runtime available. Porting a desktop app is usually as much about the GUI as it is about the language - if you have a Cocoa app and you want to port it to another environment (whether that's a browser or Windows), then you'd need more than just an Objective-C cross-compiler, you need the Application Kit and so on. WINE being a notable counter-example, it's pretty rare for these OS-specific libraries to be available at all on other platforms, let alone efficiently. And even where they are available, there are look-and-feel and usability problems when the conventions of one UI are bolted on top of another. So people tend to either use portable frameworks to start with, or else completely rewrite the presentation layer of the app.
Basically turn the browser into the OS?
There are several projects underway to turn the browser into a fully-featured environment for applications (not sure whether or not this is what you mean by "OS"). Flash and AIR, Silverlight, HTML 5. None of them plan to provide C as a programming language, as far as I'm aware.
Emscripten allows you to compile your code into javascript, which is then platform and browser independent.
I think the closest thing you are looking for is Google Native Client. It is still in early development stages though.
You may be interested in LLVM, the Low Level Virtual Machine. It would be possible to implement an LLVM inside a Java applet, Flash applet, or even in Javascript (I wouldn't be surprised if somebody hasn't already done some or all of the above).
Converting an existing application is a completely different kettle of fish, however. The paradigms of user interaction are so completely different between a "desktop" app and a "browser" app that a lot of it will have to be redesigned before a port is reasonable.
Check out Adobe Alchemy (formerly known as FlaCC), which uses LLVM to compile C/C++ to Flash.
This is possible with an ActiveX control, but this works only in microsoft internet explorer.
http://code.google.com/p/cibyl/wiki/Cibyl can make Java sources, so you could compile that for the Java plugin in a browser. Given that Java plugins are much less common nowadays though, you may be better off with a solution that compiles to Javascript.
It seems to me that the major challenges are not related to the language being used. I suspect C would be a very difficult language to implement in JavaScript, but it is possible.
It just seems like a bad idea to me.
First off, I would not write a desktop application in C, much less a web application. Second, web applications require a completely different architecture than desktop applications. Simply cross compiling a desktop application will not make it a web application. If it is portability you are looking for, I suggest using a high-level language targeting the JVM.
Maybe you should consider http://ideone.com for compiling c++ in the browser? You can also compile or interpret other languages, I personally use it rather for more exotic languages - I have c and c++ on my PC :)