JBand progress log.

[PaulBlay]

Today's progress report (so far).

Crashes when trying to display graphical tiles. Appears to be a problem with reading the bitmap info header.

[EDIT] Fixed that one.
[EDITx2] Spoke too soon.
[EDITx3] Seriously considering dumping ReadDIB() entirely and attempting to replace it with LoadImage() (or similar function).

[EDITx4] Hot-diggity! It worked.
Dumped ReadDIB and used LoadImage code from MS example. (So I get to say "Thanks Microsoft" for once). The terms of use may be problematical, but it was given as an example of how to use the Microsoft API so I don't suppose I'll be getting any annoyed emails from them.

[PaulBlay]

OK, today's progress report so far:

- Caught up to Vanilla Angband r1452.

- Er, that's about it.

Incidentally I'm currently ranked 8th most active* developer at SourceForge.JP and JBand is ranked 26th most active project.

* Luckily there is no ranking to measure skill.

[PaulBlay]

Progress report:

JBand is now 100% C++ code. Er, OK, it's 99.9% C code, but all the .c files are now .cpp

Tips on what I might do to make it more object oriented, what functions should be overloaded, etc. would be welcome. (As one of my objectives of the project is to "learn C++")

[takkaria]

Progress report:

JBand is now 100% C++ code. Er, OK, it's 99.9% C code, but all the .c files are now .cpp

Tips on what I might do to make it more object oriented, what functions should be overloaded, etc. would be welcome. (As one of my objectives of the project is to "learn C++")

Starting with Angband and learning C++ by moving bits of Angband into C++ won't give you good C++ coding practice...

[zaimoni]

Progress report:

JBand is now 100% C++ code. Er, OK, it's 99.9% C code, but all the .c files are now .cpp

Zaiband proceeded by leaving the files .c and handing g++ an option to force C++ compilation.

Tips on what I might do to make it more object oriented, what functions should be overloaded, etc. would be welcome. (As one of my objectives of the project is to "learn C++")

Or at least C++ for POD-types. One thing that is not terribly obvious until you try, is that it is very difficult to make proper classes interact well with savefiles.

Zaiband's first steps were:
* review the function-like macros in defines.h . Most of these have only one parameter of interest, so they should be inline member functions of the struct they are relevant for. [Yes, in C++ structs can have non-virtual member functions and remain safe for C memory management.] A few others should be inline functions; the only reason not to convert these to inline functions in V is C89 support.
* Review global variables and determine which ones should relocated. For Zaiband, this means: player inventory now a member of player_type (change needed to prepare for TeamBand features), and more than a few kind globals converted to be static members of their corresponding types. Ditto for name and text globals.

If I were doing it over again, the next stage would be:

template<class T> struct _grid {T x; T y; ...};

typedef _grid<unsigned char> coord;
typedef _grid<signed char> coord_delta;
typedef _grid<signed int> coord_scan;

typedef bool coord_action(coord g); ...

(The relevant type definition and non-member functions are in Zaiband's types2.h).

Regression-test very carefully when converting the interfaces, types, and reference tables to use coord/coord_delta/coord_scan . I was able to get everything except dungeon generation.

This enables making player_type and monster_type derived structs starting with what little data they have in common. Zaiband currently uses

struct agent_type
{
	coord loc;			/**< location on map */
	s16b chp;			/**< Current Hit points */
	s16b mhp;			/**< Max Hit points */
	byte speed;			/**< "speed" */
	byte energy;		/**< "energy" */

	....
};

(Full details in types.h, but the omitted member functions support the AI changes. Yes, the monsters get a player health bar now....)

The other new type that is needed is:

struct tvalsval
{
	byte tval;	/**< object type */
	byte sval;	/**< object sub-type */

	void clear() {tval = 0; sval = 0;};
};

inline bool operator==(const tvalsval LHS, const tvalsval RHS) {return LHS.tval==RHS.tval && LHS.sval==RHS.sval;}
inline bool operator!=(const tvalsval LHS, const tvalsval RHS) {return !(LHS==RHS);}

This struct isn't needed in V because the main benefit is from operator== and operator!=, neither of which can be defined in C.

In general, if there is any chance that == makes sense then provide operator== and operator!=. The clear() member function is an STL-ism, but Zaiband actually uses it.

There are a number of other member functions of player_type, monster_type, and object_type in Zaiband's types.h. Most of these were chosen to reduce overall source code size.

Generally, any function that has only one struct parameter is a legitimate candidate for conversion to a member function -- but keeping the interface small is also a good goal, and as long as everything is C-compatible structs it is probably better to use a static C function than a member function when the call graph allows using a static C function.

[PaulBlay]

Or at least C++ for POD-types. One thing that is not terribly obvious until you try, is that it is very difficult to make proper classes interact well with savefiles.

By going to Unicode (not to mention Japanese) I have pretty much broken any hopes of save file compatibility with standard Vanilla Angband so I might well end up re-writing that bit from scratch.

Thanks a lot for your other comments, which I shall be reading through carefully tomorrow.

[PaulBlay]

Today's progress report.

* First draft translation of attack.cpp is complete!

* I need to support stuff like %2$s in formatted strings (for variable order parameters).

[Rizwan]

Would that RL be "Real Life" or "RogueLike" ? ;-)

Either way I would love to hear from you in ~ two weeks time, whenever you're free. In the meantime I shall continue evaluating (struggling with) the various multi-platform GUI libraries available.

Ok what can I do to help?

[PaulBlay]

Ok what can I do to help?

Great to hear from you. I'm concentrating on the translation at the moment (that involves code work too so it's a bit fiddly).

There are a number of bugs and it would be wonderful if you could sign up to SourceForge.JP and fix any of them. Including this weird one that has me baffled.

You don't need to know Japanese for any of this (as you'll probably be glad to know ;-).