Ftgl shader example

[rogermc2]

This is my first effort at using freetype. It only displays one character; my simplest approach to getting started with a freetype implementation. I look forward to suggestions for improvement.

[flyx]

I pushed a fix, please check if your errors go away.

I still need to migrate Face_Ptr and Glyph_Ptr to memory-managed types. My first attempt showed that this requires a lot of restructuring. Can you stop pushing commits until I'm done? Otherwise we'll be in merge hell.

[rogermc2]

Great! ftgl_shader_example now works on both my computers. I'll try to remember not to push more commits on this branch. No way to lock out commits? I get myself into enough merge hell as it is! There's plenty for me to do with bringing the other branches up to date and developing the geometric algebra branch.

[flyx]

Well the situation right now is that we need to get the FT packages in a mergeable state and that's a blocker for other things. So everything other we do will get merge problems as long as the FT API is changed, no matter how good we handle git. The only good option is to concentrate on this branch and merge it fast. I'll try to get Face_Ptr and Glyph_Ptr done today.

[flyx]

I had to move around a lot of types to make Face_Reference happen. FT.Glpyhs is now FT.Faces.Glyphs because it needs a view of the Face_Reference internals. I moved a lot of types into the private part of FT so that they are visible to both FT.Faces and FT.API but not to the user. Since I had to move them around anyway, I made some records public and simplified getter functions.

However, I think I screwed up a but in FT.Utilities.Print_Character_Metadata. I became very confused about some of the types and when reworking the code, I think I fetched the wrong public record, but I could not find the correct one. I disabled calling the function Print_Character_Metadata in Texture_Manager so that it does not break and hope you can tell me how to fix this (or do it yourself).

Meanwhile, I saw that you declared Character_Record which is not a type used by the FreeType API. That also confused me a bit; why is it part of the FT.Faces package? It seems like a collection of some values, but I could not figure out its purpose. Are there subprogram working on it in other packages? I lost the overview. Anyway, as this is not a FreeType thing, it definitely has no place in FT.Faces and should be somewhere else.

[flyx]

I'm done with the memory management stuff. Do I see it correctly that the Glyph stuff is currently not used?

[rogermc2]

Character records are used for storing characters in the string example (which is really a bit more than an example as it provides the intended basis for general use of the system). It originates from the https://learnopengl.com/#!In-Practice/Text-Rendering example. The history was that I tried to develop the string example directly from this 'Text-Rendering' tutorial example but when I ran into serious difficulty I initiated this single character example as a simpler stepping stone towards the full string example. As it turned out, when I first got this single character example working, I incorporated it back into the string example but still had difficulty so I initiated a second stepping stone which is the 'single_char_storage' branch. Finally, after getting that working I was able to build a working string example. Essentialy, in the string example, a description of each ascii character is contained in a 'Character_Record'; the fully set of character descriptions being contained in a 'Character_Data_Vector' which is not used at all in 'ftgl_shader_example' but is essential for the 'String Example'. My main reason for developing this system is to provide a system that easily renders strings of characters. To do this, I need to extend the FreeType API, which as far as I can understand only deals with single characters which is appropriate as it is fundamentally a font package that provides characters but, as far as I understand, no process for manipulating them. Hence the need for systems such as FTGL and FreeType_GL. This branch, 'ftgl_shader_example', is essentally a precursor to the 'string_example' branch which, due to its origination from the 'string_example' contains a few data structures not currently utilised. I hope this makes sense.

[rogermc2]

I'm surprised if " Glyph stuff is currently not used" as it is what font characters actually are. But its too late at night for me to look into now. I'll try and provide an answer tomorrow.

[flyx]

Okay. A good way to organise that would be to move Character_Record and associated subprograms into a package FT.GL or something so that it is clear that this is glue code for using FreeType with OpenGL. Similarity to FTGL is intentional ;).

[rogermc2]

Yes, I was about to propose this. I have a "new" package in string example which is probably where it and its associated programs should be. I have been struggling for a decent name for this package. 'FT.GL' sounds better than what I've currently got. If you like you can delete 'Character_Record' and 'Character_Data_Vector' and I'll fix it up in 'string_example' tomorrow so as not to interfere with your work. This will mean I won't need to push 'ftgl_shader_example' and cause merging problems. Now, I really am signing off for tonight.

[flyx]

Okay, that was hopefully the last hard API change I will push. I was able to move FT.Faces.Glyphs back to FT.Glyphs by introducing Glyph_Slot_Reference in FT. This make a lot of things cleaner and removes all references to Face_Reference from FT.Glyphs. I also fixed FT.Utilities, it does now work again with the example.

With Glyph stuff is currently not used, I meant that currently, the code does not use Glyph_Ptr (or the new Glyph_Reference). It only uses the Glyph_Slot_Ptr (which is now publicly available as Glyph_Slot_Reference). I asked because I implemented reference counting for Glyph_Reference, but this is currently untested because the code never create a new Glyph_Reference (it only uses the Glyph_Slot_Reference to draw glyphs).

