On Wednesday, 20 November 2013 at 10:20:06 UTC, Rene Zwanenburg wrote:
> On Wednesday, 20 November 2013 at 09:15:41 UTC, Rene Zwanenburg wrote:
>> Hi,
>>
>> A few things jumped out at me:
>>
>> Camera.d:
>>
>> ...
>>
>> Oops, I have to run.. Will take a look at the rest later.
>
> Still regarding camera.d:
>
> - The glfw3 import appears to be unused and can be removed.
>
> - the call to Math.perspectiveGL modifies OpenGL state. Your math functions _really_ shouldn't interact with OpenGL.
>
> - Taking the previous point a bit further, your Camera class doesn't need to know about OpenGL either. In your rendering routine, get the camera matrices from a camera and pass them to OpenGL.
>
> - Like Paulo said, don't use the fixed function pipeline. If you're not familiar with 3D yet the FFP is easier to use at first, but using modern OpenGL will pay for itself in the long run. I don't know where to find a good introduction to modern OpenGL though, perhaps someone else around here..
>
> ...

Here are two possibilities using modern pipeline:

http://www.mbsoftworks.sk/index.php?page=tutorials&series=1

http://www.swiftless.com/opengl4tuts.html

Both of them are Windows based though, but it should be enough to get started.

--
Paulo

On Wednesday, 20 November 2013 at 15:30:32 UTC, Geancarlo Rocha wrote:
> You should fix your LICENSE following these instructions http://www.gnu.org/licenses/gpl-howto.html. I hope you understand the virality of GPL and why most people won't touch your code for real work.
>

Yeah I know, have any better ideas that is at least similar enough to the GPL?

On Wednesday, 20 November 2013 at 10:20:06 UTC, Rene Zwanenburg wrote:
> On Wednesday, 20 November 2013 at 09:15:41 UTC, Rene Zwanenburg wrote:
>> Hi,
>>
>> A few things jumped out at me:
>>
>> Camera.d:
>>
>> ...
>>
>> Oops, I have to run.. Will take a look at the rest later.
>
> Still regarding camera.d:
>
> - The glfw3 import appears to be unused and can be removed.
>
> - the call to Math.perspectiveGL modifies OpenGL state. Your math functions _really_ shouldn't interact with OpenGL.
>
> - Taking the previous point a bit further, your Camera class doesn't need to know about OpenGL either. In your rendering routine, get the camera matrices from a camera and pass them to OpenGL.
>
> - Like Paulo said, don't use the fixed function pipeline. If you're not familiar with 3D yet the FFP is easier to use at first, but using modern OpenGL will pay for itself in the long run. I don't know where to find a good introduction to modern OpenGL though, perhaps someone else around here..
>
> - rotate, move are unnecessary. Once you switch to gl3n, move becomes:
> camera.position += someVector;
> Same thing with rotate, only you multiply:
> camera.rotation *= someQuaternion;
>
>
> math.d:
>
> - D allows free functions. There's no need to use hacks like completely static classes. You can remove the Math class and put it's functions in the module.
>
> - I'd also make std.math a public import, so you only have to import your math to get both in another module.
>
> - perspectiveGL doesn't belong here, but this is fixed by using gl3n.
>
>
> time.d
>
> - Same thing with the statics as in math. Though personally I'd call Time Timer, and make instances. You'll probably want to have more than one timer.
>
> - Sleeping doesn't belong in the timer. It should only calculate total running time and delta time in update. Later on you'll probably find out it needs more features, but these two will be fine for now. If anywhere, sleeping belongs in the game loop. That being said I'd advise against sleeping at all. It's usually better to use vsync, or run at max fps if the user disables it.
>
>
> That's all I could find during a quick peek.. If you'd like me to clarify some of these points, please don't hesitate to ask!

Interesting, would you give me an example of the @property and the timer stuff, if that's all right with you?

I've attempted doing the @property stuff, but I run into lots of problems, so maybe your example will show me what I've done wrong.

On Wednesday, 20 November 2013 at 16:40:59 UTC, Mineko wrote:
> On Wednesday, 20 November 2013 at 15:30:32 UTC, Geancarlo Rocha wrote:
>> You should fix your LICENSE following these instructions http://www.gnu.org/licenses/gpl-howto.html. I hope you understand the virality of GPL and why most people won't touch your code for real work.
>>
>
> Yeah I know, have any better ideas that is at least similar enough to the GPL?

I would suggest dual license.

GPL for open source projects and something else for commercial projects.

It all depends how you see companies using your code, without any kind of retribution or recognition. I see this happening all the time in the SaaS enterprise space I work on.

For many companies open source means free beer.

I wonder how much Sony was given back to the open source projects that make up the PS4 besides the license note, for example.

http://www.scei.co.jp/ps4-license/

Anyway it is your project, so it is up to you to decide what license to use.

--
Paulo

On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote:
>
> I would suggest dual license.
>
> GPL for open source projects and something else for commercial projects.
>
> It all depends how you see companies using your code, without any kind of retribution or recognition. I see this happening all the time in the SaaS enterprise space I work on.
>
> For many companies open source means free beer.
>
> I wonder how much Sony was given back to the open source projects that make up the PS4 besides the license note, for example.
>
> http://www.scei.co.jp/ps4-license/
>
> Anyway it is your project, so it is up to you to decide what license to use.
>
> --
> Paulo

Ahh ok, I was worried when you said that the GPL was viral, I was planning on a dual license, GPL for the actual engine, and maybe boost or something for the actual assets, of course that depends on who uses the code, as long as the engine itself is free and redistributed intact then everything is fine.

