Fontmaps

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.

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.

Quote:

---

Originally Posted by Alfonse Reinheart

Define "broken and irregular". Lines are drawn. They may not be pretty, but they're drawn from point A to point B.

---

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.

Quote:

---

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.

http://en.wikipedia.org/wiki/OpenGL_Utility_Library

This seems like a meta argument / disservice to the thread to me.

Quote:

---

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:

Quote:

---

: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: @ mhagain, 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.

Quote:

---

Originally Posted by michagl

If I had to do research before opening my mouth I never would.

---

OT: Any chance you're a Fox News or MSNBC anchor? :doh:

Why all the hostility towards him?

Quote:

---

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."

Quote:

---

Originally Posted by thokra

OT: Any chance you're a Fox News or MSNBC anchor? :doh:

---

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 :)

Quote:

---

Why all the hostility towards him?

---

Because this is the internet and everyone is welcome to participate :)

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by michagl

And whenever I am asked a question, I say, excuse, but, I don't want to be rude or anything, but can you wait for me to do some research. [..] Because this is the internet and everyone is welcome to participate :)

---

OT: So, you want participation without qualification? Don't we have enough Romneys already?

Don't say his name, let's refer to him as "the guy who believes he gets to play god on his own planet after he dies". A little long, though.

Now, to the fonts. I have managed to get Pango up and rolling, so now it's just a question of programming some textbox class and test how well the metrics hold up under a real stress. I have also noticed that there are a lot of strange symbols in the UTF-8 ranges. Some symbols are kind of "associative" in that they stick to other symbols. I am yet unsure if my fontmap will be able to represent those symbols, for I haven't made much research on that.