Full of BS » C/C++

c++0x standard finalized; now open for last international comment phase

John Haugeland — Fri, 31 Oct 2008 22:20:04 +0000

It’s finally done! And, thank god, “concepts” are officially in.

Gearing Up for Public SVN

John Haugeland — Thu, 24 Jul 2008 16:01:46 +0000

I’m going to be releasing a few new libraries in the next several days, both by archive and public subversion. I’ve already bought the domains and built a forum for them. I even wasted a couple hours subversion automating everything down to the line of having little library websites made automatically, with custom per-library color palettes.

I was a little bored.

So we’re going to have three libraries progressing in the immediate future, with quite a few more over time:

HtStub – An embeddable, zero-config, zero-behavior secure Erlang webserver
SC A-Star – An efficient, modular ECMAscript (flash/actionscript, javascript, jscript etc) A* implementation with support for custom grid geometries (includes algorithm tutorial)
TestErl – unit, regression and stochastic testing for Erlang
ScUtil – a fairly large list of gap filling functionality for Erlang

In the near future, I will add C++ and PHP libraries, as well as many some libraries for more obscure languages like FormulaONE, Mozart-Oz, Factor and maybe (sadly) Delphi. I have more than 30 libraries ready for release.

All those repos are pretty empty at the moment. That will change in coming days, and I’m sure I’ll post lots of boring little snippets here about whatever minor new thing my crap does.

Yay!

Eep. Yasli::vector is on the move!

John Haugeland — Wed, 03 Jan 2007 00:26:47 +0000

Yeah, I know I’ve been quiet for a long time. There’s a good reason, and it’ll all make sense soon. However, I just stumbled across an article that is so amazing that I just can’t wait, and I need to share it. Andrei Alexandrescu is a brain, but this one’s special, even for him.

yasli::vector is on the move – read it or fail. Miserably.

(Sorry about the PDF. I hate them too. Nothing I can do.)

Checklist for Embedded IE

John Haugeland — Thu, 24 Aug 2006 02:13:56 +0000

MSHTML is an awesome user interface tool, but it has a whole lot of standard behaviors, many of which aren’t what one wants for an application (since it’s designed for the web.) This is a list of stuff you need to do to embed IE COM and have it behave like a normal application. There’s more than a person might expect.

Suppress the user interface. IE starts with most of its interface turned off, but a few things aren’t. Notable things to include are to suppress the context menu and keyboard navigation.

There are several ways to suppress the context menu. The easiest way is to do it in the html. Add oncontextmenu=”return false;” to your and the problem just goes away, and it’s easily manually overridden for specific elements later.
Alternately, you can override the interface programmatically through IDocHostUIHandler.

Get rid of the OnNavigate noise (the clicking sound when you hit a link.) This is harder than it should be.
Prevent keyboard navigation. If you only ever navigate once, and then do everything else in DHTML, this isn’t an issue, because there’s nothing to go forward or back to. However, if you need to, the way to do this is to capture DWebBrowserEvents2::BeforeNavigate2() and fill its last parameter, VARIANT_BOOL*& Cancel, to true. For security reasons this can’t be done in HTML without a garish ugly dialog box confirmation.
Prevent dragging and dropping links. Do this with BeforeNavigate2() just like keyboard navigation.
Prevent selection. The easiest way to do that is in the HTML by adding onselectstart=”return false;” to the , which is also easily overridden for child elements where appropriate. If you need it programmatically, such as a block which can be turned from and to editability, that’s in IDocHostUIHandler.
Handle some keys directly. Particularly often, control keys, tab and f-keys need very different interpretations in applications than are the defaults in IE. Some keys can be reliably intercepted in JScript, but not all of them. For lightweight stuff, use JScript; it’ll be less painful. However, if you need real control, you need to provide an IDocHostUIHandler::TranslateAccelerator() implementation.
Suppress the interior border. People are often surprised that they turn off the window border in IE, and yet it seems to still appear. That’s because IE’s default stylesheet puts an inset bevel on every web page. Turn that off in CSS by writing body { border: 0; }.
Begin to embed your images and other support media as resources, and access them with the res:// protocol.

One ugly caveat: I have never found any variation of the DirectX PNG alpha filter hack which works with res://, and I’ve looked often and at some very weird variations. It is my current belief that a PNG cannot be embedded through res:// and still be fixed for alpha. This leads to the unfortunate case of requiring at least part of your resources on disk. If anyone knows a way around this, a heads-up would be greatly appreciated.