[flyx]

Please have a look and tell me what you think of the new interface design. I updated the example to work with the new API (at least on my machine), so you can look at how it can be used.

[rogermc2]

The latest version works on both my computers. The character_record stuff makes thing much cleaner in its new location which I've named FT.OGL; FT.GL provided some confusion with GL. I'll have a look at the new design which I imagine will be excellent and wil inspect the glyph stuff more closely.

[rogermc2]

I've checked out the new design by updating the 'single_char_storage' branch to the latest API. No problems. I've decided to move the fonts folder into 'freetype_gl' folder. I haven't done it yet on the 'ftgl_shader_example' branch so as not to get into merging difficulties with your development.

[rogermc2]

I've integrated the new design into the 'string_example' branch. I found the need for two additional functions, 'FT.Glyphs.Bitmap_Width' and 'FT.Glyphs.Bitmap_Rows'. I've implemented them in the 'string_example' branch which now works fine. I haven't implemented them in 'ftgl_shader_example' yet per your request not to commit. Is it OK to implement them now?

[rogermc2]

With regard to exception handlers, I was thinking that many can be removed prior to merging as, from my perspective, they performed a valuable service for me during development but Ince the design has stabilised and working well there is really no need for them. So I am suggesting that, just prior to merging, I go through the code and remove many of them.

[flyx]

Yes, removing those catch-all-and-raise-new-exception handlers would be a good thing. Exceptions that are raised based on the error code should obviously stay.

Another good thing to do would be to go over all subprograms that call API functions and ensure that they do the appropriate null check before calling the API function because the FreeType implementation never checks for null, but instead just dereferences the pointers it gets.

After those things are done, I think this PR is ripe for merging.

[flyx]

Why do you need Bitmap_Width and Bitmap_Rows? Bitmap_Record is public, so FT.Glyphs.Bitmap (My_Glyph_Slot).Width would work, wouldn't it?

[flyx]

I renamed FT.Faces.Slot to FT.Faces.Glyph_Slot, I think that's more clear, and I removed unnecessary exception handlers from the FT packages (there weren't many; those in the example can stay). I reviewed memory management, found and fixed a leak.

We now have this in a state that could be merged unless you have further propositions. There is of course the option to clean up FT from any GL references and make it a standalone library so that it can be used for other purposes. Basically, that would mean we remove all GL.Types types and replace them with self-defined types or those from Interfaces.C. We'd then have a project freetype which does not depend on opengl, and separately, freetype-opengl, which adds glue to OpenGL (such as loading a texture from a bitmap). But I think this is a transformation we can tackle later.

[flyx]

Oh well, I got rid of GL.Types everywhere in FT. The only remaining reference to GL is the Image_Source. We will get rid of that later, when we merge FT.OGL. We can then put a transformation function there.

I fixed some small errors in record representation. Also, I renamed Errors to FT.Errors (it was originally there, wasn't it?). We cannot have a global package Errors, that is likely to name-clash with a package from a user's code.

[rogermc2]

I'm glad that GL references are going. This is a bother that I have been having with Geometric_Algebra trying to keep references to GL to a minimum so that the non-graphics code is straight Ada. Your getting rid of GL here gives me more confidence snd encouragement to do the same with GA. While Bitmap_Record containsBitmap_Width and Bitmap_Row it does not contain Bitmap_Top and Bitmap_Left which are in Bitmap's parent and which I use function calls for. So this is why I thought functions Width and Height were missing. I'll try to use Bitmap_Record for Width and Height. My current quick attempt is failing, but that's probably just me. It should work.

[rogermc2]

Regarding GL. In my Geometric Algebra development, should I minimise my use of GL and, where I do need to use it, type cast results to core Ada? This seems to me a good way to go.

[rogermc2]

I'm using Bitmap_Record for Width and Height OK so no need for Bitmap_Width and Bitmap_Rows getters. I've added Glyph_Slot checks to FT.Glyphs. Hopefully the right thing to do? I can't think of anything else that needs to be done.

[flyx]

Checking for Glyph_Slot_Reference.Data not being null is not necessary, it is declared as not null Glyph_Slot_Ptr. We only need the check this in FT.Faces.Glyph_Slot, afterwards, it cannot be null. Please revert that commit.

[rogermc2]

OK. Reverted.

[flyx]

You don't seem to have pushed that revert commit

[rogermc2]

Should be OK now. I don't understand what happened. git status showed nothing to commit so I thought it happened automatically. However, following your message, I pushed and the revert seems to have gone through.

[flyx]

This was a lot of work, but I think it was worth it. Thanks! I'll look forward to your other PRs.

[rogermc2]

Likewise; your invaluable assistance is greatly appreciated.