32bit ARM support about mcmap

[pfiszer]

And I'm trying to run it on RaspberryPi 4B with 4GB of RAM

[spoutn1k]

Hi ! Thanks for raising this issue.

The compilation failed, which means the mcmap executable has not been generated, so ./mcmap is correctly returning the warning that the file does not exist.

However the compilation error is interesting. I have no way of replicating the error on hand, but it looks like something changes in the ARM version of the stl. Let me write patches so you can test them, if you have some time.

[pfiszer]

Yeah, I've got some time, when you patch it I can test it

[spoutn1k]

Can you clone and test the branch armFix ? I noticed an x86_64 assumption that might break on ARM, it might fix your issue.

[spoutn1k]

So I got my hands on a 32bit ARM system and I managed to replicate your error.
While the branch fixes the compilation errors, and not without complaining a bunch, the resulting executable produces .. Interesting results.
I don't know if you are still interested, but I am working on it.

[spoutn1k]

The latest commit fixes the rendering errors. Expect a merge soon, then if no comments are made, I will close the issue.

[pfiszer]

src/canvas.cpp:239:65: note:   mismatched types ‘std::initializer_list<_Tp>’ and ‘long long unsigned int’     
       std::max(uint64_t(ceil(log2(sectionPalette->size()))), 4ul);
                                                                 ^
make: *** [Makefile:40: src/canvas.default.o] Error 1

[spoutn1k]

Well yes that is the error on the main branch. You have to use the armFix branch, where I put the fixes to your specific situation. I mentionned it in the previous comments, but I prefer to reiterate as you seem to have overlooked it.

If you are not familiar with git, you can check which branch you are on using git branch, and change to another branch using git checkout <branch name>.

The armFix branch executable created a full image with no errors in a reasonable time on a Raspberry Pi 4B 4g with stock RPiOs, so if you haven't made custom installs it should work for you.

[pfiszer]

It compiled fine, but when I tried to run it I got this error:

 mcmap 3.0.0 32bit (compatible with Minecraft v1.13+)
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

[spoutn1k]

Please give some more context. What did you run ? The mcmap options are important.

[pfiszer]

I run ./mcmap ~/.minecraft/saves/Kebab

[spoutn1k]

Well, if you are willing to, please send a compressed archive of the save file so that I can take a look.
In the meantime, try using the -from -to options to reduce the load, as this is a raspberry after all it is not capable of doing too much. The usage of options is detailed in the README.

[pfiszer]

I run ./mcmap -from 0 0 -to 200 100 ~/.minecraft/saves/Kebab
and got :

mcmap 3.0.0 32bit (compatible with Minecraft v1.13+)
Loaded 44 colors out of the 731 declared
[Error] Nothing to output: canvas is empty
Job complete.

The output file has 0 bytes.

Here is the world:
https://mega.nz/file/uX5nEBYZ#RKl8EMr-PrXvRyCj4AjCOgWAwDA3ZZ55zXtUvnI_doE

[spoutn1k]

Okay so this is what your world looks like (cropped):

mcmap creates an image for the whole world, which is pretty empty. Unfortunately, there is no way of knowing. On my beefy system, it squeezes out a 40,000x20,000 pixels image to fit everything, so you HAVE to tell it what to render or the pi will run out of memory.

Try with greater values: ./mcmap -from -1024 -1024 -to 1024 1024. On my pi however it created an image from the coordinates you mentionned, try cleanng and recompiling: make clean && make -j.

[pfiszer]

I got [Error] Nothing to output: canvas is empty again, which pi are you using?

[pfiszer]

It doesn't detect any region files

[pfiszer]

oh wait

[spoutn1k]

The exact same as you; the pi is not important.

Now I can only think that the world is different or not accessible, can you try with the save you provided ? Download it in another folder and try with this one.

[pfiszer]

I copied all of the region files to the pi again and It's working fine

[spoutn1k]

Did you get an output ?

[pfiszer]

yes

[spoutn1k]

Great then. Expect a merge this week-end, then the changes will be available in the main (NBT19133) branch.

[spoutn1k]

After a bit of refactoring, the changes are merged into the main branch. Thanks for bringing that error up. Closing the issue.