samoth

That won't work. You have only 3 legitimate options:

• disable depth writes (using the GL API, not in GLSL) -- this will not write depth for any pixel
• don't write to gl_FragDepth in your shader (not at all) -- this will use the interpolated depth instead
• discard -- this will kill the fragment, including depth (but also color)

Writing to gl_FragDepth for some fragments and not doing it for some others is theoretically possible, but a shader doing so is not well-formed. The outcome is undefined.

To throw away pixels that you don't want, I'd just discard, that's what it's for. It discards the color value, nothing is written out.

I'd add that it's worth noting the difference between "licence" and "licence agreement". Most software has a licence, though that doesn't mean the user has to agree to it; a licence isn't necessarily the same thing as a contract (indeed the GPL makes the point that it isn't a contract, and no one has to agree to it).

Well, yes and no. As soon as the user tears the shrinkwrap open (on a physical copy) or installs/uses the program, there is an implicit (and sometimes explicit, by clicking the "Yes, I agree" checkbox) agreement.

The user may not respect the agreement or all of its terms, and he may not even have read it (most people don't read!) but as far as the lawyer cares, it's certainly an "agreement".

It is not possible to legally use the software otherwise either -- usage of a software is only permitted with a valid license, and a license (usually, except for the Do-WTF-You-Want license) contains a paragraph that states the license is only valid if you agree with the terms. The user can of course still use the software illegitimately, but in that case it will be rather hard to press charges against the author.

Though, in the USA, maybe even that is possible. I've heard of a burglar who cut his arm entering a house and sued the house owners for having glass windows that can cut your arm when you break through them. Not sure whether that was a hoax or real...

Subtracting 32 from character codes is not something you would normally do, not even in western scripts (not for TTF, anyway -- you might do that if you use your own bitmap font where glyphs start at zero and the space character is your first defined glyph).

For Asian fonts, you obviously must support Unicode in some way, since you'll be using considerably more than 255 different characters. Whatever you use is your decision, as long as you convert them to UTF-32 at the end (before passing it to stb_truetype). I'd go with UTF-8 for storage because it's straightforward and more efficient than UTF-32. Conversion routines are freely available too, so there's not much you need to think about.

UTF-16 is larger for most languages and has no advantages over UTF-8, but it has all of its disadvantages (e.g. non-obvious length to character count mapping), plus it does not work with legacy string routines and isn't as "intuitive".

Note that using the "standard" Segoe_UI.ttf font will require you to buy a license from Monotype, unless you rely on it being installed with the operating system (not the case on MacOS X, that'd be Lucida instead).

Also, you may need to redesign the UI, since different languages can have grossly different text lengths (up to 30-40% difference) and directions -- though I think you can legitimately write Japanese and Chinese left-to-right instead of top-down-right-to-left, as an alternative style.

This is not Adobe's model, it's Salesforce's model, and Adobe is only the last one to adopt it, after Microsoft (Office 365, anyone?). Though of course, the original selling gag was "you only pay for what you actually use (evil laugh)", not "you pay for everything, flat". It's not surprising that Adobe would pervert an already rotten concept further, though.

So you're upset, but honestly, who cares. They'll still go that way, even if people are unhappy. Adobe has been selling overpriced products for decades and has successfully used its market position to push inferior and ill-advised technologies (PDF, Flash) to mainstream. They're now only following the "everything must be cloud" movement that the entire industry is going, and they're using the opportunity to secure a market position for their less valuable products (people will use them since they've already paid for the package, and many people using a product raises its market value, think Microsoft Office) as well to make more profit on a regular, predictable base.

Someone said "open source" above, which if you allow me to say, is a joke. The sole reason why Adobe is in such a position is that there is no alternative. Open source (or gratis non-OSS) image processing software is ridiculous. Inkscape may be somewhat of an alternative as a vector drawing program, but that's about it.There's Blender for 3D, but that's an entirely different thing.

For pixel processing, there's Paint .NET, which offers about 1/4 of Photoshop 7.0's features and has an interface that apparently tries to look somehow like Photoshop, and then doesn't.There's GIMP which is unwieldy and slow, and the second worst software I know of. And then there's those 3-4 more or less similar programs from Corel (PaintShop and what they're called), which are just about good enough to crop the photos that you want to upload to Facebook. Oh right... Picasa. did I forget an important competitor? I think not. If you are somewhat serious about raster graphics, you have no choice but to use Photoshop, there simply exists no alternative.

Insofar, Adobe can do just what they want, they'll sell.

[...] using displays with different refresh rates [...] delete window after creating context and use with another window

Behold, you found another case where different contexts may be an advantage or necessary. You can only (successfully) call wglCreateContext on a HDC that lives on the same device and that has the same pixel format (see MSDN for more info). This is not problematic for the theoretical case that you described about destroying the original window.

However, in a multi-display setup, it is in principle possible that different displays are attached to different devices, so that wouldn't work by the wording of the documentation.

Now don't ask me what happens when you move a window from one screen to another... this works fine in my single-GPU-multiple-display setup here (obviously, same device), but who knows what happens if you have 2 GPUs on 2 displays. Still, I figure that moving a window to another desktop is a legitimate thing to do.