You were right, that problem we were talking about was uninitialized memory, which was why I was only having the problem some of the time. Specifically, the problem was in the AGS variable text_font_maxsize. Setting text_font_maxsize to 0 during the AGS constructor solves the problem. Obviously it's not a very frequent problem but it's a simple and reliable fix.

Hi! Aldexplorer2 doesnt seem to support png reimported into vsp CG pack of Maria and Kanpan. I am looking for a way without modifing source code of aldexplorer. Maybe system3-sdl2 could be modified to use outsude pictures. How to redirect fixed picture outside picture pack by filenames?

And new zh-translation of Rance IV has published with your xsystem35-sdl2's executable and it works well, thanks for your work!

I'm not really familiar with mixing CMake with Visual Studio, so maybe you can help me with something. During the Configure step, CMake asks you to specify your platform: x64 or x86. I'd like to have both in the same project, as is standard for Visual Studio, but can't figure out how to do it. Is there a way to get CMake to generate for both platforms? Is there a way to adjust CMake's solution to support both? Normally that wouldn't be hard but I'm getting some odd errors when I try. Or, failing all else, should I just generate separate projects?

Hello, just started to work with this. One thing I noticed is that System3-SDL produces very different-sounding MIDI tracks than the original games, including Takeda Toshiya's System3 for Win32. For example, Little Vampire plays nothing but piano, replacing the sound of other instruments with more piano.

It's possible the problem is with my computer's MIDI settings, so if you need me to get you more info or a recording, I can send that.

Is there any way to bring the sound closer to the originals?

Since the change "Android: Allow specifying custom fonts in system3.ini," I haven't been able to load fonts via command arguments on Windows. Note that the game does still load the default font, because it uses open_resource() instead of SDL_RWFromFP(). When my code tries to use SDL_RWFromFP, it gives me the following error:

"Cannot load font file [x]: SDL not compiled with stdio support."

I can't find any helpful details about this error message online. Note that I'm using the default SDL.dll for my compiler, or at least I think I am. Downloading a fresh, default SDL.dll and SDL_ttf.dll doesn't change anything either. Am I making a simple mistake again?

https://github.com/kichikuou/system3-sdl2/actions/runs/8303169195

[ 94%] Linking CXX executable system3.elf
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: /opt/devkitpro/portlibs/switch/lib/libSDL2_ttf.a(libSDL2_ttf_la-SDL_ttf.o): in function `TTF_Size_Internal':
SDL_ttf.c:(.text.TTF_Size_Internal+0x74): undefined reference to `hb_buffer_create'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0xb4): undefined reference to `hb_buffer_set_direction'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0xc4): undefined reference to `hb_buffer_set_script'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0xe0): undefined reference to `hb_buffer_add_utf8'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0xf4): undefined reference to `hb_shape'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0x100): undefined reference to `hb_buffer_get_glyph_infos'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0x110): undefined reference to `hb_buffer_get_glyph_positions'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0x490): undefined reference to `hb_buffer_destroy'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_Size_Internal+0x5dc): undefined reference to `hb_buffer_destroy'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: /opt/devkitpro/portlibs/switch/lib/libSDL2_ttf.a(libSDL2_ttf_la-SDL_ttf.o): in function `TTF_SetFontSizeDPI':
SDL_ttf.c:(.text.TTF_SetFontSizeDPI+0x60): undefined reference to `hb_ft_font_changed'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: /opt/devkitpro/portlibs/switch/lib/libSDL2_ttf.a(libSDL2_ttf_la-SDL_ttf.o): in function `TTF_CloseFont':
SDL_ttf.c:(.text.TTF_CloseFont+0x18): undefined reference to `hb_font_destroy'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: /opt/devkitpro/portlibs/switch/lib/libSDL2_ttf.a(libSDL2_ttf_la-SDL_ttf.o): in function `TTF_OpenFontIndexDPIRW':
SDL_ttf.c:(.text.TTF_OpenFontIndexDPIRW+0x168): undefined reference to `hb_ft_font_create'
/opt/devkitpro/devkitA64/bin/../lib/gcc/aarch64-none-elf/13.2.0/../../../../aarch64-none-elf/bin/ld: SDL_ttf.c:(.text.TTF_OpenFontIndexDPIRW+0x178): undefined reference to `hb_ft_font_set_load_flags'
collect2: error: ld returned 1 exit status

