JBand progress log.

**Pete Mack** · May 27, 2009, 08:05

Please don't use stl stuff unless you really have to.... That stuff can be surprisingly unportable, and it can also lead to really huge amounts of object code for a tiny bit of source. (C++ got templates wrong. Java 7 and C# get them much more right.)

Also beware UTF-16: Microsoft handles it well. *NIX handles it poorly. (wchar_t is 32 bits on most *NIXes.)

**PaulBlay** · May 27, 2009, 09:09

Originally posted by Pete Mack

Please don't use stl stuff unless you really have to.... That stuff can be surprisingly unportable, and it can also lead to really huge amounts of object code for a tiny bit of source. (C++ got templates wrong. Java 7 and C# get them much more right.)

#include <shlwapi.h> is now gone.

I think I'll leave worrying about UTF-16 with *nix until I need to. It will doubtless take a long time to translate all the text so I'll have plenty of opportunity to play catch up then.

Splash screen now displays correctly

Files in /edit subdirectory are now in UTF-16.

Now reaches monster array initialization before crashing.

Reading UTF-8 files now works, so switched back from UTF-16

**PaulBlay** · May 28, 2009, 11:17

I've been sneakily adding progress updates to my previous post because it would be over the top to have more than one post per day.

I've now gone back to UTF-8 and got it working as well with UTF-8 as it was with UTF-16. Which isn't saying much.

Separate file modes added for binary read and binary write.

I've decided that I've made enough progress(?) to see if I can find anybody who wants to take an active part in the development process. PM or post if you are interested. Openings for all levels of experience ;-) (Don't feel guilty if you're to busy with your own stuff - I know exactly how that is.)

I suspect I may have more luck with the Japanese developers at SourceForge.JP so I will also be soliciting help there.

Implemented changeset 1415 from Vanilla Angband.

Lots of variable type tweaking.

**Rizwan** · June 4, 2009, 08:27

Originally posted by PaulBlay

I've decided that I've made enough progress(?) to see if I can find anybody who wants to take an active part in the development process. PM or post if you are interested. Openings for all levels of experience ;-) (Don't feel guilty if you're to busy with your own stuff - I know exactly how that is.)
I suspect I may have more luck with the Japanese developers at SourceForge.JP so I will also be soliciting help there.

I would love to help and learn at the same time. Don't know Japanese, medium programming experience C/C++, busy with RL for the next couple of weeks.

**PaulBlay** · June 4, 2009, 10:13

Originally posted by Rizwan

Don't know Japanese, medium programming experience C/C++, busy with RL for the next couple of weeks.

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.

**artanis** · June 12, 2009, 06:45

I think this thread is a little more on topic for this post.

I changed a few of the L"" to _T() as I was fixing the nmake build. I figured I had gotten all of them once it compiled successfully but I see that that was a silly assumption!

The nmake build is working now. The "clean" build target doesn't work because del doesn't seem to like / in paths. UNICODE is not defined in the makefile, but it will build both with and without it at this point.

I didn't commit the change that fixes the first crash bug. Commenting out the 3 FREE calls around init2.c:520 works well enough. I did commit a change to z-file in the file_put function that fixes the next crash bug.

Maybe I'll really go to sleep now

**PaulBlay** · June 12, 2009, 06:57

Originally posted by artanis

I changed a few of the L"" to _T() as I was fixing the nmake build. I figured I had gotten all of them once it compiled successfully but I see that that was a silly assumption!

I prefer __T() as it is easier to find and replace if necessary. (At least in VC++ _T(x) is just defined as __T(x)).

I didn't commit the change that fixes the first crash bug. Commenting out the 3 FREE calls around init2.c:520 works well enough. I did commit a change to z-file in the file_put function that fixes the next crash bug.

Maybe I'll really go to sleep now

I'll see you when you wake up then.

**Pete Mack** · June 12, 2009, 07:47

Don't bother with NMAKE -- it's a crappy imitation of the real thing. If you can get it to work in Visual Studio, getting it to work in a real make file should not be hard.

**PaulBlay** · June 12, 2009, 11:15

I didn't commit the change that fixes the first crash bug. Commenting out the 3 FREE calls around init2.c:520 works well enough. I did commit a change to z-file in the file_put function that fixes the next crash bug.

I'll see you when you wake up then.

OK I obviously hadn't woken up earlier.

It looks like those FREE calls just needed to be included in the #if NO_RAW section. I'll commit that change now.

[EDIT] Progress update - with help from artanis we can now get as far as "File -> New" before it stops working (with an endless loop)

**PaulBlay** · June 12, 2009, 16:55

OK, various crashes have been fixed - and you can now wander around and kill things in town. Unfortunately it crashes if you get killed in town - the savefile functions are broken.

**Pete Mack** · June 12, 2009, 17:00

Have fun. There are not many things more unpleasant than mucking around with save file format.

**PaulBlay** · June 12, 2009, 18:28

Originally posted by Pete Mack

Have fun. There are not many things more unpleasant than mucking around with save file format.

Yeah, it doesn't help that nearly all the char stuff is now wchar_t so assumptions everwhere that one character == one byte are broken.

The current crash is caused by this bug.

In savefile.c a file handle is mysteriously evaporating during this line of code.

Code:

243:   /* 16 character block name */
244:   ret = _tcscpy_s((_TCHAR *)savefile_head, sizeof(savefile_head), 
245:          savefile_blocks[i].name);

I presume I have overrun some memory somewhere...

[EDIT] Maybe it needs to be

Code:

	ret = _tcscpy_s((_TCHAR *)savefile_head, sizeof(savefile_head) / sizeof(_TCHAR), 
			savefile_blocks[i].name);

because I'm messing around with mixed single and double-byte variables (ick).

[EDITx2] Yup, that was it.

**PaulBlay** · June 13, 2009, 15:35

Another day, another bug.

The latest problem I've been looking at is that all about the keyboard.

Specifically:
with numlock on -
* Numpad numerals work to move.
* Shift+number does not run.

with numlock off -
* Numpad numerals do not work.
* Shift+number works to run.

That suggest anything to anybody?

[EDIT] Progress to date on this bug ... you can now move diagonally but not orthogonally with the numlock key off.

**PaulBlay** · June 15, 2009, 13:36

Howdy folks (er, anybody?

)

Today's nasty realization is that I should probably add a L or put a __T( ) around every literal character constant in the code (all 72 bazillion of them). Character constants like '\x8D' are interpreted as negative numbers (-115) but the wide character equivalents are positive numbers (141). This difference is what caused the arrow keys to not be recognized.

I expect there are a lot of other bugs also relating to this problem, but have not yet nailed them down.

[EDIT] It's slow work debugging this code, but I'm making progress. Back tomorrow.