libband - trying again to make a common code library for *bands

[CJNyfalt]

A common library of functions & objects for all *band variants to share.

This is an idea that just won't die for me. I have had it in several years and have already made two tries before. Once I starts to do any programming at all it rears its ugly head and disturbs my peace of mind.

So why do I feel so strongly the need for it?
1. The angband codebase is poorly modularized, moving stuff to a separate library would improve modularization.
2. The annoyance to have to implement UI patches for the same change for multiple variants. Having a single shared library would allow for less work.
It's especially annoying when having grown accustomed with a good UI feature in one variant, to try out another one where it's missing.

So, I started coding last week. Picked Sang, Oang, Steam, Ey and Pos for base variants. Would also have picked sCth if I could get it to work. Sang was a must because it's the only variant where I know which parts of the code are under GPL and which parts aren't. Un, FA, NPP and Anime I'm also interested in, but I don't like having to keep-up-with-the-Andrews.

Another thing I haven't yet mentioned is the migration of the code to C++.
The tools available in C++ to make the codebase smaller, especially strings, I don't want to be without.

One thing I need to state clearly. I'm creating the library for my own benefit. If you want to use it that's fine, and so much better. But, I'm not going to spend time worrying about marketing it. I'm posting about it because there's always something to gain from getting another point of view.

What have I done so far?
- An inscriptions class (called quark package for some reason in *bands.)
- A keymaps class.
Yes, these are simple stuff, but moving them to the library means that their implementation are separated from their interface. Another gain is that there's no longer any need to worry about memory management.
I might in future posts describe the classes more in detail.

As for future plans, the macro package is probably next. After that I plan to take a look a colors, visuals and the "cave" itself.

[CJNyfalt]

Here's an example class adapted from the "quarks" package.

#ifndef INCLUDED_INSCRIPTIONS_H
#define INCLUDED_INSCRIPTIONS_H

#include <string>
#include <vector>

/*
 * The inscriptions package
 *
 * This package is used to reduce the memory usage of object inscriptions.
 *
 * We use STL containers because otherwise it is necessary to
 * pre-guess the amount of inscription activity.
 *
 * Two objects with the same inscription will have the same index.
 *
 * Some code uses "zero" to indicate the non-existence of an inscriptions.
 *
 * Note that "inscription zero" is an empty string.
 *
 * ToDo: Add reference counting for quarks, so that unused quarks can
 * be overwritten.
 * - Might be solvable by using iterators instead of indexes?
 */

class Inscriptions {

public:
    Inscriptions(void);

    short add(std::string str);
    std::string get_str(short i);

private:

    static const short hard_max_ = 4096; // Roof, we don't allow more than this
    static const short reserve_step_ = 128; // Reserve step size.
    // Note that hard_max_/reserve_step_ should be a positive integer

    short max_; // Currently reserved maximum
    short number_; // Number in use
    std::vector<std::string> strings_;
};

#endif // INCLUDED_INSCRIPTIONS_H

So, what do we gain here?
- Use of strings and vector means that we don't have to do explicit memory management.
- We can start out by reserving less space for inscriptions, but also allow the space reserved for inscriptions to grow if needed.

As for the note about reference counting, it seems to me like extra work for very little gain.

In other news, I have just finished the macros class, but haven't tested it yet.

[konijn_]

So, I started coding last week. Picked Sang, Oang, Steam, Ey and Pos for base variants. Would also have picked sCth if I could get it to work. Sang was a must because it's the only variant where I know which parts of the code are under GPL and which parts aren't. Un, FA, NPP and Anime I'm also interested in, but I don't like having to keep-up-with-the-Andrews.

FYI : Hellband is the offspring of SCth, you can get it to work.

T.

[CJNyfalt]

FYI : Hellband is the offspring of SCth, you can get it to work.

T.

Hellband is interesting and I can get it to work, but sadly it's the skill system in sCth that I really want to study.


About the library itself, I have now tested out the macros class, and have to decide what to do next.

[Narvius]

and have to decide what to do next.

Choice/Browse menues for spells, FA-style.

[CJNyfalt]

Choice/Browse menues for spells, FA-style.

Good suggestion, I wrote it down. However, I want to get the low-level stuff right before I move on to the UI, so that one is saved for later.

As for sCth I finally managed to get it running, but it still seems to be crashing on certain actions.

What I will work on next in the library is probably either the text_to_ascii function or the path stuff.

[Narvius]

Well, then.
Uh...
Object/Monster knowledge browsers?
Basically the whole Knowledge menu.
That's not really UI, I guess, but probably a bit massive. I don't know...

[CJNyfalt]

Well, the knowledge menus are an interesting and illustrative topic, glad you took it up. Let's take a look at some points:

• They're something that there's been several variants of. Because of this they are a good candidate for the library, so variants always have access to the best variant.
• It also touches stuff that are best left to the individual variants - the monster & object data structures. Things could be tricky to separate so the menus don't have to know about how the data is stored. It's probably doable though, have to study it more.
• While I don't want to tell the variants where to put things on the main screen, these kind of separate menu screens are things that sure could have a common layout.
• I need to do z-term before I start working on some code that puts text on the screen. z-term is something I have waited with to do, because here's when things starts to get a little controversial. Things like mouse, Latin-1, Japanese or handheld support are stuff that varies between variants. Questions about what to support comes up and things becomes political. For example the latin-1 support in FA/S/NPP and the Japanese support in Heng/Entro are things that's improves the variant, but I'm not happy with how they're implemented. Going for Unicode would have been a better choice.

[zaimoni]

When released, Zaiband 3.0.10 alpha will have messed with the z-term module (there were conceptual issues I finally got around to).

[Pete Mack]

The knowledge menus (and menus in general) _are_ already toolkit-ized on V, Un and FA. IMHO. Nick has done buttons on FA (and somewhat V) as well.

[Bandobras]

The Un version is older, but extended with 'start at a given item', though not fully. A common and newest version in a separate file would be nice, ideed. OTOH, I don't know what's the cost of having a C++ file among the source, beside aesthetics (C++ is _ugly_). Changes in code? Changes in makefiles? Is C++ supported on all handhelds? On RISC OS? Anything else?

[Pete Mack]

I'm not a big fan of C++ for some things--I think the STL is overkill. But it is supported on all platforms. GCC is the same program as g++. The same holds for cl.exe.

Finally, I suspect angband is a sufficiently small program that it will fit on handheld even if it's bloated with STL. That said,I don't see a huge benefit to this particular toolkitization. The big issue is cleaning up display stuff: Z-term is not abstracted at the right level. And the event model used for causing refrshes is a little primitive.

Memory management for strings (quarks) is just not that big a deal, whether done with STL or not.

[CJNyfalt]

So, C++ is supported everywhere? Good, that means we can avoid that flamewar.

As for specific issues I have with the way recent *band development have taken, is the design compromise cost of handheld support and the ugly mouse stuff cluttering up valuable screen real-estate.

For cutting edge stuff from FA and Ey I'm waiting as long as possible, because I don't want to have to struggle keeping up with a variant under active development. It would of course be another story if active maintainers joined up.

[andrewdoull]

I'm not a big fan of C++ for some things--I think the STL is overkill. But it is supported on all platforms. GCC is the same program as g++. The same holds for cl.exe.

Finally, I suspect angband is a sufficiently small program that it will fit on handheld even if it's bloated with STL. That said,I don't see a huge benefit to this particular toolkitization. The big issue is cleaning up display stuff: Z-term is not abstracted at the right level. And the event model used for causing refrshes is a little primitive.

A good test case would be to implement a refresh model that supports standard overhead view, as well as isometric displays. If you can do that, you've got me interested.

Andrew

[takkaria]

A good test case would be to implement a refresh model that supports standard overhead view, as well as isometric displays. If you can do that, you've got me interested.

Andrew

V has started to implement one of these. It has an event system where various kinds of updates get triggered by firing update events rather than tweaking flags. There's also a function which returns information about a given grid position in a structure, such that it might be suitable for isometric or graphic display. (http://dev.rephial.org/trac/browser/.../types.h#L1065) The idea is eventually to provide the terminal-based frontend as just one choice, and to make it easier to implement isometric or handheld ports which don't necessarily want a rectangular grid of text as their basis.