Variant Tcl+TK Fusion?

[Nick]

What does keep me awake at night is issues affecting portability that I can't control or plan for, like the stack size limit on the Nintendo DS.

That's not such a big drama (easy for me to say - it wasn't me that worked out how to deal with it). The main effect it had was that memory allocation had to be tidied up a bit (chiefly in the help display), which is a good thing. IIRC this has been done in V; it certainly has in FA.

[darke]

Surely unangband is C99-compliant (not C89) these days?

Angband itself is fine, the main issue is that the compilers aren't quite C99 complaint a decade after the '99 standard was ratified, so actually trying to use the features is a potshot. Last time I tried Visual Studio's C implementation was still missing things like <stdbool.h> for instance. GCC is actually pretty close to being compliant, but it's variable length arrays are still broken. Cormau most likely has a perfectly conforming implementation, though that's probably to be expected since I believe they're still the only compiler that supports the C++ "export" keyword properly...

But this is more of a whine for a C/C++ usenet group.

Don't be so sure. The only reason it seems to get press is because the SVN is easily accessible and seems to attract programmers like flies... there are plenty of other variants that are popular and well-supported.

You're discounting the fact that the design decisions and thoughts on Un are pretty well blogged. I only wandered in because I was looking for some decent methods of generating dungeons for an AD&D Dungeon Hack clone I was hacking together after reading your blog posts. (Then I got distracted bug stomping of course, but I seem to have leveled up my "Easily Distracted" skill early in my youth.)

@Darke,
would you say that your coding for that 3d engine could be turned into a usable abstraction layer?

It would be possible, but essentially the abstraction layer is a very simple, domain specific GUI library interface. The way I'm currently doing it is pretty much the laziest way possible at the moment since I've got the flexibility on the 3d side of things to build the gui as I want (and the fact I'm throwing it together as a quick hack means I don't need to think hard about any potential problems associated with it). If I were hooking it into something like wxwindows, or Tk, or even a platform specific library like MFC, you'll have a lot more restrictions placed on you as to what you can do.

Plus the way I've been doing it is terribly, terribly ugly with #ifdefs and other things floating around the place. Plus it really should be getting the gui positions out of another file, rather then calculating them from the normal place in a terminal. Plus... there's a bunch more problems as well, but this was a useful enough proof of concept to shake out some of the the problems needing a solution.

If we could have a simple method to say, hook a plugin into the code and serve that plugin with the simple facts of what's currently going on ingame, then we could blow open the pathway for user created GUI's. Plus, this could then be offered to the angband team as a standard. (Standardisation seems to be the bane of open source stuff these days, such a shame as without it nothing is ever easy to make cross-platform)

The main issue is that standardisation is incredibly expensive in comparison to writing something that's domain specific so you only do it if you expect to get a significant benefit back. It's also much harder to conceptualise, generates much more code (so it's harder to debug and takes longer to write), forces you to keep working with it once it's created (so a worse solution might be picked over a better one) and might end up being a complete waste of time anyway because another platform/library/whatever comes along which you can't map your standard to.

It's not that standardisation is a bad thing, it's just your usual cost/benefits trade off.

And depending on whether #ifdefs or conditionals are used, what is the chance of either forms of stat abstraction not having to be changed when its time for the next build of Unangband to come out?

Currently I've got it so like the term layer, it has no idea of Un's internals. The labels for stats for example just take a set of (GuiName, Caption, Value, Colour, X, Y) values. My code searches to find if it's already created a "GuiName" gui-element, if it has it sets the caption/value/etc and shows it, otherwise it goes through the effort of building the gui-element, then sets all the values.

So for example, if someone decides to add a "Hobbit Kill Count" statistic for the number of random innocent hobbits killed in town, all they'd need to do was call the same function with "HobbitKill" as the GuiName, and the appropriate values and things would Just Work(tm).

Of course having it play a "Mo-mo-mo-monster Kill!" sound after you've killed a few too many in quick succession would be a value-added feature inside the 3d verison (or whatever) and not have an external gui_ handler function.