Our GL code uses lots of outdated practices that are suboptimal at best (immediate mode & fixed-function pipeline mixed with shaders, no batching, etc.). Performance suffers in particular with many bullets and particle effects on screen. Fixing this is the top priority for v1.3. The end goal is to have the renderer work in a Core GL 3.1 context, possibly with GLES 2.0 compatibility.

This is going to be a big undertaking and every bit of help is appreciated. Let's use this thread for planning and discussion of potential design issues.

In normal Touhou, every bullet has a sound, I think. Different sounds for different types of bullets and situations and bells for things like the particles changing state.

I could probably cheat together some sounds. The question is how to incorporate them into the game efficiently. Could we just add a play_sound to create_projectile without screwing things up? Do you have thoughts on this?

On master on an intel video card with shaders disabled.

Long standing issue that is probably my fault. Keep forgetting to fix it.

We are having a pretty long loading time now. It will only get worse with BGM in place. So what about somehow switching to loading things stage-wise.

At the moment most of the time is spent loading the big spell backgrounds and textures for the later stages.

Those resources are already in special folders like gfx/stage6/, so maybe we could add something that dynamically loads and unloads the right folder them to the stage logic.
This would also make testing spells in single spell mode faster.

You better remember now. :^)

While testing stage functionality, I found that Kurumi (in boss role) timing is a bit strange.

At first, I wasn't able to reach introduction dialog with her - she starts her attacks after nearly 4 seconds of waiting.
It seems to be solved if I change AT(400) to AT(120) in src/stages/stage4_events.c:417 (kurumi_boss_intro()), but I'm not sure that I do it right.

Additionally, last attack of her final spell card (Power Sign ~ Blow the Walls) occurs after the ending dialog starts (and I have to dodge it while first dialog line is displayed).

Reproduced two times with either with Youmu and Marisa. Here goes two replays with this issue (note: they were recorded with "--" commented at src/player.c:212 to achieve some sort of infinite lives).

replays.zip

I noticed that since the change to SDL2 the window is resizable. Is that intentional?

Resizing works really fluently now and the aspect ratio is preserved, which is good. But still it seems pretty unexpected behavior for a fixed-aspect ratio game. I can imagine most of the time will accidentally resize it and make the window have black bars.

It also messes up tiling wm behavior: The wm thinks it tiles well and doesn’t create it floating by default. If I make it float, the wm doesn’t know about the best window size and uses some random size that doesn’t fit the aspect ratio.
Normally, I never have this problem with games.

Since we already have an option to set the window size, how about making it non-resizable again?

Self-explanatory. There are frequently red bullet noises even where they shouldn't exist as there are no fairies left on-screen.

Trying to run the AppImage in 64-bit 17.10 gets me the following error:

"$ ./taisei-1.1+195.g1a45593-Build228.1.glibc2.14-x86_64.AppImage
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
do_winsys_init: DRM version is 3.18.0 but this driver is only compatible with 2.12.0 (kernel 3.2) or later.
1076 W: load_resource(): Failed to locate bgm 'menu'
1076 W: parse_keyvalue_file_cb(): VFS error: Node 'res/shader/postprocess.conf' does not exist
1076 W: progress_load(): Couldn't open the progress file: SDL error: Couldn't open /home/desum/.local/share/taisei/progress.dat
1085 W: get_resource(): bgm 'menu' was not preloaded
1085 W: load_resource(): Failed to locate bgm 'menu'
1085 W: start_bgm(): BGM 'menu' does not exist"

Happens with or without the Padoka PPA. Worst bit is that all eight of my CPU cores shoot up to 100% and the only fix is a reboot

Endings should be manually paged similarly to dialogs, instead of being on a fixed timer. Also, some of the lines are very long and should be broken up.

This idea comes in two separable parts:

1. Automatic freeing

Instead of storing refs inside the p->args array, they could be stored in some separate array p->refs. Leading to syntax like

create_particle1c(...)->refs[0] = add_ref(e);

Advantages:

• They can be easily garbage collected. Every element of refs that is unequal to zero is freed when the projectile dies.
• More possibilities to throw errors on wrong calling. e.g. If you use EnemyFlareShrink without setting the ref.

2. Type awareness

The code sometimes relies on the alignment of pos in the Enemy, Projectile and Boss structs. A solution would be adding some type information to the refs.

struct Ref {
    void *ptr;
    RefType type;
};

enum RefType {
    RT_Boss,
    RT_Enemy,
    RT_Projectile,
    RT_Other
};

