XL Engine source code release!

Not about OpenMW? Just about Morrowind in general? Have some random babble? Kindly direct it here.
User avatar
psi29a
Posts: 4675
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: XL Engine source code release!

Post by psi29a » 05 Apr 2018, 11:19

More fun with virtuals... anyone have a nice solution here?

https://github.com/Mindwerks/XLEngine/b ... te.cpp#L17
https://github.com/Mindwerks/XLEngine/b ... nent.h#L14

Code: Select all

OrientedSprite.cpp: In destructor ‘virtual OrientedSprite::~OrientedSprite()’:
OrientedSprite.cpp:17:36: error: no matching function for call to ‘OrientedSprite::~OrientedSprite()’
  RenderComponent::~RenderComponent();
                                    ^
In file included from Object.h:8:0,
                 from OrientedSprite.cpp:1:
RenderComponent.h:14:10: note: candidate: ‘virtual RenderComponent::~RenderComponent()’
  virtual ~RenderComponent(){};
          ^
RenderComponent.h:14:10: note:   candidate expects 1 argument, 0 provided
Sprite_ZAxis.cpp: In destructor ‘virtual Sprite_ZAxis::~Sprite_ZAxis()’:
Sprite_ZAxis.cpp:25:36: error: no matching function for call to ‘Sprite_ZAxis::~Sprite_ZAxis()’
  RenderComponent::~RenderComponent();
                                    ^
In file included from Object.h:8:0,
                 from Sprite_ZAxis.cpp:1:
RenderComponent.h:14:10: note: candidate: ‘virtual RenderComponent::~RenderComponent()’
  virtual ~RenderComponent(){};
          ^
Is this necessary? Can we remove RenderComponent::~RenderComponent(); ? Doesn't the compiler do this for us? It says it is missing an argument, so I could do this:
RenderComponent::~RenderComponent(1);
and it compiles... but I don't see the point.



Is this the correct solution?

Code: Select all

diff --git a/world/OrientedSprite.cpp b/world/OrientedSprite.cpp
index a56d6df..72b72cd 100644
--- a/world/OrientedSprite.cpp
+++ b/world/OrientedSprite.cpp
@@ -12,10 +12,6 @@ OrientedSprite::OrientedSprite() : RenderComponent()
        m_fAlpha = 1.0f;
 }
 
-OrientedSprite::~OrientedSprite()
-{
-       RenderComponent::~RenderComponent();
-}
 
 void OrientedSprite::Render(Object *pObj, IDriver3D *pDriver, f32 fIntensity, const Vector3& vOffset)
 {
diff --git a/world/OrientedSprite.h b/world/OrientedSprite.h
index 0ca2ad8..e791c36 100644
--- a/world/OrientedSprite.h
+++ b/world/OrientedSprite.h
@@ -11,7 +11,7 @@ class OrientedSprite : public RenderComponent
 {
 public:
        OrientedSprite();
-       virtual ~OrientedSprite();
+       virtual ~OrientedSprite(){};
 
        void Render(Object *pObj, IDriver3D *pDriver, f32 fIntensity, const Vector3& vOffset);
        void SetUV_Flip(bool bFlipX, bool bFlipY, bool bFlipAxis=false) { m_aFlip[0] = bFlipX?1:0; m_aFlip[1] = bFlipY?1:0; m_aFlip[2] = bFlipAxis?1:0; }

User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: XL Engine source code release!

Post by drummyfish » 05 Apr 2018, 11:50

The issue of licensing came up on GitHub so I'd like to also ask here:

If GPL components were used in the further development, would it require our code to be GPL too, or could it stay MIT?

I personally think it has to be GPLed, psi29a says that if we limit ourselves to dynamic linking, it can stay MIT. Any licensing expert here? Opinions on what license would best be used?

User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: XL Engine source code release!

Post by drummyfish » 05 Apr 2018, 11:54

psi29a wrote:
05 Apr 2018, 11:19
Is this necessary? Can we remove RenderComponent::~RenderComponent(); ? Doesn't the compiler do this for us?
I think it can be removed, C++ does this automatically. Probably something older C++ versions required or what MSVC just tolerated.

User avatar
lysol
Posts: 1360
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: XL Engine source code release!

Post by lysol » 05 Apr 2018, 12:21

Congrats on the first pull request Drummyfish! :)
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
AnyOldName3
Posts: 1594
Joined: 26 Nov 2015, 03:25

Re: XL Engine source code release!

Post by AnyOldName3 » 05 Apr 2018, 12:29

I'm confused as to why a destructor could need an argument as it's a member function and should, therefore, have access to everything it needs.
AnyOldName3, Master of Shadows

User avatar
psi29a
Posts: 4675
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: XL Engine source code release!

Post by psi29a » 05 Apr 2018, 13:27

drummyfish wrote:
05 Apr 2018, 11:50
The issue of licensing came up on GitHub so I'd like to also ask here:

If GPL components were used in the further development, would it require our code to be GPL too, or could it stay MIT?

I personally think it has to be GPLed, psi29a says that if we limit ourselves to dynamic linking, it can stay MIT. Any licensing expert here? Opinions on what license would best be used?
The code can remain MIT/Expat even if the binary is GPL because of GPL code being included in the resulting binary through statically being linked against something GPL. When you distribute the binary, the GPL extends itself to the whole of the binary and requires that the code being used to be available under the terms of the GPL. That does not change the license of the code on Github, only the code that is distributed with GPL "infected" binary. So that copy of the code is now under the GPL, but not what is upstream on github.

This happens all the time.

Every time you ship a new release with a statically compiled binary, you have to abide by the terms of all the licenses it is licensed under, provided the licenses are compatible. MIT and GPL are compatible, meaning that MIT gets subsumed by the GPL since GPL is strong copy-left. It also means that all the code the GPL comes in contact with also be GPL so you ship the release with GPL code that was originally licensed as MIT. This happens at release time.

The upstream code still remains MIT.

The only time upstream code will become GPL is when GPL code is then introduced into the repo. Then the code, as a whole, would be under the terms of the GPL as well. So we make sure that all code that gets accepted is under the MIT license, which is implicit when you send a PR, that you agree with the LICENSE in the repo.

Clear as mud? :)

