Closed rogermc2 closed 7 years ago
I think I've fixed everything the needs fixing. I am currently thinking about whether or not the shaders in this example are necessary for this package to do anything useful. I am fairly sure that they are and therefore should be "part of the main sources" instead of part of the example. However, there is the problem of machine dependence to address? In the meantime, I'll set up a separate 'string_example_branch' to investigate your recommendations.
With regard to printing more than just ANSI characters I really think that this should definitely be catered for but should be the province of another example. Ideas for the complete implementation of a widely useful string rendering system are pretty much outside the domain of my knowledge. So, I must rely on your recommendations for ways of extending this example.
On further thought, as OGL doesn't appear to be as generally useful as I thought it might be, it might be better to move OGL back into the string example
(where it came from originally) and develop a more general version independently?
The more I think of it, the more I am convinced that all the shader processing should be in OGL and invisible to the user.
Text rendering relies on the texture_coords
in the fragment shader being modulated by the text_sampler
uniform provided to the fragment shader. This is where the "blending" comes in. If blending is disabled, no modulation occurs and no character is displayed. So, these particular shaders provide essential minimum processing for character display.
I've made an attempt to transfer the shader processing into OGL in my extensions branch. However, a problem arises that the examples/common file 'Program_Loader' is required which, obviously, is not part of OpenGLAda's library and, so, doesn't seem to be visible to OGL (which presumably is a good thing from the OpenGLAda library point of view.). In view of this and all the above commentary I now think that I was premature in thinking that OGL could be part of the freetype library. Therefore I propose returning it to the example. Agreed? We could, perhaps, then develop a more versatile version of OGL separately.
If this example is important because it mirrors what one would typically do in C, then I agree that the stuff currently in OGL should be moved into the example. FT.OGL should provide a simplified interface with only the necessary things visible to the user.
About machine dependence of the shaders: Is there anything that forbids us to just use the oldest possible shader version? Wouldn't that work on all modern machines?
OK, I'll move it back into the example and also check out how far back I can set the shader version. Deciding what "a simplified interface with only the necessary things visible to the user" is a bit of a challenge. What I currently have is:
procedure Initialize_Font_Data (Font_File : String;
Projection_Matrix : GL.Types.Singles.Matrix4);
procedure Render_Text (Text : String; X, Y, Scale : GL.Types.Single;
Colour : GL.Types.Colors.Basic_Color;
Projection_Matrix : GL.Types.Singles.Matrix4);
Would this make sense as a simple user interface?
I think a simple user interface would render the text onto a texture so that the user can then place it as desired. This would remove most of the Render_Text
variables. Additionally, it would have the Font_Renderer
I described above. It would also provide a way to query how long a String would be if rendered so that the user can decide if and where to split it into multiple lines.
What you describe seems admirable. However, its a bit beyond my knowledge of graphics in general so I'm not sure how I should proceed but I'll study your comments and try to come to a better understanding of the situation. In the meantime I'll first make the changes to string_example to make it a normal stand-alone example that uses our existing freetype library without any extensions.
I moved OGL into the string example directory, but compilation fails as I can't seem to access
Glyph_Slot.Data
as
Width := GL.Types.Int (Glyph_Slot.Data.Bitmap.Width);
and Rows
fails with invalid prefix in selected component "Glyph_Slot"
invalid prefix in selected component "Glyph_Slot"
.
Getter functions would be nice as they would provide a more consistent and simpler user interface with the Bitmap_Left
and 'Bitmap_Top` function calls.
Shader versions that work on my computer: GLSL version 400 and 410 work but not versions greater than 410. GLSL version 330 works Version 3** other than 330:
ERROR: 0:1: '' : version '300' is not supported
ERROR: 0:2: '' : #version required and missing.
ERROR: 0:3: '0' : syntax error: integers in layouts require GLSL 140 or later
Versions 2** don't work Other details for my computer:
OpenGL version supported: 3. 3
Renderer: Intel HD Graphics 3000 OpenGL Engine
Primary_Shading_Language_Version: 3.30
Instead of
Glyph_Slot.Data.Bitmap.Width
do
FT.Glyphs.Bitmap (Glyph_Slot).Width
You cannot use prefix notation for accessing the Bitmap
function because Glyph_Slot_Reference
is not a tagged type.
OK, thanks.
String rendering code moved from freetype library back into text_rendering. Ready for review again.
OK. I'll sought it out.
I don't know how those other files got in there and I thought I'd changed the file name!!!!
I did change the file name! I just forgot to push the changes.
Sorry about that, fixed now. My brain must have gone into overload mode!
With regard to the unnecessary files, could this have something to do with my changes to .gitignore
and the new .gitignore
in examples/freetype_gl
? I'll try and fix it.
I've removed the unnecessary files and updated .gitignore to ignore examples/superbible/simple_texture/simple_texturing
.
Can you rename FT.OGL
so that there will be no name conflict when we add the real FT.OGL
?
I had renamed them but the originals somehow remained. I've deleted them now.
Do you have other unmerged examples using the FreeType stuff? otherwise, I would like to re-organize the project structure a bit.
None.
Go ahead and reorganize.
Can you make the user interface as simple as possible?
My original concept was that the user should do everything via Face_Ptr
, now Face_Reference
I suppose. But I don't know that this is possible or advisable now.
I am using an earlier version on another project. Should I wait until your reorganization is complete before switching to the master version?
I made the freetype stuff independent from OpenGLAda and published it separately at https://github.com/flyx/FreeTypeAda . It is still part of this repository, I use git-subrepo to keep it in sync (much nicer than the standard git submodule
). I also added style checks to the compiler to enforce proper coding style. And lastly, I made the build fail on warnings. This is to force us or any other contributor to commit sane code.
Now I'll see what I can do for a nicer FreeType interface.
Sounds good. The worthwhile adding of style checks has shown that some changes are needed in some examples. Should I open a new branch to fix these? Presumably I shouldn't do it in master! There are some other problems but I'll leave them for a couple of days in case they sort themselves out during this revision period.
Yes, you can fix them on a new branch. You can branch from master; I won't do more reorganising work to the structure for now. A good thing to do would be to make all examples use the same compiler settings as the main project. I did this with the FreeType examples if you want to have a look.
Btw, I removed your -L/usr/local/lib
from the freetype project files. If you need it, do export LIBRARY_PATH=/usr/local/lib
before compiling.
I am getting this error in all examples:
An exception occurred in Initialize.
An exception occurred in Hello_Character.
raised PROGRAM_ERROR : glfw-windows.adb:172 accessibility check failed
Sorry, my bad. Fixed it.
Thanks, working again.
This provides the final step in this journey of providing an Ada FreeType interface for rendering strings.