www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Glamour =?UTF-8?B?4oCTIEFuIG9wZW5nbCB3cmFwcGVyIGZvciBE?=

reply David <d dav1d.de> writes:
https://github.com/Dav1dde/glamour

Glamour wraps opengl is not an opengl binding. Currently it supports:

* Sampler objects
* Textures (1D, 2D, 2D_ARRAY, 3D)
* Shaders
* Buffers (Elementbuffers and "normal" VBOs)

For the shaders a custom format is used:

-----
vertex:
     // here goes the vertex shader

geometry:
    // here goes the geometry shader (this section can be omitted)

fragment:
    // here goes the fragment shader
-----

Readme/Installation: 
https://github.com/Dav1dde/glamour/blob/master/README.md
Documentation: http://dav1dde.github.com/glamour/


TODO:
  * support more opengl "backends", like statically linked opengl (in 
glamour.gl)
  * polish up the index.d and write a proper installation guide

Pull requests are appreciated.
Jul 26 2012
next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Thursday, 26 July 2012 at 13:47:42 UTC, David wrote:

 https://github.com/Dav1dde/glamour

 Glamour wraps opengl is not an opengl binding. Currently it 
 supports:

 * Sampler objects
 * Textures (1D, 2D, 2D_ARRAY, 3D)
 * Shaders
 * Buffers (Elementbuffers and "normal" VBOs)


Nice one!
Jul 26 2012
prev sibling next sibling parent reply "OlaOst" <olaa81 gmail.com> writes:
On Thursday, 26 July 2012 at 13:47:42 UTC, David wrote:

 https://github.com/Dav1dde/glamour

 Glamour wraps opengl is not an opengl binding. Currently it 
 supports:

 * Sampler objects
 * Textures (1D, 2D, 2D_ARRAY, 3D)
 * Shaders
 * Buffers (Elementbuffers and "normal" VBOs)

 For the shaders a custom format is used:

 -----
 vertex:
     // here goes the vertex shader

 geometry:
    // here goes the geometry shader (this section can be 
 omitted)

 fragment:
    // here goes the fragment shader
 -----

 Readme/Installation: 
 https://github.com/Dav1dde/glamour/blob/master/README.md
 Documentation: http://dav1dde.github.com/glamour/


 TODO:
  * support more opengl "backends", like statically linked 
 opengl (in glamour.gl)
  * polish up the index.d and write a proper installation guide

 Pull requests are appreciated.


Nice work! I converted my shader sandbox program to use glamour 
in just a couple of hours :)

I hit a snag with DLL issues using Devil, but added code for 
loading textures with SDLImage. It's in a pull request now.
Jul 26 2012
parent David <d dav1d.de> writes:
 Nice work! I converted my shader sandbox program to use glamour in just
 a couple of hours :)

 I hit a snag with DLL issues using Devil, but added code for loading
 textures with SDLImage. It's in a pull request now.


Thanks!

And also thanks for the already merged pull-request :).
Jul 26 2012
prev sibling next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
Nice work. I did a quick review of your code, and have some 
suggestions for possible improvement. Apologies for not creating 
a pull request, but I don't have a Git client installed.

Check for errors after every GL call that can generate an error. 
Because GL functions fail silently, debugging why your program 
misbehaves after a failed GL call is almost as annoying as 
finding the cause of heap corruption. Also make sure that every 
GL call is covered, or you may get your errors at the wrong 
functions. The error code will not reset once it is set, until 
glGetError is called. These checks should be disabled in a 
release build, because they're quite costly.

All resources are released using a release method, not the 
destructor. This is good. But to ease debugging, set the handle 
to zero in release(), and check for a zero handle in the 
destructor. Log a warning or something like that if the check 
fails.

Some functions have overloads for both GLuint's and wrapper 
instances. Unless you really need the GLuint versions, it's 
probably better to remove these. Users should either use the 
wrappers for everything or not at all, anything in between will 
cause bloat, ugliness, and errors.

Shader.shaders: perhaps rename to shaderSources?

The ElementBuffer and Buffer constructors accepting a pointer 
will not compile, the pointer version of set_data requires a size 
argument.

