On Aug 18, 2012, at 10:55 PM, Peter C. wrote:
> Alright, fair enough, I know the feeling about open source and having real 
> life to attend to.

A clarification here: realXtend is very much real life for many of us here, as 
in the full time job that we attend to. Adminotech bases it's whole business on 
and realXtend, providing Tundra hosting and application development (and later 
possibly adds browser based views to the worlds too). It is the sole business 
of the company and they have several employees etc. Also CyberLightning (Jani 
Pirkola's company) is building a business on realXtend, their current first 
products CyberSlide and CyberTeam are customized Tundra installs with 
proprietary additions. Ludocraft also has products and delivers customer 
solutions using Tundra, although other technologies too. Spinningwire in 
Germany, whose project the Berlin Gallery Weekend project was, is also building 
a business on realXtend (so far mostly Tundra but with good experience from 
Lehto now too -- they don't do games that much but art and collaboration spaces 
where it may be a good fit too). The guys working in the research project 
chiru.cie.fi (some 6 devs or so) work fulltime, doing research by implementing 
things in Tundra and WebNaali.

But yes the open source part shows in the public offering -- no one is selling 
the realXtend platform itself as a business, as a tool for developers, so 
marketing and documenting on that side is weak.  Adminotech, targeting hosting 
business, does this in a way, and there is actually nice Tundra developer 
documentation coming to the web by them soon (Jonne gave a little pre-peek of 
the work-in-progress site). Anyhow this dilemma is something we'll certainly 
discuss in the Mon (assocication) and Wed (foundation) meetings.

> I'm currently planning out an open source project, and the reason I asked was 
> I was worried that Tundra was going to go web client centric (which would 
> kill it's usefulness to the project I'm

Right -- so that is definitely not happening.

> planning). Regarding QT and Ogre; some of the Ogre GSOC projects look really 
> interesting (especially involving terrain), and I really hope they get merged 
> in to at least a branch of the Safe Ogre soon, or better yet that Safe Ogre 
> pushes a merge request with main Ogre for the stability fixes.

Yep, I think we'll manage ok there. The safe-no-crashes branch has no feature 
related changes so merging is AFAIK easy enough, I hope both ways.

> As for QT, while it's nice for applications and as a framework, it's really 
> not high enough performance for games. It never really was intended as a game 
> GUI, so personally I would suggest another toolkit on performance grounds, 
> but that's another discussion. Right now I'm preparing for the coming school 
> semester and working on getting my bearings with this open source work I'm 
> doing.

As your later post pointed out, the problem is not Qt and with this regard GUI, 
but you probably meant the C++ <-> Javascript interfacing of qtscript.

One quite straightforward way to speed that up for core things such as moving 
objects around etc. *might* be to wrap the related c++ classes statically, 
instead of using the current & automatic fully dynamic system (without any 
wrapper code). I mean how qt itself is wrapped with compiled c++ wrapper 
classes in qtscript libraries, as opposed to using the qt properties & slots 
mechanism for the JS access. I don't remember if we talked with Jukka already 
if this could work, but anyhow it's simple to test as the qt bindings made that 
way are always there in Tundra. If that would not help, I figure we should just 
resort to some normal direct binding method (for example just write V8 bindings 
by hand or with some binding generator tool, haven't studied this recently). 
The automatic qtscript mechanism is very nice though for the 
non-performance-critical parts.

For GUIs btw there is now an alternative way of using Ogre surfaces directly, 
also from scripts, for performance reasons (drawing animated GUis from Qt to 
Ogre in Tundra is IIRC still slow too). Jukka made that last spring or so, I 
don't unfortunately recall now whether there's an example somewhere.

Thanks for the feedback and information -- it is very important for us to know 
about needs and perceptions from out there!

> Peter

~Toni

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Reply via email to