Few typos

[dumblob]

In void DaoxRenderer_DrawTask( DaoxRenderer *self, DaoxDrawTask *drawtask ), the variable j is only declared, but not used.

The declaration of void DaoxPathStyle_Convert( DaoxPathStyle *self, int buffer[DAOX_MAX_DASH+4] ), should be changed to void DaoxPathStyle_Convert( DaoxPathStyle *self, int buffer[DAOX_MAX_DASH+5] ) as everywhere else 5 is used for buffer size increase (in the function body, but also in the caller functions).

In source/dao_animation.c:53, the variables scale, rotate, and translate are unused.

In DaoxParticle* DaoxEmitter_AddParticle(...), there is

...
if( lifeSpan < 0.5*self->lifeSpan ) lifeSpan = 0.5*self->lifeSpan;
if( lifeSpan < 2.0*self->lifeSpan ) lifeSpan = 2.0*self->lifeSpan;
...

but it's semantically the same as the following (saving few instructions ;)):

...
if( lifeSpan < 2.0*self->lifeSpan ) lifeSpan = 2.0*self->lifeSpan;
...

or there is a typo and the line if( lifeSpan < 2.0*self->lifeSpan ) lifeSpan = 2.0*self->lifeSpan; should become if( lifeSpan > 2.0*self->lifeSpan ) lifeSpan = 2.0*self->lifeSpan;.

[daokoder]

The declaration of void DaoxPathStyle_Convert( DaoxPathStyle *self, int buffer[DAOX_MAX_DASH+4] ), should be changed to void DaoxPathStyle_Convert( DaoxPathStyle *self, int buffer[DAOX_MAX_DASH+5] ) as everywhere else 5 is used for buffer size increase (in the function body, but also in the caller functions).

Right.

or there is a typo and the line if( lifeSpan < 2.0_self->lifeSpan ) lifeSpan = 2.0_self->lifeSpan; should become if( lifeSpan > 2.0_self->lifeSpan ) lifeSpan = 2.0_self->lifeSpan;.

Indeed, this is the case.

BTW, have you tried it on linux? I couldn't, because I only have access to linux installed in VirtualBox, which does not support OpenGL 3.1, so I could only test if it can compile and start on linux.

[dumblob]

or there is a typo and the line if( lifeSpan < 2.0self->lifeSpan ) lifeSpan = 2.0self->lifeSpan; should become if( lifeSpan > 2.0self->lifeSpan ) lifeSpan = 2.0self->lifeSpan;.

Indeed, this is the case.

Or rather

...
if( lifeSpan < 0.5*self->lifeSpan )
  lifeSpan = 0.5*self->lifeSpan;
else if( lifeSpan > 2.0*self->lifeSpan )
  lifeSpan = 2.0*self->lifeSpan;
...

BTW, have you tried it on linux?

Not yet, but I'm going to do it ASAP.

[daokoder]

Or rather

...
if( lifeSpan < 0.5*self->lifeSpan )
  lifeSpan = 0.5*self->lifeSpan;
else if( lifeSpan > 2.0*self->lifeSpan )
  lifeSpan = 2.0*self->lifeSpan;
...

Sure, but it hardly has any impact on the real performance, you cannot gain measurable performance improvements by optimizing something that take less than 1% of time. Please keep in mind that when I wrote code this way, I wrote it for readability and I am certain that it does no harm to performance. Also consider that, if I had wrote the code this way, the typo I made previously would be probably less obvious.

[dumblob]

I can't compile it as the const declaration violates C standard when used for declaration of static objects.

source/dao_mesh.c:624:2: error: initializer element is not constant
  {-XX, 0.0,  YY},
  ^

instead macros should be used:

#define XX 0.525731112119133606f
#define YY 0.850650808352039932f

[daokoder]

Right. I had made this change for compiling only linux, but forgot to commit it, now it's committed along with fixings for the typos you mentioned here.

[dumblob]

So, I've tried hard to run the module, but after many hours of reading different sources, trying to patch source code etc. I realized, that the open-source driver i965 for my mobile Intel graphic card GM45 can't compile the shaders:

...
(0x1d65a90) Cached paths: 6; Cached meshes: 1
(0x1d65a90) Cached paths: 7; Cached meshes: 2
(0x1d65a90) Cached paths: 8; Cached meshes: 3
(0x1d65a90) Cached paths: 9; Cached meshes: 4
(0x1d65a90) Cached paths: 10; Cached meshes: 5
Failed to compile shader!
With error message: 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
Failed to compile shader!
With error message: 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
Failed to compile shader!
With error message: 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
Failed to compile shader!
With error message: 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
offscreen = 1
DaoxRenderer_UpdateBuffer: 24 12, 0xffffffffd900f000 0xffffffffe1522000
Segmentation fault (core dumped)

I've also tried to use the mesa capability to fool applications by changing environment variables (http://www.mesa3d.org/envvars.html) - e.g. MESA_GL_VERSION_OVERRIDE=3.2 and MESA_GLSL_VERSION_OVERRIDE=150, but it didn't solve the problem. An overview of the supported shading language subset can be found http://www.mesa3d.org/shading.html .

