I wanted to know some general throughts about Marmalade and AppEasy. http://www.appeasymobile.com/
I've been following DrMop's tutorials on creating a game engine in Marmalade but noticed that since the tutorials he's gone on to make AppEasy(with others). I have looked at it and have a couple of immediate concerns
1) How easily I can incorporate text files/xml files with XOML.
2) What degree of control I would have over the code base.
3) How deep the engine is and whether it has any comparitable rivels which are better.
I've started the project I'm working on with the IWGame engine that DrMop was using in his tutorials but was wondering that if all my fears are unfounded if it is worth carrying on?
Cheers,
Support for IwGame is coming to a close. IwGame is being replaced by the AppEasy Core SDK, which is an open source portable engine where Marmalade is just one of the platforms that it plans to support. AppEasy Core will also be open source so others can contribute to its development, submit bug fixes etc..
XOML + Lua or XOML + C++ or all 3 used together provide a very powerful easy to use environment. You can easily integrate text files, XML files, image files, sound files etc. You should check out the official web site appeasymobile, theres plenty of documentation and a drag and drop app builder that spits out cross platform apps based on XOML + Lua.
Cocos2d-x is a good alternative, but you will need to set up each dev environment for each platform you plan to support (massive pain to do) as it doesn't cross platform compile stuff for you. Although Marmalade do now have a stable interface to Cocos2dx which enables you to use Cocos2dx cross multiple platforms.
Related
I am a C++ programmer, but for some reason, I have to develop a website by myself(My own commercial project). I don't want to take a lot of time to study JavaScript and something else. It is possible to just use QT and WebAssembly (instead of HTML + CSS + JavaScript) to develop a front-end web?
Yes, it's absolutely possible and I'm currently doing it for a project but you should do it carefully based on the project requirements, running environment and your own backgrounds.
Here are some problems you may encounter:
The output .wasm file may get too large. Generally, it won't be suitable for public domain applications.
In low-end devices, maybe you find it laggy if you don't do enough code level optimizations.
Threads are not officially supported yet (as of Dec. 2019) by major browsers but tech-preview is available. This is not a real big problem as it would be a standard feature soon.
Native virtual keyboard won't work on mobile devices but the work is in progress.
These were my own major problems with Qt for WebAssembly.
Despite this, I find it much more flexible than HTML+CSS. QML is really a nice language for UI development. Creating animated UIs is quite easy and straight-forward.
You can also use many JavaScript libraries in your QML code like Lodash and Moment or any other js library that does not refer or manipulate window DOM.
Yes, it is possible. But you should do not do it if only reason is reject for learning new technologies.
For now (I'am writing this answer when Qt 5.14 is present) Qt for webassembly is deployed as official platform. Unfortunately it is young platform support with a lot of problems and possible future changes. Qt team do really good job so next version will be better. 5.14 is much better than 5.13 in webassembly context but still need fixes.
You should know Qt for webassembly will support only a few Qt modules, excluding widget. Yes, you can only use QML for GUI.
Qt for webassembly was created for the purpose of port one code base in other platform (it it generally Qt develop way, please see Qt for MCU). With other technologies in this stack like QRemoteObject is very interesting technologies. It was not created for websites in normal network. Main Qt for webassembly target are internal network systems and remote control of devices. Pay attention about this.
Unfortunately, not all browser will support webassembly right. Please see Qt for weassembly support notes.
Additional, in Qt you can't find build-in rest-API handle or other standard web technologies to integrate with your existing backed.
I've already written some backend *.dll files that I intend to use in a project. I need to visualize a simulation of the code, for which I intend to use charts and graphs from Chart.JS, by using it along with TideSDK for a desktop application.
I have no clue on how to call the C libraries via JS though. And I want to avoid creating wrapper classes in Python and going through that circuitous route. Any other options? Or are there any alternatives when trying to create an HTML/CSS/JS desktop application connected to a backend C/C++ library? Will AppJS make things easier?
TideSDK is capable of extension with modules that can be compiled and included in its runtime. It was written to be extended but I would recommend waiting for TideKit. TideSDK is a bit old and setting up a toolchain could be problematic at this point.
We've been investing in a broader vision with TideKit that is getting ready for release. You will be able to extend it with native modules and you won't need to wait too much longer to see what we've been up to. http://youtu.be/aE7gN-d0GhUthat
If you have started anything with TideSDK, you will be able to migrate your code easily to TideKit. The ability to work with with native or JavaScript modularity, and to develop for all screens from a single project code base is where all our efforts have been going.
Note that AppJS was discontinued earlier this year. An alternative is writing C extensions in node through node-webkit. Note that if you are going cross platform on this and you needed OSX as well, you cannot achieve Apple AppStore compliance with node-webkit due to private APIs as a result of its port of webkit.
I have to develop a basic inventory system, and my client wants to see all the objects in the inventory in 3D and their positions in the warehouse. The thing is that I have to develop this as soon as possible, delivery time is my priority here. So I came to the conclusion that I would need a powerful 3D graphics engine and an UI toolkit that can be easily integrated with it. I've plenty of experience with C++, Qt, OpenGL, VTK, C# and WinForms. In my experience, VTK is not so good with textures and it would involve more work to add the eye candy my client wants (like animations, visual effects, etc). I've tried Axiom with WinForms. I went through hell making a sample load and run (framework incompatibilities, rendering engines not found, codec native dependencies missing, etc).
I have been evaluating different options:
Qt + Ogre (C++)
WinForms + Axiom (.NET)
Qt + Irrlicht (C++)
Which do you think would be the best option? Could you recommend me some other possibility?
Thanks in advance!
I spent a heap of time developing with Mogre (a C# wrapper around Ogre) and WinForms. In my opinion it's a good combination because you can develop the GUI much faster in C# WinForms than any of the C++ options.
If you don't mind using a C# wrapper around the C++ Ogre library I recommend using Mogre rather than Axiom. It is very stable, has some good maintainers and keeps up with the latest version of Ogre pretty well. Any code on the Ogre forums can easily be ported to C# because most of the API is identical.
Axiom is a pure .NET port of Ogre, although it lags a few versions behind and may have some missing features. I haven't spent a lot of time with it but I believe it's main strength is that it's all managed code, if that's important to you.
There's an open source project called Glue Editor that I started a while ago. It's no longer maintained but it has a lot of code you can use to get Mogre working with WinForms. You should be able to download the repository and compile it out of the box. You're welcome to take the code and use it however you like.
https://bitbucket.org/glue/glueeditor/src
If you decide to go down the Qt + Ogre path there's a project called Ogitor you might want to check out.
https://bitbucket.org/jacmoe/ogitor/src
You might also want to check out XNA and MonoGame. XNA is Microsofts framework for making games in C#. It is fairly bare bones but it has a much lower learning curve than Ogre, Mogre or Axiom. MonoGame is an open source implementation of the XNA framework that works on non-Microsoft platforms (e.g. Android, iOS, Linux).
http://monogame.codeplex.com/
I recommend Qt + Ogre (C++), although I have to confess this is the only combination from your list I have much experience with. The good thing about Ogre is the amount of documentation and the active community. So many questions are answered and documented. The graphics itself can probably be created in all library combinations. However, I like the easy intergration of object interaction in Ogre. The standard is based on bounding boxes, however there is code available for triangle intersection as well. Wish you luck!
I wrote a program in C++/OpenGL (using Dev-C++ compiler) for my calculus 2 class. The teacher liked the program and he requested me to somehow put it online so that instead of downloading the .exe I can just run it on the web browser. Kinda like java applets run on the browser.
The question is:
How if possible, can I display a C++/OpenGL program in a web browser?
I am thinking of moving to JOGL which is a java interpretation of OpenGL but I rather stay in C++ since I am more familiar with it.
Also is there any other better and easier 3D web base API that I can consider?
There is a lot activity recently with WebGL. It is a binding for Javascript to native OpenGL ES 2.0 implementations, designed as an extension of the canvas HTML5 element.
It is supported by the nightly builds of Firefox, Safari, Chrome and Opera.
Have a look at these tutorials, based on the well known NeHe OpenGL tutorials.
Several projects based on WebGL are emerging, most notably Scenegraphs APIs.
From Indie teams: SceneJS, GLGE, SpiderGL.
From Google: the team behind O3D plugin is trying to implement a pure WebGL backend (source) for the project, so that no plugin will be necessary.
From W3C/Web3D: There is an ongoing discussion to include X3D as part of any HTML5 DOM tree, much like SVG in HTML4. The X3DOM project was born last year to support this idea. Now it is using WebGL as its render backend, and is version 1.0 since March 2010.
I'm almost sure that WebGL is the way to go in the near future. Mozilla/Google/Apple/Opera are promoting it, and if the technology works and there is sufficient customer/developer demand, maybe Microsoft will implement it on IE (let's hope that there will be no "WebDX"!).
AFAIK, there's only 3 options:
Java. it includes the whole OpenGL stack.
Google's Native Client (NaCL), essentially it's a plugin that let's you run executable x86 code. Just compile it and call it from HTML. Highly experimental, and nobody will have it already installed. Not sure if it gives you access to OpenGL libraries.
Canvas:3D. Another very experimental project. This is an accelerated 3D API accessible from JavaScript. AFAICT, it's only on experimental builds of Firefox.
I'd go for Java, if at all.
OTOH, if it's mostly vectorial works (without lots of textures and illumination/shadows), you might make it work on SVG simply by projecting your vectors from 3D to 2D. In that case, you can achieve cross-browser compatibility using SVGWeb, it's a simple JavaScript library that allows you to transparently use either the browser's native SVG support or a Flash-based SVG renderer.
Do you really have the time to rewrite it? I thought students were meant to be too busy for non-essential assignment work.
But if you really want to do it, perhaps a preview of it running as a flash movie is the easiest way. Then it's just a matter of doing that and you could provide a download link to the real application if people are interested.
Outside of Java, in-browser OpenGL is really in its infancy. Google's launched a really cool API and plugin for it though. It's called O3D:
http://code.google.com/apis/o3d/
Article about the overall initiative:
http://www.macworld.com/article/142079/2009/08/webgl.html
It's not OpenGL, but the Web3D Consortium's X3D specification may be of interest.
Another solution is to use Emscripten (a source-to-source compiler).
Emscripten supports C/C++ and OpenGL and will translate the source into html/JavaScript.
To use Emscripten you will need to use SDL as a platform abstraction layer (for getting an OpenGL context as well as loading images).
Emscripten is currently being used in Unreal Engine and will also be used in the Unity 5 engine.
Read more about the project here:
https://github.com/kripken/emscripten
Two approaches:
Switch to Java. However, your application will suffer from a loss of performance as a trade off for portability. But since Java is everywhere, this approach ensures that your code can be executed in most browsers.
Use ActiveX, which allows you to run native binary code for Microsoft Windows. This is not recommended in production because activeX is well known as a potential security hole, but since your lecturer is the one viewing it, security doesn't seem to be a big deal. This is applicable for Microsoft platform (Windows+IE) only.
I have a large MFC C++ application that I would be very keen to port into AutoCAD and IntelliCAD. AutoDesk offer Object ARX for this purpose, which replaces the older and slower ADS technology. IntelliCAD, afaik only supports ADS. Has anyone out there done this, and if so which tools did you use and what pitfalls did you encounter?
I'm specifically interested in resources that will simplify the transition, and allow me to maintain seperate CAD based and standalone versions going forward.
Have a look at my answers to a couple of previous AutoCAD questions
Open source cad drawing (dwg) library in C#
.Net CAD component that can read/write dxf/ dwg files
If you were looking for the same code base to work both inside and outside of AutoCAD then the RealDWG approach may work for you since the code is the same - RealDWG doesn't need AutoCAD as a host application. The open Design Alliance libraries are for making stand-alone applications. Both have supported C++ for years & can be considered stable - well, as stable as CAD gets.
This blog (http://through-the-interface.typepad.com/) is a good one for RealDWG
One option to consider is to target AutoCAD and Bricscad. Supporting AutoCAD and IntelliCAD requires essentially two versions of code. Bricscad's goal is to be completely compatible with ObjectARX, and in my experience they are pretty close.
This at least simplifies the problem from supporting three instances (your standalone version, AutoCAD, and IntelliCAD) to supporting two instances (your standalone version and AutoCAD/Bricscad).
"DWGdirect is not just a SDK to read and write DWG files. It actually offers a full blown framework that can be used to develop a professional CAD application, complete with plug-in architecture and all." quote source