Irrlicht Engine

Right - after digging a little deeper i found:.


For Example in the class CCgUniform
virtual void update(const void* data, const SMaterial& material) const = 0 _IRR_OVERRIDE_;
the GCC compiler says
error: 'override' does not name a type
which is a bit confusing.

If i change it to
virtual void update(const void* data, const SMaterial& material) const _IRR_OVERRIDE_;
it says
... marked override, but does not override.

AHA! - because it's a base class and cannot override something.

But there is also CCgUniform1f (and more) which inherit from CCgUniform.
So the _IRR_OVERRIDE_ must go there!


The Problem with CCgMaterialRenderer is something else (i just found out).

Somehow the gcc compiler wants the "keyword" override BEFORE the '= 0' !

So if i change
virtual void OnUnsetMaterial() = 0 _IRR_OVERRIDE_;
to
virtual void OnUnsetMaterial() _IRR_OVERRIDE_ = 0 ;

it works.


If this is true, then you would need different macros for different compilers which you place at different positions in the source.
Like:
virtual void OnUnsetMaterial() _IRR_OVERRIDE_GCC_ = 0 _IRR_OVERRIDE_MSVC_ ;


As far as i know it's a bug in GCC and will be corrected (in CLANG it works).
Maybe for now it's easiest NOT to use it with GCC:
So just change it in irrTypes.h:

#if (__GNUC__ >= 4 && __GNUC_MINOR__ >= 7)
#define _IRR_OVERRIDE_
#elif (_MSC_VER >= 1600 ) /* supported since MSVC 2010 */
#define _IRR_OVERRIDE_ override
#elif (__clang_major__ >= 3)
#define _IRR_OVERRIDE_ override
#else
#define _IRR_OVERRIDE_
#endif

Because 'override' is mainly a "help" to avoid errors and you probably develop the core engine with MSVC, there would be no disadvantages for the normal user who happens to like GCC. If you find errors with YOUR development environmont it should
be of ok for the rest of us.

I did something else. I changed irrTypes.h to:

#if (__GNUC__ >= 4 && __GNUC_MINOR__ >= 7)
#define _IRR_OVERRIDE_ override
#define _0_IRR_OVERRIDE_ override = 0
#elif (_MSC_VER >= 1600 ) /* supported since MSVC 2010 */
#define _IRR_OVERRIDE_ override
#define _0_IRR_OVERRIDE_ = 0 override
#elif (__clang_major__ >= 3)
#define _IRR_OVERRIDE_ override
#define _0_IRR_OVERRIDE_ = 0 override
#else
#define _IRR_OVERRIDE_
#endif

Then everywhere you need override with an abstract class ( = 0 ) you write _0_IRR_OVERRIDE_ .
With GCC it will become 'override = 0' and with the other compilers '= 0 override'.

Maybe MSVC and/or CLANG also can handle it like GCC? If so, then just write the _IRR_OVERRIDE_ before the '= 0'.


Sometimes i understand why they developed C# and JAVA - we would be writing games now and not fiddle around
with THESE things, hehe.

No, please don't remove the GCC support in this macro. It's important to get testing from different compilers, relying on one compiler only will not catch everything.

No, I think this is simply a syntax error that I produced, but did not see until now - as I don't have Cg support enabled.

>> ... simply a syntax error that I produced ...

depends - in CCgUniform the override is just wrong - it belongs into the derived classes.

The problem with the pure virtual functions ( ... = 0 override; ) is a bug in GCC.
There you must write ( ... override = 0; ).

Latest version should already work again. The flags were properly moved into the derived classes and the other pure virtuals were simply removed, as they are not necessary.

CuteAlien wrote:I can't tell about Software drivers as I don't think anyone except Thomas understands the fantastic burnings renderer. So once we drop the other one we would be left with a driver where a single coder knows his way around it. And I don't even know if/how active Thomas still is.

Wait! No! I still use Burnings!
Believe it or not, it actually works favorably over DX OR OpenGL on my PC, particularly with shaders. I'm not sure why. Also, I like the fact that I can modify more easily than the other drivers because it's all irrlicht C++. So it's not the ideal driver for most things, but it has its uses.

So please, don't drop Software Driver 2.

I think this quote was about not dropping any of the software drivers. But in case you are working of burnings driver, if you could add support for lines and other primitives in drawvertexprimitivelist, this would really help.

hybrid wrote:I think this quote was about not dropping any of the software drivers. But in case you are working of burnings driver, if you could add support for lines and other primitives in drawvertexprimitivelist, this would really help.

Okay, thanks.

As for editing it: I've thought about that, although I can vaguely see why he didn't do other primitives (or maybe he was tired of working on it - I have yet to find out). I'll look into that more though.

Hehe, no worries. We don't plan to drop burnings :-)

I find those "overrided" headers a lot more hard to read.