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:

1. HtStub – An embeddable, zero-config, zero-behavior secure Erlang webserver
2. SC A-Star – An efficient, modular ECMAscript (flash/actionscript, javascript, jscript etc) A* implementation with support for custom grid geometries (includes algorithm tutorial)
3. TestErl – unit, regression and stochastic testing for Erlang
4. 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!

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

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

The list of falsehoods in this article is both startling and borderline offensive to the adequate programmer.  I’ll just copy them as a list and respond to them individually.

• C++’s virtues are expensive. Advanced OOP features, such as templates and the practice of using classes in the place of primitives, to name two examples, cause unacceptable code bloat.
• Malarky.
• Using classes in the place of machine types (there’s no such thing as a “primitive” in C or C++, you Java wank) has exactly zero overhead by design, except in those cases where one has RTTI turned on, which one should not for embedded.  Classes are structs and structs with a single member are, as in C, equivalent in storage to said member.  This is a requirement for C/C++ to match structs to hardware registers.
• Using templates doesn’t cause massive bloat.  Templates are only instantiated for the types in which they are used.  For classes and structs this generates zero overhead without virtualizations, and one vtbl per finalized type with.  In either case, the comparison to a parallel C implementation requires the same functions to get filled out and used; this means that C ends up with at least as much binary, just hand-made.  Furthermore, C++ (since it knows what it’s up to) can frequently share large parts of, and occasionally the complete implementations of, said functions, meaning the C++ implementation – along with being shorter, cleaner more maintainable and always correctly linked code – is also frequently binary smaller.
• A C++ compiler may generate many routines for one function (templates) or create routines where no function explicitly appeared (constructors, casts, etc.). There is generally a one-to-one relationship between a function in C code and the resulting machine-code routine. It’s easier to optimize what you can see than what you must infer.
• Empty constructors are optimized out during link.  You might as well complain that C++ has constructors for integers.  They do not exist in the binary, take no space and are never called.  There is just as much a “one to one relationship” between C++ code and binary as there is with C, if you know what the code actually says.  Complaining that the language considers every type to have a constructor, when it gets optimized out and has zero impact, is just silly.  Wah wah, the language wants to be uniform and not have special cases that cost nothing.  The sky is falling and so is my soufflé.
• The notion that there being a one-to-one relationship between your code and your binary output is either rare or significant is just absurd.
• “It’s easier to optimize what you can see than what you must infer.“ 
• You don’t need to optimize things with no cost.
• Premature optimization is the root of all evil stupidity.
• To infer suggests that you had to do some detective work to ferret out that this is being done.  Sure, if you don’t know C++ you might have to infer some things about it.  This is equivalent to someone complaining about discovering the branch overhead of calling a function in C, because they didn’t know the language and didn’t know it’d happen.  You’re complaining that a language you don’t know does things you don’t know about.  Boo, hoo: read a book, Charlie.
• Virtual methods and polymorphism complicate runtime linking and require many relocations. This slows C++ application launch time considerably. C applications are both simple to link and amenable to lazy linking, so they load quickly. (For details, see Waldo Bastian’s paper “Making C++ Ready for the Desktop”, http://www.suse.de/~bastian/Export/linking.txt.)
• No.
• Virtual methods and polymorphism allow runtime linking.  In C, you can’t have runtime linkage, unless you roll it yourself, and if you roll it yourself you’re just reinventing what C++ did.  Given that at runtime you don’t know as much about the nature of the code as the C++ compiler did, you are guaranteed to be unable to do as good a job as C++ does while remaining correct (read: safe) and portable.
• Neither virtual methods nor polymorphism have anything to do with relocation. 
• Relocatable code is code which is compiled to an address offset rather than an address.  This is useful for situations in which code is to be loaded at an unknown address, such as with dynamically linked libraries, static objects, and pretty much anything in a multithreaded environment.  If code is relocatable, then you can just load it at whatever address has space available, set the offset to that address, and wham, everything works.
• Thing is, this isn’t how things work everywhere.  An embedded programmer should know this.  Non-relocatable code is compiled to a fixed address.  This is marginally faster, as it skips an addition during lookups and function calls, but that’s not tremendously important.  With relocation turned off, as is the case in most embedded environments, polymorphism and virtual methods still work just fine.  Ask anyone who writes games for a console video game system; because the programmer is in complete control of the machine, relocation is generally unnessecary, and so is generally disabled, but we still use polymorphism and virtualization extensively.
• Nothing ever requires multiple relocations.  It is contrary to the concept of location in a single dimensional memory space.  This is just retarded.
• Relocation has zero impact on “C++ application launch time.”  Relocation is used in any application written for Windows, including not only C applications but also windows assembly applications.  Relocation has identical impacts on those applications as on C++ applications.  The impact that relocation has on the launch time of general applications is trivial: it’s the writing down of one single solitary offset.  It’s an allocation, a lookup and a write.  On most machines, it’s fewer than ten cycles.  You wouldn’t notice the impact on a computer from the 1950s.  Get over yourself.
• The simplicity of linkage and the concept of lazy linkage have no effect on application load times whatsoever.  Linkage is a purely compile-time phenomenon.  None of the things done by the C++ runtime have anything to do with module linkage, nor with “runtime linkage.”  It is important to realize that the reason C++ doesn’t call it runtime linkage is that it isn’t equivalent in any way to what the compile-time linker does; that alternative name is an artifact from languages which are completely dynamically linked, such as Smalltalk, and shows a deep confusion about the actual nature of compilation.
• C++ is just fine for lazy linkage, which is used extensively by most large C++ projects to reduce compile time.  C and C++ linkage are identical, other than C++ name decoration.  Anything the C linker can do, the C++ linker can do.  Their definitions in the standard are identical, other than name decoration rules and the ABI section that deals with passing the this pointer
• Each class with virtual methods has an associated vtable array, which adds memory overhead.
• So? 
• If you have a hundred classes with virtual methods, and each one has an average of three virtual methods, on a machine with 4-byte pointers that’s a walloping 1600 bytes.  Those vtbls are only made for virtual methods when there are multiple implementations of the method, and only when the class method or member is called through a base pointer; this overhead only exists if you’re actually using it. 
• This means that the only situation in which you could do it by hand in C in less space is on a processor like the ARM, where by switching to Thumb you could write smaller code than the compiler is inclined to generate.  Overhead doesn’t exist in a vacuum: it’s only there if you can do the same thing in C in less space.  In fact, given that in C you’re going to have to manually branch to a locally stored address, the C implementation is highly likely to end up larger.
• Besides, if you’re in an environment where 1.6K makes a difference, you’re not going to have a hundred classes, each with three virtual members.  This is a “problem” which just doesn’t occur in the real world, even in the embedded world, at any scale.
• C++’s tighter type-checking makes it difficult to write the space-conscious code reuse common to C applications (think: void *).
• What the hell?  A void pointer works in C++ exactly the same way as it does in C, with the exception that you have to make all casts explicit in code.  Given that that has exactly zero binary impact, I can’t imagine why anyone ever believed this was true.
• Even so, C++’s tighter typechecking actually means space-conscious code reuse is much easier and much more space efficient than C’s is, since you can use a single implementation and rely on stronger conversions through the OCR. 
• If you don’t know that the OCR is the One Conversion Rule, you’re not qualified to discuss typal issues in C or C++.
• The small, simple code demanded of embedded projects provides maintainability. There is no reason to assume OOP will further simplify such systems.
• Yes, C++ is bad because you don’t understand it well enough to see a benefit coming a mile away.  (cough)  This kind of hubritic nonsense even looks out of place on the internet.  Hang your head, shame-boy.
• The specific purpose of objects is to provide local simplicity and maintainability through modularity and maintained interfaces.  This is explained in the first two pages of The C++ Programming Language.  It’s obvious you haven’t read the book.  Funny how you still feel empowered to criticize something you plainly don’t understand…
• GUIs may not have a simple solution in a rigorous OOP model.
• Have you ever used an object-driven GUI system?  GUIs are the poster child for how objects can make life easier.  Essentially every GUI in existence is built on an inheritance model.  Granted, most GUIs provide a C interface because C++ linkage isn’t nearly as universal; that doesn’t mean it’s any less OO.
• Whether GUIs have a solution in an OOP model isn’t germane.
• GUIs have no better solution in C than C++.
• GUIs are rarely a concern in embedded development.  Do not confuse developing Linux applications for a small machine you hold in your hand with embedded development; embedded development means to the bare metal, without an operating system, typically in ROM.  Most embedded applications have no interface at all; they control things like your anti-lock brakes, the temperature coming out of your air conditioner and whether that key card just unlocked that door.
• There are literally dozens of GUI libraries available to C and C++.  That the language explicitly chooses not to implement them is a tip of the hat to that real embedded developers generally cannot use the kind of library that most people would want in the PC arena.  That C++ chooses to skip GUIs is in fact a huge win for embedded, not a loss.  An embedded C developer should know that, as it has the exact same win.
• This is absurdism coupled with naïvété, plain and simple.
• It’s easy to get carried away and start doing OOP for OOP’s sake. The One True Object Model may describe a problem perfectly, but it comes at the cost of excessive code.
• Yes, it’s true that bad programmers can get stuck on a near-religious devotion to a language feature.  If you’re choosing languages so that there are not useful features, to prevent your programmers from doing stupid things, you need to start hiring better programmers. 
• You might just as well suggest that C is not an acceptable language because some programmers get wholly stuck on implementing a system as a huge ball of function pointers, and that all embedded should be assembly.
• Carefully written C code can be much faster than C++ code, especially on embedded hardware. GTK+’s hand-crafted object system offers much better spatial locality than C++’s more numerous and distributed constructors. Our device has a tiny cache, so locality is an especially important performance consideration.
• There is no reason for you to suggest that C can be much faster than C++, and time and time again benchmarks prove that this is not just false, but backwards.  The C++ compiler knows more about its code than does the C compiler, and therefore can establish that some things (notably sub-const typal concerns and volatility issues are a big deal here) are safe when the C compiler wouldn’t be able to.  As a result, the C++ compiler can make more aggresive optimizations than can the C compiler.
• GTK’s hand-crafted object system exists as a legacy system to support C and ASM applications, just like Windows’.  It doesn’t offer better spatial locality than C++ GUI systems would; it uses the same malloc that GCC’s new is implemented with.  In fact, a C++ GUI can provide better spatial locality than a C GUI can, because of things like overloading operator new, which allows the reuse of code segments that C would have seperated.  On embedded machines, where ITCM caches are frequently 8-32k, that space savings can be significant.
• “C++’s more numerous and distributed constructors“
• … FUD much?  Unused constructors have 0 binary impact, and used constructors are guaranteed as small as or smaller than their C implementation counterparts.  The count thereof is unimportant, as they’re only going to be there if they’re doing things, and so in the C parallel implementation a minimum of the same count of things will be implemented.
• Distributed constructors?  In the words of Seth McFarlane, “can I buy some pot from you?”  They’re just functions.  They’re kept in the .code segment just like everything else.
• “Our device has a tiny cache, so locality is an especially important performance consideration.“
• So co-implement operator new, which will save you space on things with construction behavior.  Things without construction behavior won’t be generating any constructors anyway.

Anyway, that’s that for this particular list, but lord knows I’ve found enough other articles like this spreading misapprehension and outright falsehoods about C++.  Maybe, with time, I’ll clear up some others, too.

• 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 <body> 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 <body>, 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 <body>. 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 <body>. 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.

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.

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

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.

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!

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.