On Wednesday, 20 November 2013 at 20:00:17 UTC, Mineko wrote:
> On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote:
>
> as long as the engine itself is free and redistributed intact then everything is fine.

Then you are probably looking at a LGPL license. I'm not gonna
explain in deep the differences but keeping it short:
If a library is GPL, then the whole project must be redistributed
as GPL software. If someone uses your code and uses in a broader
project, the whole project would need to be GPL too.
If a library is LGPL, then the modified library must be
redistributed as LGPL library. If someone uses and/or modifies
your library in a broader project, only the library will need to
be redistributed as open.

EG: one takes your game engine and links it against some other
libraries to make a full game (eg: adding networking, scripting
engine, etc). If the license is LGPL, everything is fine. If
license is GPL, he will need to release everything as GPL.
Something this isn't even possible due to license
incompatibilities. However, if he modifies your library (like,
adds something to rendering routines), he has to release the
modified code, doesn't matter if it's GPL or LGPL.

Last but not least, the copyright holder (you) can relicense the
work at any time.

On Wednesday, 20 November 2013 at 20:57:11 UTC, Franz wrote:
> On Wednesday, 20 November 2013 at 20:00:17 UTC, Mineko wrote:
>> On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote:
>>
>> as long as the engine itself is free and redistributed intact then everything is fine.
>
> Then you are probably looking at a LGPL license. I'm not gonna
> explain in deep the differences but keeping it short:
> If a library is GPL, then the whole project must be redistributed
> as GPL software. If someone uses your code and uses in a broader
> project, the whole project would need to be GPL too.
> If a library is LGPL, then the modified library must be
> redistributed as LGPL library. If someone uses and/or modifies
> your library in a broader project, only the library will need to
> be redistributed as open.
>
> EG: one takes your game engine and links it against some other
> libraries to make a full game (eg: adding networking, scripting
> engine, etc). If the license is LGPL, everything is fine. If
> license is GPL, he will need to release everything as GPL.
> Something this isn't even possible due to license
> incompatibilities. However, if he modifies your library (like,
> adds something to rendering routines), he has to release the
> modified code, doesn't matter if it's GPL or LGPL.
>
> Last but not least, the copyright holder (you) can relicense the
> work at any time.

Finally.. I finally got a clear explanation of the LGPL, I was on the fence about it but ended up going with GPl, now that I know though I'll convert it to LGPL, much thanks.

On Wednesday, 20 November 2013 at 21:13:05 UTC, Mineko wrote:
> On Wednesday, 20 November 2013 at 20:57:11 UTC, Franz wrote:
>> On Wednesday, 20 November 2013 at 20:00:17 UTC, Mineko wrote:
>>> On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote:
>>>
>>> as long as the engine itself is free and redistributed intact then everything is fine.
>>
>> Then you are probably looking at a LGPL license. I'm not gonna
>> explain in deep the differences but keeping it short:
>> If a library is GPL, then the whole project must be redistributed
>> as GPL software. If someone uses your code and uses in a broader
>> project, the whole project would need to be GPL too.
>> If a library is LGPL, then the modified library must be
>> redistributed as LGPL library. If someone uses and/or modifies
>> your library in a broader project, only the library will need to
>> be redistributed as open.
>>
>> EG: one takes your game engine and links it against some other
>> libraries to make a full game (eg: adding networking, scripting
>> engine, etc). If the license is LGPL, everything is fine. If
>> license is GPL, he will need to release everything as GPL.
>> Something this isn't even possible due to license
>> incompatibilities. However, if he modifies your library (like,
>> adds something to rendering routines), he has to release the
>> modified code, doesn't matter if it's GPL or LGPL.
>>
>> Last but not least, the copyright holder (you) can relicense the
>> work at any time.
>
> Finally.. I finally got a clear explanation of the LGPL, I was on the fence about it but ended up going with GPl, now that I know though I'll convert it to LGPL, much thanks.

Take note that LGPL is only valid as long as you only use dynamic linking.

If you use static linking, it is under the same obligations as pure GPL.

--
Paulo

On Wednesday, 20 November 2013 at 09:15:41 UTC, Rene Zwanenburg wrote:
>
> Hi,
>
> A few things jumped out at me:
>
> Camera.d:
>
> - The use of x, y, z and rx, ry, rz. These should really be in some vector struct. Since you're using Dub, you can easily use gl3n [1][2]. While it's still pretty basic, should be more than enough to get you started.
>
> - Use Quaternions to store your rotations instead of euler angles.
>
> - You can use @property instead of trivial getters and setters
>
> - You may want to store your camera matrices in the camera class, and pass them to OpenGL when rendering. These matrices can be useful, and you don't want to use glGet* functions ever if you care about performance ;). gl3n provides matrix structs and facilities to create projection matrices and the like.
>
> Oops, I have to run.. Will take a look at the rest later.
>
> [1] http://dav1dde.github.io/gl3n/index.html
> [2] http://code.dlang.org/packages/gl3n

After a bit of careful study I figured out how @property works, I just implemented it wrong last time, very helpful, thanks.

On Wednesday, 20 November 2013 at 16:40:59 UTC, Mineko wrote:
> On Wednesday, 20 November 2013 at 15:30:32 UTC, Geancarlo Rocha wrote:
>> You should fix your LICENSE following these instructions http://www.gnu.org/licenses/gpl-howto.html. I hope you understand the virality of GPL and why most people won't touch your code for real work.
>>
>
> Yeah I know, have any better ideas that is at least similar enough to the GPL?

You could try my little wizard:

http://beza1e1.tuxen.de/licences/