Set up a system to exchange messages between IE DOM/DHTML/JScript and your application. There are a bujillion ways to do this, but I tend to use a combination of intercepted element events (mostly OnClick in WebBrowserEvents Invoke,) DOM extension behaviors that allow me to call C++ directly from JScript through IDocHostUIHandler::GetExternal(), and executing scripts directly on the DOM object through IHTMLWindow2::execScript().
Build everything in the to be inside a container; make the body itself overflow: none. This prevents several ugly re-layout quirks which we’re used to on the web but not in applications, when content gets long.

Start the container invisible, and make the black. That way, during the lag while resources are being loaded, you have a reasonable appearance. Black flashes look correct. White flashes look broken.
Set an onload=”HandleLoad();” function for the . That way, you know when all resources are loaded, and thus when it’s safe to take the invisible clause off of the main container.
Set the main container position:relative, to make absolute positioning of contained elements easier.

Build your web page in as a resource, and load it through IHtmlDocument2::write(). This allows you to load a document at runtime without using about:blank (which most people use, but which causes a brief white flash before your application loads; very unprofessional looking.) You’ll need SafeArrayAccessData() and SafeArrayUnaccessData() to use write() safely. When it comes time to skin or internationalize, and when you’re dealing with a compile cycle which is just linking, you’ll thank me for this.
Suppress dragging on links and buttons. If you don’t, people will be able to drag them outside the app and onto the desktop as shortcuts, and when followed those shortcuts will lead into your HTML page from the outside (which is, surprisingly, legal.)
Consider compressing your executable, such as with UPX, which makes resources unreadable externally.
Set an id on your . The is considered the origin of most events which don’t have a clear origin, and that means that catching these events is a lot easier (catching by id is the most straightforward way to sort out sources.)
Resist the urge to use runtime styles. They’re not worth the problems they cause.

That should get the new IE user through some common foibles. I’ve probably missed stuff; if you can think of something, lemme know. I do not currently know of a way to embed flash, unfortunately, without leaving available an extra file.

Oh, Neat: A Hack To Fix The IE Click Problem

John Haugeland — Thu, 24 Aug 2006 01:08:44 +0000

I always wondered how applications suppressed that god-awful clicking sound in embedded IE. Usually you catch them screwing with user preferences, but there’s a utility I have which never showed any apparent method of getting rid of the goddamned noise. I always assumed they just styled text to look like a link.

Well, I still don’t know what he does, but I found a way.

Back in post #141, More IE Woes, I documented several problems. One was that MSDN claims this noise cannot be suppressed. Indeed, by design, IE6 refuses to allow you to suppress that sound (god knows why.) That MSDN article goes as far as to tell you to override the user’s sound preferences to turn the noise off. How badbear is that? Anyway, IE7 finally has an interface to turn that off, called FEATURE_DISABLE_NAVIGATION_SOUNDS. However, people like me who are reluctant to make their applications non-functional without IE7 will not like that answer.

It turns out there’s a better way.

There’s a moderately obscure interface from IE5 for IDocHostUIHandler called GetOptionKeyPath. The superficial purpose of this is to allow the IE embedder to create a fake user, so that they can set defaults for IE like the basic font size, background color and so on. This is generally completely ignored in favor of some CSS, but it turns out that this thing actually covers the sound effect scheme too.

All you need to do is use GetOptionKeyPath, create a fake user, override the OnNavigate sound (and maybe some others) to nothing, and let the rest alone, to default to the user’s preferences.

Bang: no more clicky noise, and no overriding preferences, breaking other applications and risking corrupting preferences on crash.

Very clean.

More IE Woes – This Time, from the Inside

John Haugeland — Fri, 23 Jun 2006 02:01:24 +0000

Wow. I haven’t had such mixed feelings about IE in years.

On the one hand, MSHTML – the COM component that implements IE – is actually pretty awesome. I’ve been able to roll applications using it in hours that would normally have taken weeks. It’s an impressive feat of engineering, and though I disagree with some design decisions, the usability of the embeddable component is actually pretty spectacular, if you’re familiar with COM. In particular, the res:// protocol strikes me as borderline brilliant; binary behaviors are awesome; extensible tags have a lot of untapped potential; BHOs would be great except there are too many spamming scum abusing them.

On the other hand, there are problems. There’s one outright boneheaded mistake, and the documentation is sadly lacking.

