Angband.oook.cz
Angband.oook.cz
AboutDownloadVariantsLadderForumCompetitionSpoilersComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old September 24, 2008, 10:44   #1
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
libband - trying again to make a common code library for *bands

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 is offline   Reply With Quote
Old September 24, 2008, 18:08   #2
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Here's an example class adapted from the "quarks" package.

Code:
#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.
CJNyfalt is offline   Reply With Quote
Old September 24, 2008, 19:43   #3
konijn_
Hellband maintainer
 
konijn_'s Avatar
 
Join Date: Jul 2007
Location: New York, the Big Apple
Age: 37
Posts: 346
Donated: $120
konijn_ is on a distinguished road
Thumbs up

Quote:
Originally Posted by CJNyfalt View Post
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.
__________________
* Are you ready for something else ? Hellband 0.8.7 is out! *
konijn_ is offline   Reply With Quote
Old September 25, 2008, 12:10   #4
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Quote:
Originally Posted by konijn_ View Post
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.
CJNyfalt is offline   Reply With Quote
Old September 25, 2008, 15:30   #5
Narvius
Knight
 
Narvius's Avatar
 
Join Date: Dec 2007
Location: Poland, Katowice
Age: 22
Posts: 586
Narvius is on a distinguished road
Quote:
Originally Posted by CJNyfalt View Post
and have to decide what to do next.
Choice/Browse menues for spells, FA-style.
__________________
If you can convincingly pretend you're crazy, you probably are.
Narvius is offline   Reply With Quote
Old September 25, 2008, 18:34   #6
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
Quote:
Originally Posted by Narvius View Post
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.
CJNyfalt is offline   Reply With Quote
Old September 25, 2008, 18:46   #7
Narvius
Knight
 
Narvius's Avatar
 
Join Date: Dec 2007
Location: Poland, Katowice
Age: 22
Posts: 586
Narvius is on a distinguished road
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...
__________________
If you can convincingly pretend you're crazy, you probably are.

Last edited by Narvius; September 25, 2008 at 19:04.
Narvius is offline   Reply With Quote
Old September 25, 2008, 19:44   #8
CJNyfalt
Swordsman
 
Join Date: May 2007
Posts: 289
CJNyfalt is on a distinguished road
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.
CJNyfalt is offline   Reply With Quote
Old September 25, 2008, 19:59   #9
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
When released, Zaiband 3.0.10 alpha will have messed with the z-term module (there were conceptual issues I finally got around to).
zaimoni is offline   Reply With Quote
Old September 25, 2008, 20:35   #10
Pete Mack
Veteran
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 2,399
Donated: $40
Pete Mack is on a distinguished road
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.
Pete Mack is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Graphical ideas for *bands Leon Marrick Vanilla 26 January 4, 2011 10:01
Trying to make my own variant bpleshek Variants 8 September 15, 2008 21:42
How To: Make permanent walls purple for easier vault clearing Zero Vanilla 4 August 6, 2008 22:13
[Feature Request] Make 'repeat last command' only repeat in-game commands CunningGabe Vanilla 7 March 22, 2008 21:13
Looking through the code K.I.L.E.R Vanilla 5 July 11, 2007 09:01


All times are GMT +1. The time now is 14:13.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.