What other questions do you have? What exactly are your concerns?

TL;DR: GPL just asks for a copy of the code under the GPL, not that the original (upstream) code become GPL.

User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: XL Engine source code release!

Post by drummyfish » 05 Apr 2018, 14:29

psi29a wrote:
05 Apr 2018, 13:27
The only time upstream code will become GPL is when GPL code is then introduced into the repo.
Then I guess you could always circumvent GPL by only ever storing diffs. So not quite convinced yet, but I'm leaving this issue for until I hear more opinions, let's keep it the way it is for now :)

User avatar
Greendogo
Posts: 1413
Joined: 26 Aug 2011, 02:04

Re: XL Engine source code release!

Post by Greendogo » 05 Apr 2018, 16:30

Lol, nice getting that online, psi29a! :D

User avatar
psi29a
Posts: 4675
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: XL Engine source code release!

Post by psi29a » 05 Apr 2018, 17:32

drummyfish wrote:
05 Apr 2018, 14:29
psi29a wrote:
05 Apr 2018, 13:27
The only time upstream code will become GPL is when GPL code is then introduced into the repo.
Then I guess you could always circumvent GPL by only ever storing diffs. So not quite convinced yet, but I'm leaving this issue for until I hear more opinions, let's keep it the way it is for now :)
Not possible, if someone says their code is bound by the GPL (in the header/preamble or by agreement or by stating so in the PR) then that code, in the file is GPL. The author of any code that is written by them is the ultimate copyright holder, only that author has the right to assign a license to that copy of code. You assign a license implicitly (MIT/Expat) when you create a PR to the project by acknowledging the LICENSE. The only way you change this is by stating in your PR that you license the code in your PR under a different license. You also risk it being rejected for that reason. ;)

Even the diff is GPL, so no circumvention is possible.

It is entirely possible to revert that commit (or remove that line of GPL code) to revert the file back to the original license.

This has happened with other projects.

Anyway, this is a theoretical discussion, I believe, because we do not link statically to anything. Correct?

User avatar
psi29a
Posts: 4675
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: XL Engine source code release!

Post by psi29a » 05 Apr 2018, 21:48

One the last stepping stones is this:

Code: Select all

In file included from scriptstdstring.h:14:0,
                 from scriptstdstring.cpp:3:
scriptstdstring.cpp: In function ‘void RegisterStdString_Native(asIScriptEngine*)’:
angelscript.h:355:77: error: invalid static_cast from type ‘<unresolved overloaded function type>’ to type ‘bool (*)(const string&, const string&) {aka bool (*)(const std::__cxx11::basic_string<char>&, const std::__cxx11::basic_string<char>&)}’
 #define asFUNCTIONPR(f,p,r) asFunctionPtr((void (*)())(static_cast<r (*)p>(f)))
                                                                             ^
scriptstdstring.cpp:577:86: note: in expansion of macro ‘asFUNCTIONPR’
  r = engine->RegisterObjectMethod("string", "bool opEquals(const string &in) const", asFUNCTIONPR(operator ==, (const string &, const string &), bool), asCALL_CDECL_OBJFIRST); assert( r >= 0 );
   
https://github.com/Mindwerks/XLEngine/b ... g.cpp#L577


Any ideas?

If I comment out that line, it compiles and then we get:
Screenshot from 2018-04-05 23-33-43.png
It Lives! :)

Post Reply