FreetypeGL on Marmalade

[Andrei Petrovici]

Hi,

My name is Andrei Petrovici.
First of all I want to thank you for your effort in maintaining
freetype-gl.

I am currently using Marmalade for mobile development. They have many
blocks to develop applications but for various reasons i want to use
plain OpenGL in my game engine.
I looked all over for simple "font" libraries (non stl dependencies
etc). I had only 2 final candidates: freetype-gl and fontstash.
Freetype-gl is outstanding because it has one major advantage: vertex-
buffer (utility) is well designed outside the library and can easily
be replaced by our own classes.

Not to mention that it is enough to have texture-font ant texture-
atlas to run demo-font.

I must tell you that I have tested freetype-gl before may 7 release
(Big code cleanup and API documentation added), so please discard
obsolete stuff.
I will test as soon as possible this version but I wanted to tell you
my first humble remarks:

1. Because Marmalade SDK allows me to build on visual studio c/c++
compiler and gcc compiler I found some annoying problems on visual c/c+
+ compiler on assert(...) in c functions.
Please see
http://stackoverflow.com/questions/705502/why-does-microsofts-c-compiler-want-the-variables-at-the-beginning-of-the-funct.
I solved by renaming .c files in .cpp files.
2. Microsoft compiler has problems on void pointer arithmetic (errors
actually) .gcc uses 1 in pointer arithmetic for void* by default. So I
had to explicitly use char* or byte* to resolve this minor problem
(see vector.items, vertex_buffer.pointer).
3. I think that opengl include block (gl.h etc) should be defined in
separate .h file to be modified easily ( I have to use OpenGL ES
version.Please see http://www.khronos.org/registry/gles/)
4. in vector.cpp I found a little bit strange the capacity increase in
vector_insert: 2 * previous capacity ( I think an upper define for
increase factor (2) will be more manageable).
5. it is a good thing that strndup in vertex_buffer_new it has a
backup version because i didn't find this function in my limited
development sdk.
6. Regarding the well designed vertex_buffer class I think that an
USE_GLES(FTGL_GLES) kind of define will be useful because on gles we
dont have:
GL_FOG_COORD_ARRAY, GL_SECONDARY_COLOR_ARRAY, GL_EDGE_FLAG_ARRAY
(glFogCoordPointer, glEdgeFlagPointer,glSecondaryColorPointer)
GL_DOUBLE, GL_INT
7. I thing it will be useful to define index data type. On OpenGL ES
it should be used ushort vs uint for index data.
8. In my version buffer_delete forgot to free self->attributes.

All the above were relative easy to adjust in my "environment" even
that I am a little bit rusty at using c/c++.
May I ask why have you chosen c vs c++?
I tested the result on Android phones (different os versions) and I
have found one strange and big problem in vertex buffer object
implementation.
If data is uploaded with glBufferData on dirty data, it leaks the
buffers on opengl side. So I finally found that calling glBufferData
on construction and uploading glBufferSubData is the perfect android
OpenGL ES way.

Thank you for reading this.
Keep up the good work.

[Nicolas Rougier]

Hi Andrei,

Sorry to have not answer your previous email but I was away from home and experienced some difficulty in connecting.
First of all, thanks for you useful comments, I will try to take them into account since you both analyzed the problem and proposed the fix. Unfortunately, I do not have access to a windows machine and I won't be able to test them thoroughly.

>
> Not to mention that it is enough to have texture-font ant texture-
> atlas to run demo-font.
>

Argg ! In the last demo I refactored code to avoid having same code duplicated all over but maybe I will put it back into demo-font to reduce dependency to a minimum

> I must tell you that I have tested freetype-gl before may 7 release
> (Big code cleanup and API documentation added), so please discard
> obsolete stuff.
> I will test as soon as possible this version but I wanted to tell you
> my first humble remarks:
>
> 1. Because Marmalade SDK allows me to build on visual studio c/c++
> compiler and gcc compiler I found some annoying problems on visual c/c+
> + compiler on assert(...) in c functions.
> Please see
> http://stackoverflow.com/questions/705502/why-does-microsofts-c-compiler-want-the-variables-at-the-beginning-of-the-funct.
> I solved by renaming .c files in .cpp files.

That's unfortunate. I prefer to have assert right after function name because I think it makes things clearer. As to rename .c into .cpp, I'm not a big fan of this solution.

> 2. Microsoft compiler has problems on void pointer arithmetic (errors
> actually) .gcc uses 1 in pointer arithmetic for void* by default. So I
> had to explicitly use char* or byte* to resolve this minor problem
> (see vector.items, vertex_buffer.pointer).

That's a good point. I will try to replace void * by char *.

> 3. I think that opengl include block (gl.h etc) should be defined in
> separate .h file to be modified easily ( I have to use OpenGL ES
> version.Please see http://www.khronos.org/registry/gles/)

You're right. I added an opengl.h header.

> 4. in vector.cpp I found a little bit strange the capacity increase in
> vector_insert: 2 * previous capacity ( I think an upper define for
> increase factor (2) will be more manageable).

I get the 2 factor from the definition of the STL vector class. I agree with your comment but the factor 2 is only present in the insert function and is quite easy to change. I suspect most people that want to adapt freetype-gl to their own code will also use their own vector implementation.

> 5. it is a good thing that strndup in vertex_buffer_new it has a
> backup version because i didn't find this function in my limited
> development sdk.

Thanks for reminded me. I removed it and just put it back...

> 6. Regarding the well designed vertex_buffer class I think that an
> USE_GLES(FTGL_GLES) kind of define will be useful because on gles we
> dont have:
> GL_FOG_COORD_ARRAY, GL_SECONDARY_COLOR_ARRAY, GL_EDGE_FLAG_ARRAY
> (glFogCoordPointer, glEdgeFlagPointer,glSecondaryColorPointer)
> GL_DOUBLE, GL_INT

You're right. Are there any specific OPENGL ES flag that can be used for such purpose ?

> 7. I thing it will be useful to define index data type. On OpenGL ES
> it should be used ushort vs uint for index data.

Yep. Same as above, we need some compile flag to detect OPENGL ES.

> 8. In my version buffer_delete forgot to free self->attributes.
>

Fixed.

> All the above were relative easy to adjust in my "environment" even
> that I am a little bit rusty at using c/c++.
> May I ask why have you chosen c vs c++?

I find it easier to both read and adapt C sources rather than C++. For example, if you look at FTGL, I find it hard to re-use or adapt the source code because of the templates.

> I tested the result on Android phones (different os versions) and I
> have found one strange and big problem in vertex buffer object
> implementation.
> If data is uploaded with glBufferData on dirty data, it leaks the
> buffers on opengl side. So I finally found that calling glBufferData
> on construction and uploading glBufferSubData is the perfect android
> OpenGL ES way.

Weird. I made the change. It make me think that I intend to debug freetype-gl agains memory leaks but I did not find tools to do so under osx. How did you detect such leak ?

>
> Thank you for reading this.
> Keep up the good work.

Thanks for the nice and helpful report (I added your name in the README as contributor).



Nicolas

[Andrei Petrovici]

Hi Nicolas.

Thank you for your kind remarks.

I think FreeType-GL strong points are:
1. Maintained code (I saw the effort to maintain the library).
2. Clean code (even the not commented source code is split in logical/
manageable functions)
3. Light footprint and very light dependencies.
4. Code that can be easily linked to other vertex Buffer/vertex data
Container classes.
5. Code that runs on many OS :).

Many people already have their own utility classes for vertex
management.
This does not mean that I think is a bad idea that such classes are
present in freetype-gl.
They have to be here because is the fastest way to be convinced about
freetype-gl.

I am also a big fan of assert. :) Not to mention that I can't use
exceptions by default in Marmalade SDK.
I think there is no GLES flag. I think a FTGL_GLES flag will be just
fine. I tend to push all defines in something like library_defines.h
because I can globally control things.
If anyone will have specific GLES flag (an automatically flag set for
GLES compilations) it will easily define/undefine FTGL_GLES flag.
(FTGL for FreeType GL :))

