Problems compiling with Visual Studio on Windows

[adrido]

hi, finally I was successful compiling minetestmapper on Windows with Visual Studio. I could not use the CMakeLists.txt, because after solving all errors Cmake produced unreadable rubbish (but thats another issue). Manually creating a project file and including all required library throw some errors, but I could solve that except of one:

In mapper.cpp lines 793-800 https://github.com/Rogier-5/minetest-mapper-cpp/blob/master/mapper.cpp#L793-L800 you are using the function strcasecmp. In witch library can I find that function?

To continue I commented that lines out, and I was able to create the minetestmapper.exe file. Everything works fine, except the drawscale argument. :smile: But I have another issue I could not solve up to now:

If I try to create a map the progressing mapblocks only goes to ~63%. Than the debugger prints ~100 times Invalid parameter passed to C runtime function. and the mapper starts to generate the PNG file. But the PNG file is only 0 Bytes big. Do you have any idea how to solve that issue or where to search?

Nice days adrido

[Rogier-5]

Hi Adrido,

finally I was successful compiling minetestmapper on Windows with Visual Studio I could not use the CMakeListstxt, because after solving all errors Cmake produced unreadable rubbish (but thats another issue) Manually creating a project file and including all required library throw some errors,

Please let me know of any changes that could be made to minetestmapper to better support building using MSVC.

but I could solve that except of one:

In mappercpp lines 793-800 https://githubcom/Rogier-5/minetest-mapper-cpp/blob/master/mappercp p#L793-L800 you are using the function strcasecmp In witch library can I find that function?

Apparently strcasecmp is posix-specific...

Try:

ifdef _MSC_VER

#define strcasecmp(s) _stricmp(s)
#endif

If that works, I'll create a patch for it. Probably a file which contains platform- specific code. E.g. 'porting.h', just like minetest has.

Alternatively, remove the call to strcasecmp, or define it to the identity operation:

ifdef _MSC_VER

#define strcasecmp(s) (s)
#endif

In the latter case, the arguments to drawscale must be lowercase. BTW: I just realize that drawscale is not the only option which uses textual parameters, and the others don't all use case-insensitive comparison. I suppose I should be consistent: use strcasecmp/stricmp everywhere, or nowhere... So I might actually remove strcasecmp altogether...

If I try to create a map the progressing mapblocks only goes to ~63% Than the debugger prints ~100 times Invalid parameter passed to C runtime function and the mapper starts to generate the PNG file But the PNG file is only 0 Bytes big Do you have any idea how to solve that issue or where to search?

One possibility is that you are using a library which is compiled using a different compiler than the one you are using. But then I'd sooner expect it to fail at 0% or 100%, not somewhere in between.

You could try this: https://msdn.microsoft.com/en-us/library/a9yf33zb.aspx. That might give some more information as to where the problem occurs. If that works, we can continue from there.

Nice days to you too.

Rogier.

[adrido]

I uploaded the current state here: https://github.com/adrido/minetest-mapper-cpp Its currently more proof of concept than something right.

I found what maybe causes the Invalid parameter passed to C runtime function. error. https://github.com/adrido/minetest-mapper-cpp/blob/master/TileGenerator.cpp#L2358 the m_image seems to be empty.

witch version of gd library did you use?

[Rogier-5]

I found what maybe causes the Invalid parameter passed to C runtime function. error. https://github.com/adrido/minetest-mapper-cpp/blob/master/TileGener ator.cpp#L2358 the m_image seems to be empty.

There is some stuff in there... I don't know how it should look ? . Is the section of map that you are mapping fully generated. I.e. no blank mapblocks and no non-background pixels in all 4 corners ? If it is, and if --drawscale is not enabled (also causes background-color pixels in 3 out of 4 corners), then I'd expect m_image->red (and the other colors) to contain non-zero entries. If there are background-color corners, then the zero entries you are seeing might be something that can be expected.

Apparently, the map would be 884x884 pixels ?

If the 'Invalid parameter passed to C runtime function.' messages start at 63% of the map, then the reason that m_image is empty, might be because of, or related to, the 'invalid parameter' error ?

To verify libgd, and to avoid the rendering altogether, and any problems it might trigger: in TileGenerator::generate, after 'createImage();' add 'writeImage(output); exit(0);' . If you then run minetestmapper --tiles=block, you should get a white (or rather: background color) image of the requested size with a 17x17 black grid. Make sure the image size is not too large, to avoid any errors that might cause. Nor too small of course. . If that works, then the problem most probably occurs while rendering the world, else it may indeed be a libgd problem.

witch version of gd library did you use?

2.1.1. Both for the linux builds, and for the mingw windows build.

Did you build libgd from sources yourself, or did you download the compiled library ? If you downloaded it, make sure the version you use was built for MSVC.

[adrido]

HEURECA! finally it works. Currently only with sqlite and only x32 but it works.

The "63%" Problem was caused because I had set --geometry 6000x6000 --geometrymode pixel maybe it calculates the Progress wrong so it does not finish with 100% on small maps. (not sure if this is a bug)

I does not know how I fixed the Invalid parameter passed to C runtime function. problem. Maybe it was because the gd lib was compiled with an diffrent version of the z library than minetestmapper (dll conflict, dont know)

The problem of the "0 Byte png file" was because libpng was missing and whether gd nor Windows C Runtime complained about it.

But finally it works, and that is good :smiley:

I'm only wondering why my build of minetestmapper (including all dll's) is so much smaller than yours (1,2 MB than 12MB) Minetestmapper MSVC x32.zip

There are still a lot of warnings while compiling but current state is good to start.

[Rogier-5]

HEURECA! finally it works. Currently only with sqlite and only x32 but it works.

Congratulations !

The "63%" Problem was caused because I had set --geometry 6000x6000 --geometrymode pixel maybe it calculates the Progress wrong so it does not finish with 100% on small maps. (not sure if > this is a bug)

It divides the current z-mapblock by the total number of z-mapblocks, and that's the percentage. With a 6000x6000 map, there are 375 mapblocks in the z-direction, so the resolution is about 0.3%... However, it only prints a progress line if it processes a block at that z-coordinate. If the bottom 37% rows of the world are empty, it prints nothing after having printed 63%... Of course, you could use --disable-blocklist-prefetch to make it process all empty rows as well...

BTW I just saw that there seems to be an off-by-one error in the progress percentage computation :-) Still, it should go all the way to 100%, unless the map is partly empty. If it doesn't, it may be a bug indeed.

I does not know how I fixed the Invalid parameter passed to C runtime function. problem. Maybe it was because the gd lib was compiled with an diffrent version of the z library than minetestmapper (dll conflict, dont know)

Could be. My Windows knowledge is not that detailed, although I am aware of a few of the common problems.

The problem of the "0 Byte png file" was because libpng was missing and whether gd nor Windows C Runtime complained about it.

How strange...

I'm only wondering why my build of minetestmapper (including all dll's) is so much smaller than yours (1,2 MB than 12MB)

I haven't checked the names and sizes of the DLLs, but maybe my build needs some DLLs that yours doesn't ? In any case, my build was compiled for windows, but on linux, and using a posix environment, so it needs a posix compatibility layer and a number of libraries that a 100% native windows build would not need, or the windows-native build would find similar but different libraries installed by default in the system directories. That would be my first guess.