I guess -lharfbuzz is not specified on the linker command line. It's probably a packaging issue of switch-sdl2_ttf.
@AGraber FYI

In quoted (SysEng-style) strings, currently all backslashes (0x5c in ASCII) are treated as escape characters. But 0x5c can be a trailing byte of multibyte characters. For example, the second byte of 'ソ' is 0x5c.

That means, if System3-sdl2 encounter the message 'ソ', it will remove the second byte of ソ, consume the closing ' as part of the message, and also consume the subsequent command bytes as message until it hits the next ' character.

System3-sdl2 should not treat 0x5c as an escaping character if it is part of a multibyte character.

Background

Originally System1-3 only supported Japanese characters, encoded in Shift-JIS. ASCII characters are included in Shift-JIS, but they were interpreted as commands rather than text messages.

SysEng (by @RottenBlock) enabled ASCII characters in messages, by enclosing them with quotation marks (' or "). It was merged to system3-sdl2.

@silas1037 is working on GBK character encoding support, for Simplified Chinese translation. The code change is fairly simple, thanks to the similarity between GBK and Shift-JIS.

Now let's step back a bit, and explore possible alternative designs for multi-language support.

Unicode vs non-unicode

Unicode

xsystem35-sdl2 and xsys35c have complete UTF-8 support, as described in "Unicode mode" document. I think a similar approach is possible in system3-sdl2.

Pros:

• We can cover many languages with single implementation. Note that just using Unicode is not perfect, for example we can't get right-to-left languages support for free.
• UTF-8 is the "native" encoding of SDL2. We could just pass UTF-8 strings to SDL2 functions.
• Gaiji characters can be mapped to Unicode's Private Use Areas.
• Characters outside the target character set can be used. For example, symbols like ◎ can be used even when translating to a western language that uses Latin-1 character set.

Cons:

• Implementation is not trivial, compared to the GBK support.
• Shift-JIS support is still needed, for original AliceSoft games.

Non-unicode

Instead of using Unicode, we may support different encodings for each character set (Shift-JIS for Japanese, GBK for Simplified Chinese, Big5 for Traditional Chinese, etc.).

Pros:

• We already have working code for GBK, by @silas1037. It breaks Shift-JIS support, so some refinement is needed though.
• GBK support only needed to replace the Unicode conversion table and implementation of a few functions such as is_[12]byte_message(). Many non-unicode encodings have similar structure so could be supported in a similar way.

Cons:

• We need separate Unicode conversion table for each language.
• To avoid conflict, Gaiji encoding must be defined individually for each target character encoding. For example, 0xeb9f-0xebfc and 0xec40-0xec9e are used for Gaiji in Shift-JIS, but it overlaps with regular character ranges in GBK.

Language tag

Currently, there is no way to declare the character encoding used in ADISK.DAT. For the interpreter (or decompiler), the character encoding has to be provided separately, e.g. by a command-line flag. Should we have a language / character-encoding tag in the head of the scenario file, like the (now deprecated) REV tag of SysEng?

This may not be so beneficial, since many games require the correct game ID to work properly, and the character encoding can be determined from the game ID.

Compiler / decompiler

I'm not familiar with Sys0Decompiler internal, but it seems simply changing the encoding name was enough for GBK compilation, and it would possibly work for UTF-8 or other encodings too. Decompilation would be straightforward as well, if the character encoding is known.

It would be nice if the compiler had some abstract notation for Gaiji, so that users don't have to care about the actual representation in the target character encoding.

Zenkaku-Hankaku conversion

System3 games store certain Zenkaku (2-byte) characters as Hankaku (1-byte) characters, to save precious floppy disk space. There is no reason to perform such conversion in non-Shift-JIS encodings.

When trying to build system3-sdl2 with Emscripten on an English Windows 10, I suffer an error during the step "Linking CXX executable system3.js." I'm using unmodified code from the repo, and I've tried reinstalling emscripten, system3-sdl2, and even python a few times, without any luck. Using emscripten on Linux works fine, the problem seems exclusive to Windows. Here's the traceback:

Traceback (most recent call last):
File "C:\emsdk\upstream\emscripten\em++.py", line 14, in
sys.exit(emcc.run(sys.argv))
File "C:\emsdk\upstream\emscripten\emcc.py", line 2150, in run
post_link(options, wasm_target, wasm_target, target)
File "C:\emsdk\upstream\emscripten\emcc.py", line 2179, in post_link
emscripten.run(in_wasm, wasm_target, final_js, memfile)
File "C:\emsdk\upstream\emscripten\emscripten.py", line 845, in run
emscript(in_wasm, out_wasm, outfile_js, memfile, shared.DEBUG)
File "C:\emsdk\upstream\emscripten\emscripten.py", line 283, in emscript
metadata = finalize_wasm(in_wasm, out_wasm, memfile, DEBUG)
File "C:\emsdk\upstream\emscripten\emscripten.py", line 437, in finalize_wasm
stdout=subprocess.PIPE)
File "C:\emsdk\upstream\emscripten\tools\building.py", line 1618, in run_binaryen_command
ret = check_call(cmd, stdout=stdout).stdout
File "C:\emsdk\upstream\emscripten\tools\shared.py", line 105, in check_call
return run_process(cmd, *args, **kw)
File "C:\emsdk\upstream\emscripten\tools\shared.py", line 95, in run_process
ret = subprocess.run(cmd, check=check, input=input, *args, **kw)
File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\subprocess.py", line 474, in run
File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\subprocess.py", line 926, in communicate
File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\cp1252.py", line 23, in decode
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 95: character maps to
make[2]: *** [CMakeFiles\system3.dir\build.make:538: system3.js] Error 1
make[1]: *** [CMakeFiles\Makefile2:114: CMakeFiles/system3.dir/all] Error 2
make: *** [Makefile:102: all] Error 2