So for now, I'm unfortunately out of question for testing of this module :( . Or do you see any other option?

[daokoder]

It seems that your card is too old and does not support OpenGL 3.1: http://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units. Nothing can be done, unless you try it on another computer with newer graphics card.

[dumblob]

Ok, I've tried SW rendering and got the following:

0$ (export LIBGL_ALWAYS_SOFTWARE=1 MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150; dao ~/del/dao/DaoGraphics/examples/particles.dao)
(0xcfd010) Cached paths: 6; Cached meshes: 1
(0xcfd010) Cached paths: 7; Cached meshes: 2
(0xcfd010) Cached paths: 8; Cached meshes: 3
(0xcfd010) Cached paths: 9; Cached meshes: 4
(0xcfd010) Cached paths: 10; Cached meshes: 5
Failed to compile shader!
With error message: 0:480(17): error: `return' with wrong type int, in function `ParticleFactor' returning float
offscreen = 1
DaoxRenderer_UpdateBuffer: 60 30, 0xffffffffb5852040 0x136cd80
139$ 

Also I'm not sure if GLFW writes always an error message to stderr in case something bad happened, but the message Failed to create window in dao_window.c seems quite general - shouldn't we try to make it more descriptive e.g. by using GLenum glGetError( void) and const GLubyte * gluErrorString(GLenum error)?

[daokoder]

Are you sure Mesa supports GLSL 1.5? My impression is that it supports only up to 1.3.

shouldn't we try to make it more descriptive e.g. by using GLenum glGetError( void) and const GLubyte * gluErrorString(GLenum error)?

The error message from GLFW should be handled by a callback. It's done, but not committed yet.

[dumblob]

Are you sure Mesa supports GLSL 1.5? My impression is that it supports only up to 1.3.

According to http://www.mesa3d.org/shading.html#support , GLSL 1.5 should be supported.

[daokoder]

Thanks to your information regarding Mesa, now I am able to run it in my VirtualBox Linux with mesa with minor changes:). However, I don't see any drawing for examples that require blending (particles and vector graphics examples), I don't know if it is not working or just extremely slow. Other examples seems to work with a few artifacts. I believes these are the issues of Mesa software rendering.

Changes are committed, you should be able to run it now.

[dumblob]

Thanks to your information regarding Mesa, now I am able to run it in my VirtualBox Linux with mesa with minor changes:).

Great!

Excluding vector graphics examples, SDL examples, particles.dao, the only examples which run correctly on my setup are terrain_hex.dao, hextraction_pod.dao and procedural_terrain.dao. All the rest just prints something like the following and quits immediately instead of showing a window and rendering something.

astroboy_walk.dao (note the (nil))

Scene: 5 nodes; 2 lights; (nil)
(0x238a890) Cached paths: 6; Cached meshes: 1
(0x238a890) Cached paths: 7; Cached meshes: 2
(0x238a890) Cached paths: 8; Cached meshes: 3
(0x238a890) Cached paths: 9; Cached meshes: 4
(0x238a890) Cached paths: 10; Cached meshes: 5
offscreen = 1
DaoxRenderer_UpdateBuffer: 19954 9762, (nil) 0x11481c0
(0x238a890) Cached paths: 12; Cached meshes: 6
(0x238a890) Cached paths: 12; Cached meshes: 7

rama_attack.dao (note the (nil))

(0x25839e0) Cached paths: 6; Cached meshes: 1
(0x25839e0) Cached paths: 7; Cached meshes: 2
(0x25839e0) Cached paths: 8; Cached meshes: 3
(0x25839e0) Cached paths: 9; Cached meshes: 4
(0x25839e0) Cached paths: 10; Cached meshes: 5
offscreen = 1
DaoxRenderer_UpdateBuffer: 120 40, 0x2dbaa80 0x2c20200
DaoxRenderer_UpdateBuffer: 10278 3426, (nil) 0x2f0ab00

terrain.dao (note there is no (nil))

vertices: 11454
triangles: 22666
(0x2eeb330) Cached paths: 6; Cached meshes: 1
(0x2eeb330) Cached paths: 7; Cached meshes: 2
(0x2eeb330) Cached paths: 8; Cached meshes: 3
(0x2eeb330) Cached paths: 9; Cached meshes: 4
(0x2eeb330) Cached paths: 10; Cached meshes: 5
offscreen = 1
DaoxRenderer_UpdateBuffer: 11454 22666, 0x25820040 0x373c6c0

Return code for all of these failing examples is always 139. The weird thing is, that there are no other error messages. Also, running the failing examples in valgrind makes the (nil)-showing examples render the final image (but very slowly).

[daokoder]

The nils are normal. Please try to reduce the window sizes (namely change Graphics::Window() parameters) and see what happens.

[dumblob]

Please try to reduce the window sizes (namely change Graphics::Window() parameters) and see what happens.

I've tried, but that didn't help - the stdout/stderr output is exactly the same and the behavior as well (i.e. in both cases astroboy_walk.dao and rama_attack.dao only window shows up for a fraction of second and immediately disappears and the whole program exits with 139).

[daokoder]

Then please compile it in debug mode, and run it in gdb and see what's the stack trace.