Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lmu2png does not work with Japanese file names #61

Open
EK720 opened this issue Oct 1, 2021 · 2 comments
Open

lmu2png does not work with Japanese file names #61

EK720 opened this issue Oct 1, 2021 · 2 comments

Comments

@EK720
Copy link

EK720 commented Oct 1, 2021

I'm trying to convert maps in a Japanese RM2K game to png files for mapping purposes, but many of the maps give an error along the lines of "Can't find chipset ", even though the chipset is there in the files. Is there any way for me to solve this problem, or are there any alternative tools I could use to convert RPGM maps to images?
image

@Ghabry
Copy link
Member

Ghabry commented Oct 1, 2021

Add -e 932 to the command line

@ElTipejoLoco
Copy link

ElTipejoLoco commented Oct 17, 2023

image
夢箱-2.png exists in game directory's CharSet folder.
Displays as û▓öá-2 without -e 932.
Displays as 夢箱-2 with -e 932.
wataru 主人公 カヌー移動.png exists in game directory's CharSet folder.
Displays as wataru ÄσÉlî÷ü@âJâkü[ê┌ô« without -e 932.
Displays as wataru 主人公 カヌー移動 with -e 932.
Copying and pasting image files with the mis-encoded filenames into the appropriate directory and re-attempting will not result in them being found.
I've only experienced LMU2PNG present this kind of issue. Is it possible that the encoding code somewhere in either liblcf's detection of encoding or its usage specific to populating strings here is not working as expected? I mainly figure it must be the issue if specifying the Shift-JIS's code page is actually changing the behavior (though using external encoding/decoding tools implies the file names would turn into what's being displayed if the CLI attempted to display them in IBM00858's, in my case, whereas the filenames that appear when specifying the Shift-JIS code page don't).
I'm assuming the issue is somewhere in the population of the strings before they're fed to FindResource(), and I'm hoping it's somewhere here rather than further upstream in liblcf.
This is a non-issue for missing ChipSet files thanks to the -c option, though these too will fail if they're not renamed to have filenames with only UTF-8 valid characters when specified. Unfortunately, Panoramas aside it feels like it'd be a terrible idea to implement a workaround for CharSet issues as there would possibly need to be a prompt for every time a unique file's failed to be found, which could get ridiculous for cases such as EK720's.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants