DJA: Tossing around ideas

[will_asher]

good news and bad news
good news: all 5 of the changes I was working on mentioned in the previous message are finished along with some other cool stuff. 3.2.0 is pretty much ready to release if it weren't for the bad news.
bad news: There's a new between-version crash bug (or maybe two) which I'm having a very hard time tracking down and I don't want to release 3.2.0 until they're fixed.
I used VisualC++ for awhile, but then I had to move all my DAJ stuff to a different computer and I couldn't get VisualC++ to work on the other computer. So I'm back to using DEV-C++. VisualC++ was better at tracking down bugs. plog doesn't seem to be helping in this case.

EDIT: old message, but of course I meant 1.3.0 not 3.2.0

[will_asher]

I'm very glad I based my variant on 3.0.9 because the newer V code seems a lot harder to understand for a beginner like me. I'm trying to import caverns from V into DaJAngband. Now that the code is like this, it's going to be a lot more trouble for me to import features from new V.

PS: how do you search all code files for something on github?

[will_asher]

Well I've copied the cavern generation code and mostly translated it so it should work in DaJAngband. (I had to take queue.c and queue.h from the new V code.) I've got it so I only get one error message, but I get that message several times.

In six places in the new code, at the declaration of a variable like "int deleted[size];" below, I get an error saying "error: expression must have a constant value," and it underlines 'size'. Can anyone help me with fixing this?

