fix to a regression with ParticleSystem loading

[Toni Alatalo]

Hi, for info in case someone encounters the same and doesn't check the tracker / pull requests, and also to note that we should handle his somehow:

I encountered problems with using particle systems now, they don't load. Same scenes work with older versions.

Reverting the recent refactor to use the new AttributeChanged signal biz fixed the problem, so something goes awry with my scene&assets and the new code.

I made two pull requests: one with the minimal example scene which could be included in the Tundra scenes. But better do that when it actually works :) -- https://github.com/realXtend/naali/pull/608

Other pull request is for my current fix for the problem, which is simply to revert the refactor. https://github.com/realXtend/naali/pull/609

There's an open issue about this too, https://github.com/realXtend/naali/issues/607

Somehow other particle systems work with the new refactored code, though, for example the snow in RMP.

~Toni

[antont]

Update: I spotted the actual prob (was just a typo in the override of the AttributesChanged handler ('Attibute')), applied a proper non-reverting fix and pulled the minimal particle example scene in now too as it works.

Is quite unfortunate that c++ hasn't had a cross plat way of failing to build when source has such typos, took a quick look at the discussion in stackoverflow which says "Since g++ 4.7 it does understand the new C++11 override keyword", perhaps we can start adopting that at some point? My gcc in a bit old ubuntu (12.04) seems to be 4.6 still. http://stackoverflow.com/questions/497630/safely-override-c-virtual-functions

~Toni 

[Ali Kämäräinen]

Although as tempting it would be to use C++11, personally don't think it's sensible until all of the major compilers somewhat fully support it. In practice  I'd guess this means waiting at least one year or so.

[Jonne Nauha]

Yeah we really can't sprinkle c++11 features around the codebase. Windows is lacking behind here even if we get the VC2010 deps path working. Additionally >=VC2010 will drop VLC out which is too high of a price for us at Meshmoon at least to pay. So I don't see us moving to new compilers before VLC moves to them.

This override keyword probably could be used with TUNDRA_OVERRIDE typedef or something similar, adding it to CoreDefines.h. It would be empty for VC9 and "override" where applicable. To be honest this is not even the most useful feature that we should use if c++11 would be free reign. I think proper copy constructors and stuff like that for our structs and classes could speed up things nicely.

Anyone have info how to cross compile to VC10/12 binary in linux or something like cygwin on windows? I've tried looking into it numerous times but cant seem to find anything :P This might let us build VLC for those platforms, then I would be happy moving to VC10.

Best regards,
Jonne Nauha
Adminotech developer

On Sat, Jan 26, 2013 at 3:55 PM, Ali Kämäräinen <stink...@gmail.com> wrote:

Although as tempting it would be to use C++11, personally don't think it's sensible until all of the major compilers somewhat fully support it. In practice  I'd guess this means waiting at least one year or so.

--
--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org
 
 

[Ali Kämäräinen]

Actually in Visual Studio override keyword has been implemented already since VC8 as a nonstandard extension part of the C++/CLI, so in theory certain C++11 features would be doable already. But naturally these keywords would have to be defined to empty when using e.g. older GCC. "Proper copy constructors" (by which I think Jonne means move constructors ;) could be easily implemented by ifdeffing the code.

[Jonne Nauha]

Yeh sorry I meant the new move operators.

On 27 Jan 2013 16:53, "Ali Kämäräinen" <stink...@gmail.com> wrote:
>
> Actually in Visual Studio override keyword has been implemented already since VC8 as a nonstandard extension part of the C++/CLI, so in theory certain C++11 features would be doable already. But naturally these keywords would have to be defined to empty when using e.g. older GCC. "Proper copy constructors" (by which I think Jonne means move constructors ;) could be easily implemented by ifdeffing the code.
>