Any ideas?

TOTO's System3 for Win32 has been updated on 2020/3/21, for the first time in 4 years. It includes some general improvements and bug fixes, and adds support for more games.

As system3-sdl2 has diverged heavily from TOTO's, merging it would require significant amount of manual work.

Hi again. I've been working on English support for system3-sdl2, and I'm nearly ready with the Windows release, but I thought of something else I wanted to discuss with you. In the original system3 for win32, the program had a menu bar. Obviously, menu bars are system-dependent and that's not portable, but the menu included a handful of features that system3-sdl2 could easily support, if only it had a way to turn them back on. Can you think of anything we could do that might restore these features? I've been considering a few alternatives, like desktop-exclusive use of the F-keys, but maybe you can think of something portable.

Reminder of the features I'm talking about:

• Resetting the game - I use this one a lot and it's the one I miss the most. While the code for this is no longer in system3-sdl, it could be copy and pasted without trouble.
• Fullscreen support - Looks hideously stretched, I'm personally not a fan. But some desktop users might want it? SDL should make this easy enough to implement.
• Sound source toggle - Toggles between FM and CD sound in games that support it. system3-sdl2 still has all the code required just waiting to be used.
• Message wait mode - Produces a teletype effect when printing text. The code is still around waiting to be used.

The menu also supported quitting the game and served as an alternate way to use the Skip Text feature, but those aren't really required.

Hope to hear from you, maybe you'll have some ideas!

Hi again. Recently, I got some error reports for the beta version of the English port saying that the program wouldn't run on Windows due to Application Error 0xc000007b. Looking into the problem, I discovered that while I can run my the English version just fine, I suddenly can't run your original, Japanese version without getting the same error. This certainly didn't used to be the case. I really feel that I'm missing something obvious but I don't want to make any leading suggestions.

Here's what I can tell you:

• Compiled using your relatively recent code and most recent instructions. Debug build, although the other users were encountering the problem in my Release build.
• In my case, running on Windows 10 64bit in English mode. Problem occurs in both command line and explorer.
• SDL2.dll, SDL2_mixer.dll, SDL2_ttf.dll, libfreetype-6.dll, and zlib1.dll are present in the folder.
• Little Vampire data files used for testing, though since the program crashes instantly I don't think that matters.
• While I haven't tested this on your Japanese version yet, in my version it didn't seem to matter if the code was compiled for 64 bit or 32 bit.

Any ideas?

After hiding and returning to window in Task Bar, it would turn off the screen so that it need click inside plate.

Moved from #4 (comment).

In System3, Z 1xx command defines a mapping from music number to track number of the CD. For example, Z 101, 2 specifies that track 2 should be played for music number 1. If this mapping is not specified or track 0 is specified, MIDI sound is used.

In some games (e.g. Rance 4.1 and 4.2), CD/FM sound can be switched from in-game menu. Selecting "FM" (which means MIDI to us) clears the mapping with zero, and selecting "CD" re-populates the mapping.

Some other games (e.g. Only You) lets the user choose a sound device at the start of the game. If "FM" is chosen, the Z 1xx command is not executed at all.

In system3-sdl2 code, this mapping is stored in the MAKO::cd_track[] array. In the current implementation, selecting "FM Sound" from the menubar clears this array, and selecting "CD Audio" sets cd_track [i] = i for 1 <= i <= 99.

There's a bug here. In Rance 4.1, the correct mapping is cd_track[i] = i + 1. This is the reason why selecting "CD Audio" plays a track that is off by one. Note that cd_track[i] = i is correct in some other games (e.g. Only You), and some others have more random mappings (e.g. D.P.S. ALL).

If the Z 1xx command has been executed in the past, the mapping can be restored when "CD Audio" menu is selected. That should fix Rance 4.x, because Rance 4.x always issue Z 1xx commands at the startup. But in other games, it's not guaranteed that the correct mapping is known when "CD Audio" menu is selected.

When trying to use the new config file system, I encountered a parser error. Thankfully, I was able to fix the error, but you should be the one to decide if it's the right fix. The fix is simple: in config.cpp, ln94, change "if (current_section == CONFIG)" to "else if". The code seemed to be checking the line that reads "[config]" and was producing an error when it didn't include any instructions on the same line.

Also, there's a typo in the Readme: at one point you say "ststem3.ini" instead of "system3.ini."

I was trying out the new, English release of Policewoman VX, and noticed that it wasn't using antialiasing. I checked the config.ini file and everything seemed fine, "noantialiasing" was set to "false" as intended, and so went into the debugger and found that to_bool's strcasecmp and strcmp functions were always returning true, even when you send them the string "false."

The config file itself doesn't seem to matter, I could even change the variable in code and it would still declare a match for every one of strcasecmp(s, "yes"), strcasecmp(s, "true"), strcasecmp(s, "on") and strcmp(s, "1"). Even checking to see if they were all true simultaneously would pass:

strcasecmp(s, "yes") && strcasecmp(s, "true") && strcasecmp(s, "on") && strcmp(s, "1")

Is it just me? If so, what on earth have I done?

In SysEng0.4, reactions on '前進する' could be quite soon so that you can move fast by contiously clicking, but system3-sdl2 is not.
When selection '前進する' appears, you have to wait 0.5 seconds until reacting to left-click.
In fact, not only moving selections, all selections seem so.

After hiding and returning to window in Task Bar, it would turn off the screen so that it need click inside plate.

The MSYS built from Actions could not be run.
Well, how to get a stable and common-used one by actions building?

And, it cannot show savedata when loading on WinXP.

Hi! I add text below to system3.ini and fail to open program. Well, I want to define different.

[string]
back = 戻る
next_page = 次のページ
dps_custom = カスタム
dps_linus = リーナス
dps_katsumi = かつみ
dps_yumiko = 由美子
dps_itsumi = いつみ
dps_hitomi = ひとみ
dps_mariko = 真理子

I want to create a translation for them.