On Thursday, 26 July 2012 at 13:47:42 UTC, David wrote:

 https://github.com/Dav1dde/glamour

 Glamour wraps opengl is not an opengl binding. Currently it 
 supports:

 * Sampler objects
 * Textures (1D, 2D, 2D_ARRAY, 3D)
 * Shaders
 * Buffers (Elementbuffers and "normal" VBOs)

 For the shaders a custom format is used:

 -----
 vertex:
     // here goes the vertex shader

 geometry:
    // here goes the geometry shader (this section can be 
 omitted)

 fragment:
    // here goes the fragment shader
 -----

 Readme/Installation: 
 https://github.com/Dav1dde/glamour/blob/master/README.md
 Documentation: http://dav1dde.github.com/glamour/


 TODO:
  * support more opengl "backends", like statically linked 
 opengl (in glamour.gl)
  * polish up the index.d and write a proper installation guide

 Pull requests are appreciated.
Jul 27 2012
parent reply David <d dav1d.de> writes:
  Check for errors after every GL call that can generate an error. Because
 GL functions fail silently, debugging why your program misbehaves after
 a failed GL call is almost as annoying as finding the cause of heap
 corruption. Also make sure that every GL call is covered, or you may get
 your errors at the wrong functions. The error code will not reset once
 it is set, until glGetError is called. These checks should be disabled
 in a release build, because they're quite costly.


I was about to implement it, but I thought it isn't necassary, but maybe 
I was just wrong. I'll think about it (I will definitly add a template 
to glamour.utils which calls the OpenGL method and adds a check)


 All resources are released using a release method, not the destructor.
 This is good. But to ease debugging, set the handle to zero in
 release(), and check for a zero handle in the destructor. Log a warning
 or something like that if the check fails.


Good idea.


 Some functions have overloads for both GLuint's and wrapper instances.
 Unless you really need the GLuint versions, it's probably better to
 remove these. Users should either use the wrappers for everything or not
 at all, anything in between will cause bloat, ugliness, and errors.


Really, where?
If you mean the `unit` param for Samplers/Textures, that is needed, 
sometimes you just wanna bind the Sampler/Texture to a specific unit.


 Shader.shaders: perhaps rename to shaderSources?


Good idea.


 The ElementBuffer and Buffer constructors accepting a pointer will not
 compile, the pointer version of set_data requires a size argument.


Right.


Thanks for your input.
Jul 27 2012
next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Friday, 27 July 2012 at 13:29:55 UTC, David wrote:

 Some functions have overloads for both GLuint's and wrapper 
 instances.
 Unless you really need the GLuint versions, it's probably 
 better to
 remove these. Users should either use the wrappers for 
 everything or not
 at all, anything in between will cause bloat, ugliness, and 
 errors.


 Really, where?
 If you mean the `unit` param for Samplers/Textures, that is 
 needed, sometimes you just wanna bind the Sampler/Texture to a 
 specific unit.


Those are the ones I was talking about. But yeah, I agree that 
can be useful.
Jul 27 2012
prev sibling parent David <d dav1d.de> writes:
Am 27.07.2012 15:29, schrieb David:

  Check for errors after every GL call that can generate an error. Because
 GL functions fail silently, debugging why your program misbehaves after
 a failed GL call is almost as annoying as finding the cause of heap
 corruption. Also make sure that every GL call is covered, or you may get
 your errors at the wrong functions. The error code will not reset once
 it is set, until glGetError is called. These checks should be disabled
 in a release build, because they're quite costly.


 I was about to implement it, but I thought it isn't necassary, but maybe
 I was just wrong. I'll think about it (I will definitly add a template
 to glamour.utils which calls the OpenGL method and adds a check)


Done. Added the template function and every call is checked (if compiled 
with -debug).


 All resources are released using a release method, not the destructor.
 This is good. But to ease debugging, set the handle to zero in
 release(), and check for a zero handle in the destructor. Log a warning
 or something like that if the check fails.


 Good idea.


Done. (If compiled with -debug)


 Some functions have overloads for both GLuint's and wrapper instances.
 Unless you really need the GLuint versions, it's probably better to
 remove these. Users should either use the wrappers for everything or not
 at all, anything in between will cause bloat, ugliness, and errors.


 Really, where?
 If you mean the `unit` param for Samplers/Textures, that is needed,
 sometimes you just wanna bind the Sampler/Texture to a specific unit.


This stays as it is.


 Shader.shaders: perhaps rename to shaderSources?


 Good idea.


Renamed.


 The ElementBuffer and Buffer constructors accepting a pointer will not
 compile, the pointer version of set_data requires a size argument.


 Right.


Fixed.
Jul 27 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/12 9:47 AM, David wrote:

 https://github.com/Dav1dde/glamour


