www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D game engine -- Any suggestions?

reply "Mineko" <uminekorox gmail.com> writes:
Yo, I'm starting off a new game engine designed around D, and I 
just wanted to know if some of you might be kind enough to review 
some of my base code and tell me if I need to change anything in 
it.. While it's small. ;_;

I'm still learning D, I quite like it, the power of C++ in some 
parts, and the ease of Java in others. (Good job Walter!)

Anyway here, check it out, only ones you really need to pay 
attention to are main.d, time.d, and input.d.

https://github.com/ICGCC/Breaker-3D-Game-Engine

Thanks for helping out a newbie, and if you want to contribute to 
it, even better!

..That and if I'm using the GPL right. >_____>"
Nov 19 2013
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 20 November 2013 at 07:48:21 UTC, Mineko wrote:

 Yo, I'm starting off a new game engine designed around D, and I 
 just wanted to know if some of you might be kind enough to 
 review some of my base code and tell me if I need to change 
 anything in it.. While it's small. ;_;

 I'm still learning D, I quite like it, the power of C++ in some 
 parts, and the ease of Java in others. (Good job Walter!)

 Anyway here, check it out, only ones you really need to pay 
 attention to are main.d, time.d, and input.d.

 https://github.com/ICGCC/Breaker-3D-Game-Engine

 Thanks for helping out a newbie, and if you want to contribute 
 to it, even better!

 ..That and if I'm using the GPL right. >_____>"


- Well for a start, 600 lines of license headers is a bit too 
much. You can just refer to your license file in a two-line 
header (+copyright).

- PI is defined in std.math

- a class is public by default unless noted otherwise, unlike Java
Nov 20 2013
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 20 November 2013 at 07:48:21 UTC, Mineko wrote:
(...)

 ..That and if I'm using the GPL right. >_____>"


Do you really plan on using 677 lines per file on the license 
header..?
Nov 20 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 20 November 2013 at 07:48:21 UTC, Mineko wrote:

 Yo, I'm starting off a new game engine designed around D, and I 
 just wanted to know if some of you might be kind enough to 
 review some of my base code and tell me if I need to change 
 anything in it.. While it's small. ;_;

 I'm still learning D, I quite like it, the power of C++ in some 
 parts, and the ease of Java in others. (Good job Walter!)

 Anyway here, check it out, only ones you really need to pay 
 attention to are main.d, time.d, and input.d.

 https://github.com/ICGCC/Breaker-3D-Game-Engine

 Thanks for helping out a newbie, and if you want to contribute 
 to it, even better!

 ..That and if I'm using the GPL right. >_____>"


You don't need to include the full GPL license in each file. Look 
here for an example.

https://github.com/pjmlp/queue-d

Don't use the legacy OpenGL functions. Fixed pipeline is dead.

--
Paulo
Nov 20 2013
prev sibling next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Wednesday, 20 November 2013 at 07:48:21 UTC, Mineko wrote:

 Yo, I'm starting off a new game engine designed around D, and I 
 just wanted to know if some of you might be kind enough to 
 review some of my base code and tell me if I need to change 
 anything in it.. While it's small. ;_;

 I'm still learning D, I quite like it, the power of C++ in some 
 parts, and the ease of Java in others. (Good job Walter!)

 Anyway here, check it out, only ones you really need to pay 
 attention to are main.d, time.d, and input.d.

 https://github.com/ICGCC/Breaker-3D-Game-Engine

 Thanks for helping out a newbie, and if you want to contribute 
 to it, even better!

 ..That and if I'm using the GPL right. >_____>"


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
Nov 20 2013
next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
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!
Nov 20 2013
next sibling parent "Paulo Pinto" <pjmp progtools.org> writes:
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
Nov 20 2013
prev sibling parent "Mineko" <uminekorox gmail.com> writes:
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.
Nov 20 2013
prev sibling parent "Mineko" <uminekorox gmail.com> writes:
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.
Nov 20 2013
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 11/20/2013 4:48 PM, Mineko wrote:


 Thanks for helping out a newbie, and if you want to contribute to it,
 even better!


You don't need to list derelict-util as a dependency in your 
package.json. The other Derelict packages already depend on it so it 
will be pulled in anyway.
Nov 20 2013
parent reply "Mineko" <uminekorox gmail.com> writes:
Wow!

You guys are really helpful, I wouldn't have thought about a lot 
of that, I'll pounce on all of this right after breakfast! 
Thanks! :D
Nov 20 2013
parent "Henning Pohl" <henning still-hidden.de> writes:
Feel free to take a look at https://github.com/hpohl/ext/. Maybe 
you can find something useful.
Nov 20 2013
prev sibling parent reply "Geancarlo Rocha" <nope mailinator.com> writes:
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.


On Wednesday, 20 November 2013 at 07:48:21 UTC, Mineko wrote:

 Yo, I'm starting off a new game engine designed around D, and I 
 just wanted to know if some of you might be kind enough to 
 review some of my base code and tell me if I need to change 
 anything in it.. While it's small. ;_;

 I'm still learning D, I quite like it, the power of C++ in some 
 parts, and the ease of Java in others. (Good job Walter!)

 Anyway here, check it out, only ones you really need to pay 
 attention to are main.d, time.d, and input.d.

 https://github.com/ICGCC/Breaker-3D-Game-Engine

 Thanks for helping out a newbie, and if you want to contribute 
 to it, even better!

 ..That and if I'm using the GPL right. >_____>"
Nov 20 2013
parent reply "Mineko" <uminekorox gmail.com> writes:
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?
Nov 20 2013
next sibling parent reply "Paulo Pinto" <pjmp progtools.org> writes:
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
Nov 20 2013
parent reply "Mineko" <uminekorox gmail.com> writes:
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.
Nov 20 2013
parent reply "Franz" <Franz K.it> writes:
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.
Nov 20 2013
parent reply "Mineko" <uminekorox gmail.com> writes:
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.
Nov 20 2013
parent "Paulo Pinto" <pjmp progtools.org> writes:
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
Nov 20 2013
prev sibling parent reply "qznc" <qznc web.de> writes:
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/
Nov 20 2013
parent reply "Mineko" <uminekorox gmail.com> writes:
I did a complete restructure of the engine, so it'd be a bit 
better for later use.

If there's anything I missed or anything I should fix, please 
tell me.
Ignore the opengl stuff though, right now it's more or less a 
placeholder so I can implement the base functions first and 
forthmost.

https://github.com/ICGCC/Breaker-3D-Game-Engine
Nov 22 2013
parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Friday, 22 November 2013 at 16:10:13 UTC, Mineko wrote:

 I did a complete restructure of the engine, so it'd be a bit 
 better for later use.

 If there's anything I missed or anything I should fix, please 
 tell me.
 Ignore the opengl stuff though, right now it's more or less a 
 placeholder so I can implement the base functions first and 
 forthmost.

 https://github.com/ICGCC/Breaker-3D-Game-Engine


Looks much better :). I'm quite busy at the moment, but I'll take 
a closer look at it later..
Nov 23 2013