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

[CJNyfalt]

It seems that there are a general desire for changes in the z-term functionality.
So, please continue and specify, so I can see what exactly needs to be done.

As for what isometric view requires, I guess that it's a need to start update in the far corner and then do the update diagonally toward the viewpoint.

[takkaria]

It seems that there are a general desire for changes in the z-term functionality.
So, please continue and specify, so I can see what exactly needs to be done.

As for what isometric view requires, I guess that it's a need to start update in the far corner and then do the update diagonally toward the viewpoint.

Well, generally, I think you don't want z-term to exist at all for novel or new UIs; you want all the information from the game to exported though interfaces the UI can hook into easily and completely avoid the terminal layer. Hence the changes to map_info() in V to allow a display without any reference to a terminal -- it just returns monster/object/feature IDs/if the player's there/if it's at the edge of a trap-detected region/etc. See http://dev.rephial.org/trac/browser/...rc/cave.c#L836 . The majority of this kind of work has to be done outside of a variant-neutral library, mainly because different variants have different requirements and structures.

[CJNyfalt]

Well, generally, I think you don't want z-term to exist at all for novel or new UIs; you want all the information from the game to exported though interfaces the UI can hook into easily and completely avoid the terminal layer. Hence the changes to map_info() in V to allow a display without any reference to a terminal -- it just returns monster/object/feature IDs/if the player's there/if it's at the edge of a trap-detected region/etc. See http://dev.rephial.org/trac/browser/...rc/cave.c#L836 . The majority of this kind of work has to be done outside of a variant-neutral library, mainly because different variants have different requirements and structures.

So, it seems that I should concentrate on making the cave information (cave_info, cave_feat, cave_o_idx, cave_m_idx, cave_cost, cave_when) as portable as possible instead, right?

[CJNyfalt]

So, I started on creating the cave class I mentioned in the post above. Most of the interface is quite obvious, the parts that aren't obvious is how to handle cave_info. Should the class be aware of the various bit-flags or should it be a 'dumb' container?

[andrewdoull]

So, I started on creating the cave class I mentioned in the post above. Most of the interface is quite obvious, the parts that aren't obvious is how to handle cave_info. Should the class be aware of the various bit-flags or should it be a 'dumb' container?

I can't answer the class questions, but could you support separation of line of sight, and line of projection?

Andrew

[Pete Mack]

It might also be worth revisiting the menu toolkits in C++. I wrote them using function tables, which are arguably less intuitive than virtual class functions for those less familiar with old-fashioned programming.

[CJNyfalt]

It might also be worth revisiting the menu toolkits in C++. I wrote them using function tables, which are arguably less intuitive than virtual class functions for those less familiar with old-fashioned programming.

A good idea, although it will be quite some time before I reach that point.

I can't answer the class questions, but could you support separation of line of sight, and line of projection?

Yes, basic support for this will be included, because S, which I use as my master source, has separate CAVE_FIRE and CAVE_VIEW.
The problem is that converting to a common cave_info is that it will break savefile compability, at least for a few variants.
This is because some variants use a byte for cave_info, while others use u16b.
I'm not even sure if a u16b is enough, or if I should use unsigned int.

[zaimoni]

This is because some variants use a byte for cave_info, while others use u16b.
I'm not even sure if a u16b is enough, or if I should use unsigned int.

Standard policy is to use types that try to have known-size. So the question is whether you should be using u32b.

(Strictly speaking, C99 permits int to be only 16-bit, although that is expected only for 16-bit platforms)

[CJNyfalt]

Standard policy is to use types that try to have known-size. So the question is whether you should be using u32b.

(Strictly speaking, C99 permits int to be only 16-bit, although that is expected only for 16-bit platforms)

Well, yes. I guess it's time to require stdint.h.

[andrewdoull]

A good idea, although it will be quite some time before I reach that point.



Yes, basic support for this will be included, because S, which I use as my master source, has separate CAVE_FIRE and CAVE_VIEW.
The problem is that converting to a common cave_info is that it will break savefile compability, at least for a few variants.
This is because some variants use a byte for cave_info, while others use u16b.
I'm not even sure if a u16b is enough, or if I should use unsigned int.

I separated out player dependent flags from cave dependent flags in Unangband which allowed me to have enough flags for each set, with a byte for each. This design allows you to potentially support multiplayer *bands at some point in the future.

/*
* Special cave grid flags
*/
#define CAVE_GLOW 0x01 /* self-illuminating */
#define CAVE_ROOM 0x02 /* part of a room */
#define CAVE_DLIT 0x04 /* lit by daylight during daytime */
#define CAVE_HALO 0x08 /* lit by glowing feature */
#define CAVE_TLIT 0x10 /* lit by a monster or player */
#define CAVE_CLIM 0x20 /* location is 'climable' */
#define CAVE_XLOF 0x40 /* blocks line of fire */
#define CAVE_XLOS 0x80 /* blocks line of sight */

/* Cave lit by any form of light - except player torch */
#define CAVE_LITE (CAVE_GLOW | CAVE_DLIT | CAVE_TLIT | CAVE_HALO)

/*
* Special player grid flags
*/
#define PLAY_MARK 0x01 /* memorized feature */
#define PLAY_SAFE 0x02 /* detected as safe */
#define PLAY_MAGI 0x04 /* magical effect */
#define PLAY_LITE 0x08 /* lit by the player */
#define PLAY_SEEN 0x10 /* seen flag */
#define PLAY_TEMP 0x20 /* temp flag */
#define PLAY_VIEW 0x40 /* view flag */
#define PLAY_FIRE 0x80 /* fire flag */


Andrew

[CJNyfalt]

I separated out player dependent flags from cave dependent flags in Unangband which allowed me to have enough flags for each set, with a byte for each. This design allows you to potentially support multiplayer *bands at some point in the future.

Good idea. I think it's best I reserve an unsigned short for each.

[buzzkill]

WOW! For the most part, I have no idea what you guys are talking about, but I still find it interesting.