The OnNavigate sound – that click you hear when you get a link – cannot be suppressed. I’m not joking – by design, IE refuses to let you get rid of it. Their suggestions are to override the user’s global IE preferences, shut off sound, or to hide the browser before you follow any click and then re-show it after the click. Given how much Microsoft blabbed about how this should be usable as a transparent control, it leaves me flabbergasted that they haven’t fixed this until IE7 with FEATURE_DISABLE_NAVIGATION_SOUNDS. Just amazing.

Update: I found a way. MSDN is wrong about this; it is indeed fixable.

This bit about being unable to touch innerHTML on several tag types (notably table and tbody, where it’s hella useful) pisses me off, but since I can work through DOM, it’s annoying rather than important.
One of the particularly wootastic things MS did was to generate an interface called IDocHostUIHandler by which one can inject new functions into JS’ purview through the DOM and window.external , allowing you to effectively provide new interfaces just by implementing a COM object with the automation interfaces in IDispatch. Of course, I can’t find a complete example in pure-c++ without ATL, WTL, MFC or some other ignorant wrapper nonsense to save my life, so I’m pretty stuck. I have a mostly-complete implementation, but when I try to install it, window.external turns to null, suggesting a flaw. Of course, all the error handling is in window.external, where I can’t get at it, so your guess is as good as mine about what’s actually going on.

With some extra documentation and if they hadn’t been such tards about that clicking noise, MSHTML would be a much more wonderful playground than it actually is. (I’m pretty sure there is in fact a way to disable those noises – several commercial applications do it just fine – but MSDN insists it’s unpossible, which suggests it’s probably some undocumented interface somewhere. Hell.)

On Shadowcasting

John Haugeland — Sun, 02 Apr 2006 06:09:18 +0000

I haven’t written a roguelike in a long, long time. Last time, I used the traditional light-per-room model for lighting from the original Rogue; these days, I don’t find that at all satisfactory. It’s time for a proper shadowcaster.

And, to be plain, I’d forgotten how much of a hassle a shadowcaster actually is. I went to dig up maybe some example code, but the good answers were few and far between; there are several each at various roguelike sites like Dungeondweller, but the articles are written to widely varying levels of quality, most without source, and with no apparent method to compare between methods. Most of them an experienced programmer can ignore out of hand, but one of the algorithms up there is just repeated line of sight, which is dead slow. It’s enough to make a man think about writing another tutorial…

Luckily, I know what’s up, so I’m going to implement recursive shadowcasting. There’s a not-half-bad implementation in this tutorial by Gordon Lipford, but in several places he sacrifices efficiency or power for readability. Right thing to do for a tutorial. Wrong thing to do for production code. (He also has several unexplained actions here and there, writes pseudocode where interactions aren’t clear, and requires the reader to reimplement several structures from explanations, but whatever.) At any rate, his method is efficient, flexible, and less painful to implement than some of its competition, so I’m running with it.

One of the very cool things about Lipford’s method is that it’s arc-angle based. As a result, objects don’t actually have to fit a tile; rays are radiated. That means that anti-aliasing one’s shadows is in fact realistic; I’m halfway done with that in my shadowcaster now. Other things could be added, but I’ve decided to skip them for now. One of the really neat things about this modified method, though, which uprises from the line of sight algorithm is that I have accurate overhead cover rules and a good set of premise data to work in the notion of “perception.”

Simulating perception accurately is traditionally a problem for AI behavior, but in a Roguelike it’s a bigger problem than usual. Because roguelikes offer such complex tactical situations, and because speed in varying environments is such an issue, players often want to “lose” the predators by hiding. Lots of the common methods for handling roguelike behavior involve simple distance calculations, meaning monsters can semi-effectively follow you through visual obstacles which otherwise should confuse them, such as walls. Sometimes this is of great tactical advantage to the player; s/he can use slight speed or distance advantages to get around a wall with a u-turn, then rely on the monster keeping the nearest mathematical distance and walk the other way down the wall, acquiring some safety.

Now, I’m all for cheating on the player’s behalf; one of these days I’ll blog about it at length. However, there’s cheating and there’s cheating. Some of it keeps little nagging things from ruining gameplay; that’s good cheating. Being lax on player bullet collision, and being overstrict on player personal collision, means that the player “just barely gets by” when oftentimes they shouldn’t, and “just barely makes the shot” when oftentimes they shouldn’t. You can just crank the game difficulty to compensate, and it leads to a player never feeling like they were ripped off or cheated. The Japanese game company Treasure are absolute masters of this careful balance (sorry, AFAIK they don’t have an English-language page. Just pretend you can read it.) But, there’s another kind of cheating that game programmers do. Actually, there are several others; I’m gonna skip stuff like giving opponent AI information it shouldn’t have to keep it competitive. Right now, what I’m going to talk about is sacrificing realism for computation time.

