Why is nobody discussing FTGL, have I been missing something?
FTGL is a free cross-platform Open Source C++ library that uses Freetype2 to simplify rendering fonts in OpenGL applications. FTGL supports bitmaps, pixmaps, texture maps, outlines, polygon mesh, and extruded polygon rendering modes.
[QUOTE=Alfonse Reinheart;1242857]
You’re used to the Windows world, where if “the system” doesn’t do something, then it may as well not exist. That’s not how things happen outside of the Windows world. In the not-Windows world, you use libraries to get things done.[/QUOTE]
Just for the record I work with both but I do consider them to be wildly different types of operating environments filling ultimately different needs. I use Cygwin a lot with Windows but there is nothing in the Linux world that really encourages the development of monolithic platforms for Linux.
If you use GTK, you have a dependency on Pango because GTK uses Pango for its text layout. It uses LibXML2 for its XML reading, so you have another dependency there. And so on. That’s how things work in the not-Windows world: you pick your libraries and use them. Some of these are provided by the system. Some of these are provided by you.
Not to nitpick but I am aware of that. I don’t use GTK for the record. But I do appreciate glib. But I’ve never developed a windowed app for X (so I don’t know what is required to integrate with the window managers; full disclosure)
Functionally, there’s no difference between having a dependency on Pango and having a dependency on Uniscribe. The only practical difference is that in the Pango case, you have to link to the library explicitly, while in the Uniscribe case, you don’t.
Exactly. It’s not a project (sourcecode) dependency. It’s under the hood.
OpenGL is supposed to be a relatively thin wrapper around graphics hardware, in order to achieve a reasonable abstraction and allow for a reasonable platform-neutral interface to that hardware. OpenGL’s job is not to make it easy to do complex things. It’s job is to make it possible to do complex things. If something can be layered on top of OpenGL, then it should be.
Well yeah. OpenGL doesn’t open any file formats. Fonts are files. So obviously rendering text is not implemented at the level of the OpenGL spec. But nevertheless it’s important to make graphics accessible and text mindlessly multilingual. IMO it’s pretty ridiculous that a consumer card cannot draw lines in 2012. But even I will admit that line drawing is less integral than drawing text, and there are legitimate, albeit pretty ridiculous, reasons for not implementing line drawing in hardware. Still it should be standard, especially as GPUs and CPUs become more and more integrated in mainboards. We shouldn’t be having a discussion about drawing text in 2012. Printf like drawing should not introduce a new library to a project. That’s just my opinion.
You won’t find any font rendering functions in D3D either, for similar reasons.
Search for D3DX.
[QUOTE=Inagawa;1242859]I am not working exclusively with Windows, actually. The use of GDI+ (a painful experience as it were) is just temporary.
So how would you gentlemen advise me to continue?[/QUOTE]
Yeah definitely. But you might consider different strategies depending on what your ultimate goals are. I am definitely following this thread, and it will definitely influence my work. I hope you don’t mind my taking advantage or it.
You basically would need to say what platforms you are targeting. What are you wanting to do with it. Is i18n important. Is it an opensource or closed source project. Is it of limited scope etc.
Depending on your answers a good answer might be yeah, if it looks good to you and it works, then that’s that right? Or otherwise you might want to hang around and see what doesn’t rise out of these ashes.
PS: If you are not planning on leaving planet Windows I think there probably are some things you can do to make things easier and nicer.
[QUOTE=dukey;1242860]
It works as a drop in replacement for wglfontbitmaps. Proper anti-aliased fonts for win32. Opengl 1-2 support.
It’s not especially fast because it uses gldrawpixels, which doesn’t seem to be very fast. But it works fine nonetheless.
If you use it credits to me please 
[/QUOTE]
[QUOTE=def;1242868]Why is nobody discussing FTGL, have I been missing something?
FTGL is a free cross-platform Open Source C++ library that uses Freetype2 to simplify rendering fonts in OpenGL applications. FTGL supports bitmaps, pixmaps, texture maps, outlines, polygon mesh, and extruded polygon rendering modes.[/QUOTE]
Just wanted to say thanks for these two posts.
EDITED: Also as for FTGL. I do worry about these kinds of projects not supporting particular (widely used; non proprietary) font file formats for quasi-political reasons. But on the other hand I would not be surprised if there are file formats and fonts exclusively used in the Linux world. In which case there is probably a strong argument for doing things in more than one way in order to make all the fonts anyone might want to use just work so that they will be happy 
It works as a drop in replacement for wglfontbitmaps. Proper anti-aliased fonts for win32. Opengl 1-2 support.
The whole point of wanting to replace wglFontBitmaps (besides potential performance issues) is to not use removed functionality like glDrawPixels and display lists.
Why is nobody discussing FTGL, have I been missing something?
Because it’s 8 years old and clearly no longer being supported.
IMO it’s pretty ridiculous that a consumer card cannot draw lines in 2012.
You can draw lines in consumer cards just fine.
Printf like drawing should not introduce a new library to a project.
This makes no sense. You don’t want to use Pango to do text layout, and you don’t want to use FreeType2 to do glyph creation and font processing. But you don’t mind if something else uses them, if it’s “under the hood”.
OK, but that something else… will be a library. Which, if you’re not already using in your project, will have to be introduced to it. The very thing you say you don’t want to do.
So I really don’t understand what it is you’re looking for. It sounds to me like you want some magical, “Do everything I want” library to poof into being. You want FreeGLUT or whatever to simply solve all of your problems as you get them.
That’s not going to happen; the sooner you accept that, the better.
Search for D3DX.
I did. According to Wikipedia, it’s Deprecated in the Win8 SDK. The only part that survives are the math functions that form the core of DirectX Math.
Also, D3DX is not part of D3D and it never was. It is a new library that you explicitly have to introduce to a project separately from D3D.
michagl: Well, the story is basically that I need a way of not only rendering the glyphs in good quality, but I also need all the glyph metrics, so I can position the glyphs individually.
GDI+ vomits some kind of metrics, but they are unusable.
I’d actually like to avoid using any external libraries at all if possible - I happen to be using C# and OpenTK, so any external library might be a big problem for me.
So let me get this straight. You want a cross-platform glyph rendering solution. But you don’t want to use an “external library” to do it (even though GDI+ is an external library). So… how exactly do you expect this to happen?
In general, the non-Windows world renders its glyphs through FreeType2. But that’s an external library.
I said I’d like to avoid using external libraries, but I will use them if there’s no other way. And GDI+ may be an external library to you (C++), but not to me - it’s part of .NET.
I’ll have a look at FreeType2, it looks sweet. Thanks for the recommendation, I’ll post here later on how it worked out.
Not in my experience. If you are using a normal consumer card for playing games changes are the lines will be broken and irregular when you use a line drawing API. This is still the case on a 1400$ gaming laptop that is going on 7yrs old. And its the case on an ATOM+ION2 (mainboard, cpu, and gpu in one) that is about 2yrs old now that I purchased as a backup. Actually the laptop has defect that kills the graphics modules, but I quit replacing them with the same model (because it became too expensive) and I don’t know if I’ve done anything with line rendering since. Prior to around the times programmable GPUs became the norm drawing lines just worked. Though I tended to have workstation cards back then. Maybe nowadays you need an extension or something.
This makes no sense. You don’t want to use Pango to do text layout, and you don’t want to use FreeType2 to do glyph creation and font processing. But you don’t mind if something else uses them, if it’s “under the hood”.
Sure. Whenever you use a library you don’t know what it is going to do under the hood. It’s an abstraction layer. If you want to do something like a publishing app then you might want a lot of control. But if you just need to display text you don’t want to complicate things, have to write a wrapper around a competing library that may not even be supported a few years down the line. You want something minimal and standard that can be relied on in the long term. Just displaying text should be as simple as writing text to a file in 2012. Since the ways to do that are not very mature on desktop platforms other than Windows there is no standard way to do it apparently. So we are just trying to figure out the best way in the meantime the way I see it.
So I really don’t understand what it is you’re looking for. It sounds to me like you want some magical, “Do everything I want” library to poof into being. You want FreeGLUT or whatever to simply solve all of your problems as you get them.
Yeah that’s how we do it. Ex. You don’t program a software rasterizer in 2012 and you don’t expect to.
That’s not going to happen; the sooner you accept that, the better.
It will happen but that’s not the point. It’s a shame it hasn’t happened yet, otherwise this thread would be unnecessary. We have something like gettext to do translation. Drawing text should be as simple and as commonplace. It is an additional dependency which almost everything already has as a dependency, but its minimal and entrenched and well understood. Text is a basic currency of information exchange. It should be provided at the system level and integrated into OpenGL. If we lived in a world where you didn’t need more than 65535 characters to render all of the symbols of all of our languages etc… if we just need ASCII things would be different. But the guts of Unicode need to be under the hood and easy to access so that we can easily communicate with it. It’s a travesty IMO but again just an opinion.
I did. According to Wikipedia, it’s Deprecated in the Win8 SDK. The only part that survives are the math functions that form the core of DirectX Math.
I think D3D is deprecated IMO because its not compatible with XP past D3D9. Microsoft had to bring back XP after it declared it dead because it did not anticipate netbooks and nettops and it doesn’t have anything for those class of PCs in the works. I love these things because I can buy a computer for the same price I used to pay for a cpu, and a mainboard, and a gpu, and presumably they are just going to get cheaper and cheaper… that’s a huge market to neglect. I have almost no expensive habits in my life nowadays.
Also, D3DX is not part of D3D and it never was. It is a new library that you explicitly have to introduce to a project separately from D3D.
It’s an extension layer for D3D. It uses the same interfaces. It’s analagous to GLUT. I think there was something else simply called Glu, but I forget, it’s been so long. I did not tend to use either. But that was around the turn of the century. Most of all D3DX is something the end user installs separately from your application and if they play video games will almost always already have installed. On Windows that is important, even though in the Linux world you have package management (that makes DLL hell look like a picnic)
[QUOTE=Inagawa;1242916]michagl: Well, the story is basically that I need a way of not only rendering the glyphs in good quality, but I also need all the glyph metrics, so I can position the glyphs individually.
GDI+ vomits some kind of metrics, but they are unusable.
I’d actually like to avoid using any external libraries at all if possible - I happen to be using C# and OpenTK, so any external library might be a big problem for me.[/QUOTE]
In my opinion the only worthwhile technologies Microsoft has ever developed are Win32 and COM (COM is slowly replacing Win32 completely which is probably for the best; D3D is an example of COM) and if you look under the hood of everything that MS churns out, MFC, ATL, GDI+, .Net, C# (and its 3 or 4 molts), all kinds of new stuff for Win8, and everything I’ve left out, of which there is likely many because I am very dismissive of all of them because like I was trying to say if you look under the hood you find out that these are all wrappers around Win32 and COM most of which have a very short life cycle. But I understand that MS requires the use of C# I think for some things like entry level Xbox development.
I would never use one of Microsoft’s static OOP APIs like MFC and GDI+. All of the fonts in Windows are based on a class of functions that are equivalent to DrawText in its Win32 and D3DX variety. It should be possible to generate metrics with these if they are provided… but I am wondering why you are mixing C# and OpenGL. That seems like an unusual pattern.
Actually I forgot. GDI is actually just the graphics APIs of Win32. So it’s definitely not deprecated. That means it’s just GDI+ that is solidly deprecated. GDI+ is just an MFC like version of GDI in my experience. So probably you are already familiar with this family of functions in one form or another…
http://msdn.microsoft.com/en-us/library/windows/desktop/dd144821(v=vs.85).aspx
EDITED: Search for “Font and Text Functions” (since microsoft.com links have a lifespan of only a few months)
I think that is everything, but I may be wrong.
The metrics should not be unusable. You are probably just not doing something right (unfortunately we are stuck with Microsoft’s “documentation” and short term memory until someone is able to topple this giant; and unfortunately compared to MS’s competitors MS really looks more and more like the friendly giant nowadays)
MS calls these APIs legacy (not the same as deprecated) but the truth is everything boils down to Win32 or COM and COM does not yet do everything Win32 can and it certainly can’t (and never will) on XP and all of Microsoft’s non-legacy (read: deprecated or-soon-to-be wrapper) APIs are always supplanted after a year or two so they are really not worth the investment if you envision your code being useful ~2 years from whenever.
Not in my experience. If you are using a normal consumer card for playing games changes are the lines will be broken and irregular when you use a line drawing API.
Define “broken and irregular”. Lines are drawn. They may not be pretty, but they’re drawn from point A to point B.
It’s an extension layer for D3D. It uses the same interfaces. It’s analagous to GLUT.
No it isn’t. GLUT is a toolkit for creating and managing OpenGL windows, with a few ancillary functions for doing useful things. And though D3DX provides many features, conspicuously absent from that feature list is a simple way to create and manage a D3D window. Similarly, D3DX’s primary features are math functions, image loading, meshes loading, and shader/effects loading and management, none of which you will find in GLUT.
Please stop trying to pretend that two libraries that have completely different purposes are in any way comparable just because they’re named similarly.
GDI+ is just an MFC like version of GDI in my experience.
:doh:
In the future, please take the time to do some research before forming an opinion and spreading misinformation.
D3DX is more analogous to GLU. The functionality provided by each library may differ, but the underlying intent is much the same. So you’ll find routines for quadrics, tesselation, some limited matrix work, some helpers for texture loading in GLU, and you’ll find a whole bunch of other routines in D3DX, some of which overlap, but in both cases they supplement the core API (by wrapping functionality, by providing some handy helper routines, or by providing an implementation of some things that you would otherwise need to write code for yourself) rather than being an actual part of it. It’s perfectly possible to write a GL program without even touching GLU and it’s perfectly possible to write a D3D program without even touching D3DX.
Re: drawing lines - both OpenGL and D3D provide support for lines (lines are even still a core primitive topology type in D3D11), but the problem may occur when you talk about lines wider than 1 pixel, which may or may not be supported in hardware by consumer cards.
Am I right to assume, that to position all of the glyphs on the same ‘line’, I need to take the (Height (yMax) - bearingY) and add that to the Y coordinate, no? Trying this with Cairo, it’s inaccurate. I’ve yet to properly try this with FreeType1 (Don’t have access to FreeType2).
I am proud to report that so far I’ve been successful. I am now rendering text with subpixel filtering and the quality seems awesome so far.
I’ve also made some drastic changes in design of the fontmap and sped it up.
The old fontmap could generate about 13,000 glyphs in about 13 seconds, while the new one can generate 15,416 glyphs in 1.32 seconds.
I’ll have to do quite a few tests to determine if everything is okay, so I’ll probably post some update tomorrow.
Broken, there are sometimes pixel wide gaps in the middle of a single line. Irregular the corners do not mate sometimes at all. In my experience you are only guaranteed the suggestion of lines. Though there may be cards that flat refuse to draw lines (I haven’t researched it)
Sometimes it seems like the run-length is cutoff so that the lines are not even locally straight. I started noticing this with OpenGL a long time ago, and I was told, and it was common knowledge at the time that line drawing was out if you have a sub-workstation video adapter.
No it isn’t. GLUT is a toolkit for creating and managing OpenGL windows, with a few ancillary functions for doing useful things. And though D3DX provides many features, conspicuously absent from that feature list is a simple way to create and manage a D3D window. Similarly, D3DX’s primary features are math functions, image loading, meshes loading, and shader/effects loading and management, none of which you will find in GLUT.
I’ve worked with Glut or maybe something similar called Glu that does all kinds of D3DX like stuff, drawing quadrics and primitives for example. This is nitpicking. An extension framework can implement whatever kinds of extensions that seem to be necessary or desirable.
This seems like a meta argument / disservice to the thread to me.
Please stop trying to pretend that two libraries that have completely different purposes are in any way comparable just because they’re named similarly.
What is named similarly? Nvm. I really don’t care:tired:
:doh:
In the future, please take the time to do some research before forming an opinion and spreading misinformation.
If I had to do research before opening my mouth I never would. But for the record anything I’ve ever seen GDI+ used for you can do with GDI with a little extra work. I don’t doubt there may be exclusive things it can do. But then it would seem odd to deprecate it without deprecating GDI or migrating the features into GDI.
I did happen to inadvertently do some research into C#. I must admit I really don’t understand it other than it looks like a way for Microsoft to alienate itself away from C++. There is an ECMA standard for it oddly enough even though only MS implements it. I always assumed it was compatible with “managed” (Microsoft extensions) C++ and C++ itself. I’m assuming it can dynamically link to C/C++ libraries, otherwise it would be a total island of unusability. Either way I apologize for lumping C# into the above post. I think I meant managed C++. I could not figure out what C# is good for; and am even less inclined to use if for anything now. Being a beast of Microsoft it seems strange to breed it with OpenGL… I’m intrigued at least:)
Edited: @ [b]mhagain[/b], sorry I did not notice the two posts on the top of this page. Unfortunately I can’t do a ton of tests with different hardware to get an idea about the state of 1px wide line drawing. I am pretty sure I am not hallucinating the bottom falling out of line drawing since a half a decade or more years back. I’ve always assumed the girth of papers describing ways to draw lines without line drawing was an attempt to win back this lost functionality on consumer hardware and that the support for line drawing was worse than just being slow. Anyway it’s offtopic.
@Inagawa. Are you planning on publishing your source code? Are you generating glyphs on demand? A lot of the time a font will have a lot more symbols than you actually need, and a lot more than will fit on a texture. I wonder myself if the D3DX DrawText implementation draws its vector fonts to a texture or if it just draws them as a flat 3D mesh. The D3DX docs kind of suggest they are drawn to a texture as I recall, but without looking at them (so sue me) it could also be interpreted as drawing to a vertex/index buffer.
My fontmap doesn’t just pick some random glyphs and slap them on a texture, you tell it which exact symbols you need represented (there are a few constants in place so you don’t need to write them by hand) and it bin-packs as many as it can on a texture (the size of which you specify). If there isn’t enough space on the texture, it simply creates another one and continues there. You then just request all the info by calling a simple GetGlyph() function which returns all of the information that you need to successfully position and render the glyph.
You can even update the texture with new glyphs as you go, even after they are made into an OpenGL texture.
Also, to defend C# - it’s not a microsoft-exclusive language; since the ECMA standard, Mono developed C# compilers for all the other platforms you could ever need. C/C++ interop is achieved either through P/Invoke system or by writing a C++/CLI wrapper that can be accessed from C#.
Edit: Success, Pango is now the backend for rendering and measuring the glyphs. Now just to figure out where to set the filtering.
OT: Any chance you’re a Fox News or MSNBC anchor? :doh:
Why all the hostility towards him?
Why all the hostility towards him?
He admitted to not bothering to actually learn things before trying to make claims about them. That kind of thinking deserves hostility.
I seem to recall a quote, “Better to remain silent and be thought a fool, than to open your mouth and remove all doubt.”
Yeah I am paid to post in forums. And whenever I am asked a question, I say, excuse me, I don’t want to be rude or anything, but can you wait for me to do some research 
Why all the hostility towards him?
Because this is the internet and everyone is welcome to participate
Also, to defend C# - it’s not a microsoft-exclusive language; since the ECMA standard, Mono developed C# compilers for all the other platforms you could ever need. C/C++ interop is achieved either through P/Invoke system or by writing a C++/CLI wrapper that can be accessed from C#.
I see. Someone should somehow add Mono to the version table on Wikipedia. It gives the wrong impression. So much for doing research!
I did look back to find Bjarne’s take on C#. He suggested it’s proprietary (and lamentable) in his site’s FAQ.
I did notice BTW that wglUseFontOutlines returns metrics in the form of GLYPHMETRICSFLOAT. They are not super sophisticated but are probably acceptable for most applications (without researching and writing a program to see for myself; irresponsible of me I realize)
Anyway wglUseFontBitmaps doesn’t seem to do this so it’s easy to miss, but it isn’t clear that wglUseFontOutlines can do bitmapped fonts. And the docs explicitly say “TrueType” which I assume limits fonts to vector formats not limited to .ttf.
This is why it would be nice to have standards.
I seem to recall a quote, “Better to remain silent and be thought a fool, than to open your mouth and remove all doubt.”
Said the (edited: incredibly vain of dubious character) fool
PS: How many posters here are interested in rhetoric vs fonts? I for one would like to keep the discussion going because as I’ve stated I am still not personally convinced what to do about fonts vis a vis OpenGL and am interested in the experiences of others.
OT: So, you want participation without qualification? Don’t we have enough Romneys already?