Google Native Client, Qt or Both?

[THe Floating Brain]

Good day

I know I kinda have a post about this: http://elysianshadows.com/phpBB3/viewto ... f=6&t=6567
But I am now more seriously considering either useing Google Native Client (NaCl) or Qt.
Mainly I am questioning this beacues I plan to re-write my engine (for the most part), and I
would love to support the following features (this design derision may interfear with these
particular features):

Code: Select all

	* : Non invasive framework.
	* : Easy modification of the engine.
	* : Easy implementation of any scripting language a developer wants to use (Lua by default).
	* : 3-D rendering (models, primitives, 2d surfaces, water, ect).
	* : Lightning.
	* : Particals.
	* : I/O library (keyborad and mouse as well as files).
	* : Custom collision areas (my own invention called "Scan Areas", envovls file IO).

Here are the pros and cons (from this list you can see why I have my concerns):

Code: Select all

	* : Pros: What Both Share Or Can Share: 
		* : Qt threading (threading is needed for NaCl).
		* : OpenGL E.S 2.0
		* : Lua... kinda.
		* : Linux, Windows, Mac OS (cross-platform).

Code: Select all

	* : Cons: NaCl: 
		* : Not all scripting languages have a "port" to NaCl like Lua.
		* : I dont know OpenGL E.S 2.0, and I would have to fight Qt's
		OpenGL framwork semantics with Glut.
		* : Rendering has it's limitations.
		* : IO is very limited and "secure".
		* : Supports Chrom OS but Qt does not.
		* : Console based, no plug-in, no IDE (not that that is bad, its just slow).
		* : Not familiar with it what so ever.
		* : Forced to use Pepper API.
		* : Slightly less performence.
		* : Probably hard to update.
		* : I assume the "Lua port" is kinda limted like rendering
		and all forms of IO.

Code: Select all

	* : Pros: NaCl: 
                * : Can be viewed in browser (of course).
		* : Chrome OS is more modern than Unix (which Qt Supports).
		* : Other game engines are doing it (Unity, Bullet (physics), ect.), and its 
		kinda the "way of the future".

Code: Select all

	* : Cons: Qt: 
		* : Hard to link anything with a window 0.0.
		* : Supports Unix (NaCl does not).

Code: Select all

	* : Pros: Qt: 
		* : Very familiar with it.
		* : I know glut (mostly).
		* : Slightly faster performence.
		* : Unix probably has more users.
		* : Some features are supported in Nacl.
		* : No hinderance to using variouse scripting langauges.
		* : Easy to update.
		* : No issues with any kind of IO or rendering.
		* : Good experance, (I looked, many C++ development jobs look for you to
		have experance with Qt).

A big factor here is 'Other game engines are doing it, and its kinda the "way of the future".', and the fact that it may be hard to integrate various scripting languages with NaCl. So I really would like to here the opinion of my fellow programmers on this matter. Should I support both NaCl and Qt (maybe make some sort of interface library) or just one, and if so;
which one?

Thank you for reading :-D

P.s: It should be noted that I plan to have browser based development tools for my engine and
cloud storage.

P.s.s: http://www.youtube.com/watch?v=R281PhQufHo dont watch the who thing of you do not want
to I just suggest skiming it a little.

[Falco Girgis]

As I am continually telling people, QT is a framework designed to handle GUI-based applications. Sure, you can make games with it, but I wouldn't recommend it. That's a gigantic amount of overhead for a game, and it's using the framework for something it was never intended to do.

[THe Floating Brain]

As I am continually telling people, QT is a framework designed to handle GUI-based applications. Sure, you can make games with it, but I wouldn't recommend it. That's a gigantic amount of overhead for a game, and it's using the framework for something it was never intended to do.

For the most part I agree, however I have taken this in-to consideration. I would mainly
be using Qt for it's cross-platform dependability (curticy of gcc I assume) openGL, input, and maybe threads. From what I have seen these can probably be implemented in a very modular, non-invasive fasion. Additonally like I said, not very many things having to do with IO in general and scripting are not supported by NaCl.