There are several problems with cheating to save computation time. Some of them are reconcilable; others aren’t. Generally the least controllable issue here is that oftentimes you just can’t afford the raw horsepower to do what you want to do correctly. First person shooters in the 286/386 era are a prime example; Wolfenstein and DooM got by just fine with blitting, but given modern standards they look positively silly. The important bit here, though, is that Wolfenstein and DooM’s approximations were good enough™ they did not adversely impact the game, and until they were made outdated by the horsepower required for a more accurate solution, the impositions their techniques created generally didn’t impact the game. (There are a few exceptions, notably the 2d+height map preventing truly 3d maps, but that was more of an engine issue than an issue of approach, so whatever.)

Horsepower aside, though, there are also issues of sloth or ignorance. In fact, field of view algorithms provide an excellent example even compounded above the previous example. Gee, can you guess what I’m gonna start going on about?

The fact of the matter is that on a complex 2d planar map, even implemented well, field of vision code is moderately expensive. Hansjörg Malthaner brags, and rightfully so, that his field of view implementation can crank out a 59×59 area in under 2ms on a 400mHz k6/2. Whereas that may sound like hopelessly antiquated equipment by today’s standards, please remember that that’s talking about the field of view for just one creature; even dealing with a machine that can push 16x what that does, when you’re dealing with (say) 256 creatures – and that’s not terribly unlikely in a Roguelike at deeper levels – you’re still looking at around 32ms, just to figure out what monsters can see what. That’s before you consider anything like, say, what the monsters’ responses would be. And, to put that in perspective, we’re talking about a full two frames at 60fps (the rate at which most console hardware runs) – that’s slow enough to see a stutter, even on modern hardware.

And – I cannot emphasize this enough – Hansjörg’s implementation is good. This is not the upshot of some naïve bumbling. This is what kind of speeds one should expect.

Now, granted, this is a fairly severe situation. For one, 59×59 implies sight radius 29, which is big by anyone’s standards, and since we’re talking about area which is exponential and a workload tied to a surface unit instead of an edge, and since that workload is also exponential, then having an area that big is pretty serious. Also, games other than roguelikes don’t usually have low to middling hundreds of active, thinking opponents at a time (well, inasfar as roguelike creatures think, really, but that’s beside the point.) But, as we all know, I’m working on the Nintendo DS, which is a 67mHz ARM9; when we’re there, we’re just not talking about cutting edge computational power, and therefore speed seriously matters to me. Granted that the field of view in my game is much smaller, it’s still a pretty big issue.

This is where the kung-fu comes in. See, there are other repurcussions to choosing a field of vision mechanism other than speed. Granted speed is what we’re interested in here, but there are other things to be considered. That is, for example, why I’m not implementing the giant goto map generator of Jesse Welton’s. Instead, what I’m doing is going to give me view regions for specific tiles; that information will be enough to implement a much, much stronger perception algorithm, by gauging what fraction of a tile is visible. That way I can have monsters with very long sight who won’t notice you sneaking up on them around corners, or monsters who only see six or seven tiles away, but who notice absolutely everything in range. It should make far more satisfactory AI chase behavior, especially since I’m going to be tracking actual creature knowledge.

Anyway, that’s just what I’m working on in Southgate at the moment. New topics soon.

Container Selection Posters

John Haugeland — Sun, 12 Mar 2006 04:52:20 +0000

So I put up a new store, for programmers who need reference charts, and I’ve even put one whole product into it (well, three, because I made three different sizes, but whatever.)

There will be more soon, which is to say “when I get around to it.” But, for now I’ve put up one thing, and that thing you shall buy. This is the fifth store joining my panoply of pointless shopping options, alongside my sudoku store, my anti-Bush store, my go store and my programmers’ bookstore.

Buy, my monkeys, buy!

C Problems For The Poser Programmer In Your Life

John Haugeland — Fri, 10 Mar 2006 09:15:05 +0000

Someone happened to give me a link to a set of interesting C problems, which though not intensely difficult are enough to make a novice take pause. Some of them are even eye opening for novices. It’s an interesting read.

As an aside I’ve been looking for documents like this for various languages. I’ve also got the excellent Parashift C++ FAQ Lite, the FAQs.org list, and lord knows more than enough books; still, other good documents from which to derive tutorial material would be highly appreciated.