FreeType-GL is C in C++ manner (so it's a non debate thing :) ).

I found the leak with my own allocation functions redefines.
But I personally recommend Fluid Studio (Paul Nettle) Memory Manager.
Please see links:

http://www.paulnettle.com (The Code section)
http://www.paulnettle.com/pub/FluidStudios/MemoryManagers/

I managed to use their memory manager with minor adjustments caused by
my SDK restrictions:
1. no exceptions.
2. a way to dump reports before app exit.
3. a way to switch to default ( not logged ) allocations/
deallocations (my SDK has at least one minor memory problem and Fluid
Studios Memory Manager it keeps remainding me that :) ) .

I will try to make a demo video on android phones / iphone to show the
fps performance with dynamic text :).

Thank you Nicolas.

[Robert Webb]

Sorry for coming to this discussion very late, but I am now interested in doing the same thing, using FTGL with OpenGL ES and Marmalade.  Is a working version of this available anywhere?

And a question: there was discussion above about including a #define for OpenGL ES.  I'm wondering why this is necessary.  Why not just stick to OpenGL ES calls throughout?  I don't imagine anything beyond that is needed, and if it is, then it won't work on ES anyway.

Thanks,

Rob.

[Nicolas Rougier]

Hi Rob,

freetype-gl is now hoste on github at: https://github.com/rougier/freetype-gl.

Could open there issue related to your questions ?

Nicolas