It’s still valid to save any type of data in a ref, it will just get RT_Other.
Then using _Generic macro magic add_ref can be used to set that parameter.

#define add_ref(x) add_ref_p(x, _Generic(x, Boss*: RT_Boss, Enemy*:RT_Enemy, ..., default: RT_Other)

I’ve never used _Generic so not sure if this works.

Using this information we can replace the REF(r) macro:

Boss *b = (Boss *) REF(r); /* Old */
Boss *b = REF(r, Boss);    /* New */

where

#define REF(r, type) (type *)get_ref(r,RT_ ## type);

here get_ref returns a void * pointer to the data and throws an error if the type is wrong.

Now this ensures things you get by REF have the right type. Now we still have that ->pos problem in EnemyFlareShrink. For this I suggest adding

#define REF_GET_ATTRIB(dest, r, attr) \
    switch(get_ref_type()) { \
    case RT_Boss: dest = ((Boss *) get_ref(r,RT_Boss))-> attr; break; \
    ... \
    case RT_Other: log_fatal(...);

Which will only compile if attr is really something a shared attribute between Boss, Enemy and Projectile.

Maybe this isn’t the most elegant way to do it, so feedback is welcome.

Tested in stage practice

Suggested by Ultroloth (and I agree).

Audio works for me only on taisei-1.1+199.ga6a1660-Build231.1.glibc2.14-x86_64.AppImage. Log:

i965_dri.so does not support the 0xffffffff PCI ID.
958       W: load_resource(): Failed to locate bgm 'menu'
960       W: parse_keyvalue_file_cb(): VFS error: Node 'res/shader/postprocess.conf' does not exist
960       W: progress_read(): Progress file will be automatically downgraded from v1.1.1 to v1.1.0.199 
upon saving
968       W: get_resource(): bgm 'menu' was not preloaded
969       W: load_resource(): Failed to locate bgm 'menu'
969       W: start_bgm(): BGM 'menu' does not exist

It doesn't on AUR taisei ver. 1.1.1-1. Log:

0         W: config_set(): Unknown setting 'key_fpslimit_off'
90        W: png_warning_handler(): PNG warning: iCCP: known incorrect sRGB profile
184       W: load_resource(): Failed to locate bgm 'bgm_menu'
184       W: parse_keyvalue_file_cb(): VFS error: Node 'res/shader/postprocess.conf' does not exist
184       W: progress_read(): Unknown command 5 (3 bytes). Will preserve as-is and not interpret.
184       W: get_resource(): bgm 'bgm_menu' was not preloaded
184       W: load_resource(): Failed to locate bgm 'bgm_menu'
184       W: start_bgm(): BGM 'bgm_menu' does not exist
194       W: load_sound_begin(): Mix_LoadWAV() failed: Audio device hasn't been opened
194       W: load_resource_finish(): Failed to load sound 'generic_shot' (res/sfx/generic_shot.wav)
196       W: load_sound_begin(): Mix_LoadWAV() failed: Audio device hasn't been opened
197       W: load_resource_finish(): Failed to load sound 'hit' (res/sfx/hit.wav)
198       W: load_sound_begin(): Mix_LoadWAV() failed: Audio device hasn't been opened
198       W: load_resource_finish(): Failed to load sound 'shot_special1' (res/sfx/shot_special1.wav)

It also doesn't work on AUR taisei-git ver. 1.1.r237.gfc57c9f-1, log:

482       W: audio_backend_init(): Mix_Init() failed: OGG support not available
559       W: load_resource(): Failed to locate bgm 'menu'
560       W: parse_keyvalue_file_cb(): VFS error: Node 'res/shader/postprocess.conf' does not exist
560       W: get_resource(): bgm 'menu' was not preloaded
560       W: load_resource(): Failed to locate bgm 'menu'
560       W: start_bgm(): BGM 'menu' does not exist
567       W: load_sound_begin(): Mix_LoadWAV_RW() failed: Audio device hasn't been opened
567       W: load_resource_finish(): Failed to load sound 'generic_shot' (res/sfx/generic_shot.ogg)
572       W: load_sound_begin(): Mix_LoadWAV_RW() failed: Audio device hasn't been opened
572       W: load_resource_finish(): Failed to load sound 'shot_special1' (res/sfx/shot_special1.ogg)
574       W: load_sound_begin(): Mix_LoadWAV_RW() failed: Audio device hasn't been opened
574       W: load_resource_finish(): Failed to load sound 'hit' (res/sfx/hit.ogg)

I tried all versions with the same ~/.local/share/taisei folder, then removed it before launching each version, it changed nothing.

It happens both with headphones plugged and unplugged. I'm using Manjaro's default pulseaudio and alsa configuration (pulseaudio sink is the default alsa device). I have ALC223 soundcard, detected as HDA Intel PCH.

Thanks in advance for any help with this issue.

As you may know, taisei doesn’t take checking the return value of malloc for NULL seriously and would segfault if NULL is returned.

Now with all the dialog graphics and possibly BGM in the future, it is possible that some people will try to run this on their SoC/toaster and it will run out of memory and maybe return NULL on some kind of system and the user will not know it’s because of that.
Maybe we should define some malloc function that will panic and print an error message if that happens and replace all mallocs by that.

I do not know if the builtin references and linked-list implementations (or anything else) rely on malloc(0) == NULL though. But that could be retained by something like

void *tmalloc(size_t size) {
    void *p = malloc(size);
    if(p == 0 && size != 0)
        oh_no();
    return p;
}

This is probably better because SDL_mixer implements some features we could use, and ALUT/OpenAL has a lot of features we don’t really need (like 3D positional audio). Also, cross compiling those libraries with static linking is kind of a pain, and freealut does not appear to be readily available everywhere.

Don't forgetti.

Suggested by metsubou, who'd like to see a sound similar to the rumbling in Touhou when a spell or pattern is almost cleared.

Happens both on practise mode and in-game, both on existing and new saves. Has been working before.

Log:

409306    W: get_resource(): texture 'proj/stain' was not preloaded
409306    W: load_png(): VFS error: Node 'res/gfx/proj/stain.png' does not exist
409306    E: load_resource_finish(): Required texture 'proj/stain' couldn't be loaded (res/gfx/proj/stain.png)
fish: “taisei” terminated by signal SIGABRT (Abort)

Already discussed with Akari, however there is a lack of direction on what is causing it.

Anyone else thinks it should be removed? The game is completely broken and unplayable without shaders anyway, let alone ugly as sin. You can't even see some of the bullets (the ones supposed to be additively blended, I think). I can easily imagine someone disable it accidentally or hoping to gain more FPS on their toaster from 2008, and think the game doesn't work properly (see #39).

I went back through the looks to collect this todo list we came up with a few weeks ago.

Probably should do?

• finish Reimu
  • balancing™
  • bomb sfx?
• invincibility frames at the start of spellcards
• fix fragments

Might post-pone in favor of releasing

• touch up stage 2 stage danmaku
• touch up other patterns (Artificial lightning, etc)
• scoring™

I'm still bitter about this issue and probably going to investigate it again sometime soon. I'm not sure if this is caused by incorrect usage of the tsrand functions somewhere, but I believe it's highly probable and should be tripple-checked first. At very least, the naming of those functions should definitely be revised -- what the fuck does an anfrand() do?

If you have any thoughts about replays and/or RNG, you're more than welcome to discuss them here.

Suggested by Ultroloth.

The projectile death effect should be replaced with an angle-neutral one, because not all projectiles have a meaningful angle value. We can go back to an angle-aware one in 1.3 when we have a reliable way to tell if the angle is meaningful.

This is just an issue to keep track of the resources we are missing.

BGM

• Stage 1
• Stage 1 Boss
• Stage 2
• Stage 2 Boss
• Stage 3
• Stage 3 Boss
• Stage 4
• Stage 4 Boss
• Stage 5
• Stage 5 Boss
• Stage 6
• Stage 6 Boss
• Menu
• Credits
• Ending
• Gameover (not sure if needed, so this is lower priority than everything else)

SFX

• Most urgently we need a sound for enemy shots. Cool charge up sounds and chimes would also be cool for some attacks. (#52)
• Power up sound
• Extra life sound
• Extra bomb sound

GFX

• Some pictures for the different endings. I can do them when I get motivation.

This is a little teaser for what I’m doing at the moment. ;)

Focusing the player name input field on the settings screen and typing p will take a screenshot. This should not happen.

How about we revive #taisei-project on freenode? And by revive I mean actually attend it. In particular I need at least @laochailan there. There are some things I'd prefer to discuss in real-time rather than in issue comments.

SDL2 always repeats keys on its own, and each keypress generates a series of SDL_KEYUP/SDL_KEYDOWN events. If key repeat is enabled (e.g. via xset), it gets all key events twice, half of them with key.repeat == 0, rendering the menus unusable and badly influencing gameplay.

I’m not alone with this problem; multiple SDL2 applications appear to suffer from this. I have not tested whether this happens on Wayland as well. Given that this issue has been around for years in SDL2, it seems we’ll have to support multiple input APIs, like many other games do, and only use SDL2 as fallback where no native API is implemented.
Looks like xkbcommon is the way to go on Linux, rather than the ancient Xlib2 extension.

As we all know, Projectile, Enemy, Item and friends all contain prev and next elements so they can be used directly as elements of the linked list implementation. This relies on them being aligned equally in every one of those structs and is one of the suspects that could cause the memory corruption with optimizations enabled.

And even if it isn’t this is is a very scary construction and quite easy to fix by wrapping them all in the ListContainer struct which already exists and changing all the loops over lists in the game in a smart way.

for(ListContainer *l = global.projs; l; l=l->next, p = (Projectile*)l->data)

for example.

P.S.: Bonus points for changing all the loops automatically using regex.

Right now, gamepad input easily gets stuck in a direction when using analog axes.

I attempted to connect to the Freenode IRC chat and no one was in the room. Is this officially dead?

Happens as soon as the debug callback is called, nature of the crash is unpredictable. I suspect a calling convention mismatch, though I'm pretty sure we're using the API properly. Might not be our bug, more testing is needed. Currently confirmed on x64 wine only.

-Technically by Ultroloth from his stream but I see it hasn't been pinned here.

He wanted the colors changed to better reflect that they're separate from the lesser fairies and have more hp.

We can't time anything even remotely precisely with that garbage API, not to mention the random fucking clipping. See also https://discourse.libsdl.org/t/sdl-mixer-issue-no-one-talks-about/20200/2

This blocks #112

At this point it might be reasonable to go back to OpenAL and see if we can synchronize the sfx timings nicely with it. There's also this library that's built around it that may or may not be suitable. It's also a good opportunity to refactor the audio code.

And I'm totally fucking not going to work on this shit.

It gives a false positive on two of my Fedora systems: 25 stable on my netbook, and 27 rawhide in a systemd-nspawn container.

The build log

Their aiming is random and doesn't help when trying to get a consistent route down for the stage, especially since they move from top to bottom, meaning that they shoot you from every angle on the side they're on. The ones in the post midboss section also awkwardly transition into the rest of the stage and I personally think having no filler kedamas would be best.

Earliest known affected commit is 2457d76.
First (and so far the only) time triggered on spell practice of Icicle Fall Easy (spell id 8108) as MarisaB.

==22289==ERROR: AddressSanitizer: heap-use-after-free on address 0x7fa168409428 at pc 0x0000004703ee bp 0x7ffcee9ae1c0 sp 0x7ffcee9ae1b8
READ of size 8 at 0x7fa168409428 thread T0
    #0 0x4703ed in list_append ../../../git/taisei/src/list.c:56
    #1 0x492a02 in _create_projectile ../../../git/taisei/src/projectile.c:269
    #2 0x492ab0 in create_particle ../../../git/taisei/src/projectile.c:279
    #3 0x428481 in spawn_particle_effects ../../../git/taisei/src/boss.c:216
    #4 0x430317 in process_boss ../../../git/taisei/src/boss.c:590
    #5 0x4b1590 in stage_logic ../../../git/taisei/src/stage.c:408
    #6 0x4b3796 in stage_logic_frame ../../../git/taisei/src/stage.c:573
    #7 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #8 0x4b56af in stage_loop ../../../git/taisei/src/stage.c:688
    #9 0x4d879f in start_game_internal ../../../git/taisei/src/menu/common.c:72
    #10 0x4d8cf5 in start_game ../../../git/taisei/src/menu/common.c:109
    #11 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #12 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #13 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #14 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #15 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #16 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #17 0x4ff73b in enter_stagemenu ../../../git/taisei/src/menu/submenus.c:26
    #18 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #19 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #20 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #21 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #22 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #23 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #24 0x47504d in main ../../../git/taisei/src/main.c:310
    #25 0x7fa17b3e2a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
    #26 0x421419 in _start (/data/taisei-build/dev/gcc/src/taisei+0x421419)

0x7fa168409428 is located 298024 bytes inside of 319552-byte region [0x7fa1683c0800,0x7fa16840e840)
freed by thread T0 here:
    #0 0x7fa17d9242f0 in __interceptor_free (/usr/lib64/libasan.so.5+0xeb2f0)
    #1 0x476d74 in objpool_free ../../../git/taisei/src/objectpool.c:159
    #2 0x4c621c in stage_objpools_free ../../../git/taisei/src/stageobjects.c:45
    #3 0x4b5ac2 in stage_loop ../../../git/taisei/src/stage.c:704
    #4 0x4d879f in start_game_internal ../../../git/taisei/src/menu/common.c:72
    #5 0x4d8cf5 in start_game ../../../git/taisei/src/menu/common.c:109
    #6 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #7 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #8 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #9 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #10 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #11 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #12 0x4ff73b in enter_stagemenu ../../../git/taisei/src/menu/submenus.c:26
    #13 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #14 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #15 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #16 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #17 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #18 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #19 0x47504d in main ../../../git/taisei/src/main.c:310
    #20 0x7fa17b3e2a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)

previously allocated by thread T0 here:
    #0 0x7fa17d924670 in malloc (/usr/lib64/libasan.so.5+0xeb670)
    #1 0x475354 in objpool_alloc ../../../git/taisei/src/objectpool.c:40
    #2 0x4c6138 in stage_objpools_alloc ../../../git/taisei/src/stageobjects.c:36
    #3 0x4b4821 in stage_loop ../../../git/taisei/src/stage.c:632
    #4 0x4d879f in start_game_internal ../../../git/taisei/src/menu/common.c:72
    #5 0x4d8cf5 in start_game ../../../git/taisei/src/menu/common.c:109
    #6 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #7 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #8 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #9 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #10 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #11 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #12 0x4ff73b in enter_stagemenu ../../../git/taisei/src/menu/submenus.c:26
    #13 0x4e4bb9 in close_menu_finish ../../../git/taisei/src/menu/menu.c:60
    #14 0x4cdb71 in call_callback ../../../git/taisei/src/transition.c:83
    #15 0x4cdfca in update_transition ../../../git/taisei/src/transition.c:146
    #16 0x4e62dc in menu_logic_frame ../../../git/taisei/src/menu/menu.c:163
    #17 0x4571e4 in loop_at_fps ../../../git/taisei/src/framerate.c:157
    #18 0x4e65a9 in menu_loop ../../../git/taisei/src/menu/menu.c:183
    #19 0x47504d in main ../../../git/taisei/src/main.c:310
    #20 0x7fa17b3e2a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)

SUMMARY: AddressSanitizer: heap-use-after-free ../../../git/taisei/src/list.c:56 in list_append
Shadow bytes around the buggy address:
  0x0ff4ad079230: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad079240: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad079250: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad079260: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad079270: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0ff4ad079280: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad079290: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad0792a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad0792b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad0792c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff4ad0792d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==22289==ABORTING

I'm using the latest version (master branch). When running ninja in the build folder, this error message appears:

[…]
Meson encountered an error:
Multiple producers for Ninja target "src/taisei@exe/core.c.o". Please rename your targets.
FAILED: build.ninja 
/usr/bin/python3 /usr/share/meson/meson --internal regenerate […]/taisei […]/taisei/build --backend ninja
ninja: error: rebuilding 'build.ninja': subcommand failed

What license(s) are the assets in this game under?

I may be wrong, but I think CMakeLists.txt is set to require Python (which is later used only for Windows builds).

Also, while PACKAGE_DATA_LEANIFY is disabled by default, it would be nice to have this optional dependency mentioned in README.

Hi,
I've submitted a flatpak manifest for Taisei to flathub.
https://github.com/flatpak
https://github.com/flathub

If you're interested in maintaining the flatpak manifest feel free to comment here to get admin access to the repository.
flathub/flathub#538

It is impossible to distinguish multiple devices with the same name on the settings screen. Should probably append the ID in that case.

Is the AppImage for Linux available for download somewhere? Thanks.

See the attached pictures.

version 1.1-239-g119535e (1 commit behind)

Using Intel i915 driver with Intel HD Graphics 530 (i5 6300HQ).
Resolution: 2560x1080.
KDE Plasma v 5.11.2
KDE Frameworks v 5.39.0
Compositor settings:

Log:

497       W: load_resource(): Failed to locate bgm 'menu'
497       W: parse_keyvalue_file_cb(): VFS error: Node 'res/shader/postprocess.conf' does not exist
498       W: get_resource(): bgm 'menu' was not preloaded
498       W: load_resource(): Failed to locate bgm 'menu'
498       W: start_bgm(): BGM 'menu' does not exist
12519     W: load_resource(): Failed to locate sound 'full_power'
12519     W: load_resource(): Failed to locate sound 'extra_life'
12519     W: load_resource(): Failed to locate sound 'extra_bomb'

Please put the exclamation mark at the end of "Perturbation theory breaking down!" like so.

-From your resident grammar nazi excluding lachs0r