http://www.reddit.com/r/programming/comments/x9htl/glamour_an_opengl_wrapper_for_d/


Andrei
Jul 27 2012
parent David <d dav1d.de> writes:
Am 27.07.2012 21:45, schrieb Andrei Alexandrescu:

 On 7/26/12 9:47 AM, David wrote:

 https://github.com/Dav1dde/glamour


 http://www.reddit.com/r/programming/comments/x9htl/glamour_an_opengl_wrapper_for_d/



 Andrei


Cool, thanks.
Jul 27 2012
prev sibling parent reply "Jonas Drewsen" <jdrewsen nospam.com> writes:
On Thursday, 26 July 2012 at 13:47:42 UTC, David wrote:

 https://github.com/Dav1dde/glamour


Just did a wrapper myself for a project I'm working on. But I 
would be happy to join forces.

I have a couple of nitpickings though:

1, Why is the member method naming not using the standard camel 
case formatting as e.g. phobos does but uses underscore instead.

2, The gl3n library which glamour uses is pretty nice. It does 
use underscores as well but not consistently e.g. 
Quaternion.rotatey(). Additionally the type aliases (e.g. alias 
mat4) are lowercased which is not the standard and is also not 
how it is done in glamour (e.g  alias Texture3D).

How would you feel about changing the naming to the standard D 
conventions? I'll help you out if you think this ok.

/Jonas
Jul 28 2012
parent reply David <d dav1d.de> writes:
 1, Why is the member method naming not using the standard camel case
 formatting as e.g. phobos does but uses underscore instead.


This is my personal coding-style, heavily influenced by Pythons PEP-8. I 
am using it, because I personally don't like the camelCase, because I 
think it makes e.g. distinguishing members from types harder or reading 
the names and I also don't like the look of it.


 2, The gl3n library which glamour uses is pretty nice. It does use
 underscores as well but not consistently e.g. Quaternion.rotatey().
 Additionally the type aliases (e.g. alias mat4) are lowercased which is
 not the standard and is also not how it is done in glamour (e.g  alias
 Texture3D).


`Quaternion.rotatey`, `Matrix.rotatey` – to be honest, I don't know why 
I named them like that (same with the static counterparts `y_rotation`). 
Maybe I should change it, but I don't think that's really bad or breaks 
the general coding style.

The aliases are lowercased to match `glsl`.


 How would you feel about changing the naming to the standard D
 conventions? I'll help you out if you think this ok.


Not a fan of that, this would break existing code and has no real benefits.
Jul 28 2012
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 July 2012 at 21:21:58 UTC, David wrote:

 This is my personal coding-style, heavily influenced by Pythons 
 PEP-8. I am using it, because I personally don't like the 
 camelCase, because I think it makes e.g. distinguishing members 
 from types harder or reading the names and I also don't like 
 the look of it.


You are throwing consistency out of the window because of your 
own personal preference. You shouldn't be using the same style 
regardless of language and project.


 How would you feel about changing the naming to the standard D
 conventions? I'll help you out if you think this ok.


 Not a fan of that, this would break existing code and has no 
 real benefits.


It's in your best interest to use the D style [1] if you want 
people to use your code.

[1] http://dlang.org/dstyle.html
Jul 28 2012
prev sibling parent reply "Jonas Drewsen" <jdrewsen nospam.com> writes:
On Saturday, 28 July 2012 at 21:21:58 UTC, David wrote:

 1, Why is the member method naming not using the standard 
 camel case
 formatting as e.g. phobos does but uses underscore instead.


 This is my personal coding-style, heavily influenced by Pythons 
 PEP-8. I am using it, because I personally don't like the 
 camelCase, because I think it makes e.g. distinguishing members 
 from types harder or reading the names and I also don't like 
 the look of it.


Fair enough.

I really do prefer to have a consistent style thoughout code 
bases I work with because it makes it much easier to reason 
about. Since phobos is the standard library that kind of dictates 
the styling for me :)

I've managed to find another project that does the same as 
Glamour and with the standard D style. I think I'll go with that 
one for now:

https://github.com/p0nce/gfm/tree/master/opengl

/Jonas
Jul 29 2012
parent David <d dav1d.de> writes:
 I've managed to find another project that does the same as Glamour and
 with the standard D style. I think I'll go with that one for now:

 https://github.com/p0nce/gfm/tree/master/opengl


Do whatever you wanna do ;)
Jul 29 2012