void clear_small_regions(int dhei, int dwid, int colors[], int counts[]) 
{
	int i;
	int size = dhei * dwid;

	int deleted[size];
...

EDIT: this is the equivelent piece in the original V code

void clear_small_regions(struct cave *c, int colors[], int counts[]) {
	int i;
	int h = c->height;
	int w = c->width;
	int size = h * w;

	int deleted[size];
...

EDIT: a compiler warning:
'function' : 'int' differs in levels of indirection from 'int[]'
=a meaningless sentence. I'd be nice if the compiler warnings would actually say what was wrong. (although I can tell from this that there's apparently a difference between an int declared with [] and an int declared without [], the wording is horrible, and it doesn't help me see how to fix it.)

[PowerDiver]

The error is because when you declare a variable, the compiler needs to know how much space to allot every time the function is called. If the array has a variable size, the compiler cannot figure out how much space to set aside at compile time. It is possible for it to be allocated at runtime, but that is trickier, so in the old days it was not allowed.

Clearly the standards have changed since the ancient times when I learned C. You need to look at the current V makefile to see what arguments are being passed to the compiler. One of those must say to use a standard that allows that particular declaration.

Presumably some youngster reading these boards can give you better info about all this.

[will_asher]

Going from what you said, I looked at the makefile on github, thinking that I didn't really know what I was looking for (or at least I didn't know what what-I-was-looking-for looked like).
But as I'm looking, I suspect it might be in this line:

CFLAGS += -DBUILD_ID=${VERSION} -I. -std=c99 -Wdeclaration-after-statement -O0

would it be the "-Wdeclaration-after-statement" thing? Maybe I'll try putting that in my Visual studio project.

[Derakon]

It might also be the -c99, which, unless I'm gravely mistaken, says to use the 1999 specification for C, which could have loosened things enough to allow declaration of variables with unknown size. I'm more inclined to believe that since -W flags simply warn you when you're doing things you might not want to do; they shouldn't stop compilation unless you're also set to make all warnings be errors.

[will_asher]

I tried adding "/Wdeclaration-after-statement" in the command line (that's where I'm supposed to add this kind of thing right?), and it said it was an invalid argument.

I tried adding "/std=c99" in the command line and it created a bunch of error messages saying
Error 1 error C1083: Cannot open include file: 'pwd.h': No such file or directory c:\users\public\games\djadev\cutedgedja-2\src\h-basic.h 148
which point to h-basic.h
So I got rid of the "/std=c99" but the error messages didn't go away. HELP Why didn't the error messages go away when I got rid of the argument that started them? I hadn't changed anything else. I can't compile now.

[zaimoni]

In six places in the new code, at the declaration of a variable like "int deleted[size];" below, I get an error saying "error: expression must have a constant value," and it underlines 'size'. Can anyone help me with fixing this?

void clear_small_regions(int dhei, int dwid, int colors[], int counts[]) 
{
	int i;
	int size = dhei * dwid;

	int deleted[size];
...

This code by definition will not compile on MSVC10-: no support for parsing C99 variable-length arrays. There is no option to compile C99; the target standard is C90, with a few C99 extensions like long long.

You'll have to use dynamic memory allocation to make this work on MSVC. [z-virt.h, here we come!]

Shouldn't creating a new project, keeping the C source but not the project files or object files, revive the project?

EDIT: I knew takkaria had intentionally dropped MSVC as a supported compiler with the directory restructuring, but this means reversing the file reorganization won't repair the V build.

[PowerDiver]

I tried adding "/Wdeclaration-after-statement" in the command line (that's where I'm supposed to add this kind of thing right?), and it said it was an invalid argument.

I tried adding "/std=c99" in the command line and it created a bunch of error messages saying
Error 1 error C1083: Cannot open include file: 'pwd.h': No such file or directory c:\users\public\games\djadev\cutedgedja-2\src\h-basic.h 148
which point to h-basic.h
So I got rid of the "/std=c99" but the error messages didn't go away. HELP Why didn't the error messages go away when I got rid of the argument that started them? I hadn't changed anything else. I can't compile now.

I know nothing of compiling under windows, but here are a couple of ideas.

(1) Try
make clean
Perhaps some intermediate object has been produced and it is getting in the way. Of course, I don't even know if your makefile has a rule for clean.

(2) Makefiles can be very picky. In particular, you cannot replace a TAB with spaces that visibly look identical. Perhaps you have made a change and didn't notice it.

------------

To fix the code you copied, you should declare that variable as

int deleted[MAX_DUNGEON_HEIGHT * MAX_DUNGEON_WIDTH];

or whatever those constants are. That will screw up the code if there are any uses of N_ELEMENTS(deleted) or sizeof(deleted), but hopefully all of the loops reference the size variable used in the current definition.

That's a bit wasteful, but no big deal, and you really don't want to be messing with dynamic allocation issues.

[edit] If you make the code change above, you should also assert that the array is big enough.

assert(size <= MAX_DUNGEON_HEIGHT * MAX_DUNGEON_WIDTH);

[will_asher]

I got it to compile again by starting a new project. No more messing with the command line for me unless I have exact intructions.

in cavern_gen(), there is this piece:

	int dhei = randint(DUNGEON_HGT / 2) + DUNGEON_HGT / 2;
	int dwid = randint((DUNGEON_WID*2) / 3) + DUNGEON_WID / 3;

That's the reason I passed dhei and dwid to the cavern code functions instead of using DUNGEON_HGT and DUNGEON_WID.
Would it work if I #define CAVERN_HGT and CAVERN_WID as something like 3/4 * DUNGEON_HGT and DUNGEON_WID.

Then that variable declaration would be

int deleted[CAVERN_HGT * CAVERN_WID];

[PowerDiver]

Don't mess around. There may be changes later. Perhaps 3/4 will turn into 7/8 in some future release. Missing a +/- 1 due to how rounding works can lead to inscrutable bugs. It is just space used on the stack until the function exits, and there isn't any good reason to optimize that if it risks another bug down the road.

Leave the rest as you copied it, including however the size variable is computed, and don't forget to add the assert.

[will_asher]

Okay, thanks! I got caverns working now.
I didn't realize that was just space set aside for that function, I was thinking the numbers had to be exact (so I thought I'd have to remove the variable size of the caverns).

EDIT: yes, I'm pretty clueless about programming. It's a wonder I have my own variant at all.

EDIT: now I want to figure out how to have a level that's mostly cavern, but have a couple normal rooms.

[will_asher]

Update:
As I'm testing caverns in DAJ, I noticed that monsters pathfinding seems confused by the different shape of the dungeon. Sometimes they can't find their way to you even if they're on the other side of one wall with an opening four spaces away.
Was monster pathfinding changed in V to fix this or is this problem specific to DAJ?

[Derakon]

V's pathfinding is pretty stupid. It may be that the cavern map type simply produces the concavities needed to confuse it more often than the standard maps do.

[d_m]

Myshkin just pointed me to this thread.

Sorry for using variably-sized arrays and causing you some trouble. I will try to rewrite that so it can work on MSVC.

That said, we have committed to using stdint.h in Angband (to rationalize some existing places where pointers and ints are used interchangeably in an unsafe way). It looks like MSVC either supports stdint.h or has a header file you can grab that defines it so hopefully that won't cause other problems.

As far as pathfinding, I think Derakon is right... V's pathfinding is mostly bad, and not well-tested on destroyed/cavern areas. I'd like to find some time to fix this, although patches are welcome!