dcnick3 / shin Goto Github PK

thread 'main' panicked at 'assertion failed: (left == right)'
left: '14473847'
right: '14473848' ;, shin-core\src\format\audio\mod.rs:199:5

It appears that on windows ffmpeg doesn't spit out the frame info as early as we would like and the game gets stuck

Maybe it's a problem with a certain ffmpeg build, instead of windows?

Also, we can try handling in a more failsafe way? (e.g. timeout & skip the playback?)

Rayon is kinda large, bevy doesn't like it, so we probably should not like it too & control the task pools ourselves?

At least this should change:

• The message is skipped "atomically", not 1 ClickWait per frame (how does the message synchronization work there?)
• Tweens used by LAYERWAIT are fast-forwarded (except when a special flag is set in the LAYERCTRL)
• ???

It's kinda convoluted, as those values are transformed multiple times during the layouting & rendering process, need to do a little digging with ghidra to do it

Want to have the kinsoku system as in the original engine, as well as word-wrapping for western languages as an extension

Want to allow: stopping time, single-frame stepping, changing the speed (look at factorio)

Currently types used in scenario parsing & vm execution are all over the place. Them needing FromVmCtx implementations is does not help. We want to figure out a policy on where to put them and where to put the impls

This requires some investigation on the engine side, but, probably should be done as:

• the PAGEBACK command "freezes" the screen
• the LAYERLOAD commands load the layers off-screen
• the WIPE command executes the transition animation (if any), changing from the frozen screen to the new layer set

Those are started with EVBEGIN and ended with EVEND commands

They do not allow fast-forwarding

They can be skipped as a whole (jump to EVEND) by pressing B

Questions:

• I haven't seen any messageboxes there. Is it possible to have one? How do they behave?
• Can stuff like interruptible wait (WAIT with first arg being 1) be interrupted? How do SELECTs work? Are events fully non-interactive?

It should:

• slide in from the bottom
• change its opacity as it does so

The speed should be matched to the original impl. Also don't forget to add waits in MSGCLOSE

It doesn't make sense to load full videos to even start playing, they should be streamable.

For other assets it probably isn't beneficial though. We should support both use-cases.

The new kira update exposes the Decoder trait, possibly (?) allowing us to duplicate less code.

The feasibility should be investigated

I think game treats them like EVs (#20), allowing to skip them by pressing B

This seems to be called "Scene Loading" in the game

The idea is to first run a lighter version of VM, without loading assets & rendering to a specific position in the script, and then to materialize it to the "real" ADV view.

This feature is used to implement loading (definitely), rollback and save thumbnail building (maybe). Also, warping to specific point of SNR is useful for development & debugging.

AFAIR there were some shortcuts in audio implementation, like looping not being implemented (?)

I found your tool when I was looking for a way to extract the data.rom found in the following two PS Vita ports:
(PCSG00462) Irotoridori no Sekai: World's End Re-Birth
(PCSG00901) AstralAir no Shiroki Eien: White Eternity

I tried to extract IroSeka's data.rom, but sdu gave me a bad magic number error. To fix that I changed "ROM" to "ROM2" in a hex editor, but now I get:
Error: Parsing ROM

Caused by:
Unknown version: 0x00020001

Astral Air already has ROM2 in its file header, but I get the same issue there:
Error: Parsing ROM

Caused by:
Unknown version: 0x00000001

There are many file formats inside that your tool also supports, such as .snr, .txa, .pic and .bup.

Is it possible to implement support for these two data.roms?
Also, is there a way to repack the data.rom file?

Currently, LAYERLOAD requires a yield to game loop, effectively making minimum load time 1 tick. I believe we can do better.

It does not allow us to express the inheritable transformations that can be put onto the RootLayerGroup

In the original engine, the LayerGroup and PageLayer ignore those transforms and pass them into the lower level layers. The transforms should probably be split into the transformation and projection?

Entergram released three patches in 2021, fixing several problems in Umineko. Is it possible apply thoses fix using your engine?

Umineko 1.0.3 (01006A300BA2C800)/(20.7MB) ? They also released patches for other games, such as Gerokasu.

So, apparently, entergram has fucked up gamma correctness in their engine...

They do not mark textures as being in sRGB space (but they are!) and therefore all computations happen without conversion to linear space (but they should be converted!)

Because of this I couldn't get the messagebox opacity to look quite right (to be the same as in the game)....

Alpha blending (RES = a * src + (1-a) * dst) was done in the different colorspace, so the result is different

To implement the same in our engine we would need to use texture views with differing srgb-ness, tracked at gfx-rs/wgpu#3237

Those are widely used in umineko.

Related commands: PLANESELECT, PLANECLEAR

I have spent some time carefully reverse-engineering how the rendering pipeline actually works in the engine, and what we have right now is very different from the game. I want to basically rewrite

This will help us to support features like:

• Masks applied to LayerGroups (which is what shin currently crashes)
• NewDrawableLayer-based effects (props 0x38-0x54). This is actually the only kind of effects used in umineko, with remnants of the older system (EffectLayer) still being present in the game. What a mess
• #8 (the rendering part)

This will probably also reduce GPU usage a bit: we do a ton of redundant renders right now, while the original engine design seems pretty optimized for some older smaller GPUs.

However I am not sure if it should be done now: wgpu seems to be on its path to resolving gfx-rs/wgpu#1453, which will make it much easier to implement the renderer (no need to manually put the GFX objects into an arena and ensuring they outlive the frame render).

I really like the impl by kira audio, would copy some ideas from there. Also, they are apparently called "tweens", for "in beTWEEN"

Wanna:

• Some debug overlays for layers ¿& other? tweens
• Warnings on unimplemented layer properties

Use https://crates.io/crates/gilrs to get raw gamepad state, allow to make bindings to it.

I tried sdu on the game D.C.4 ～ダ・カーポ4～ (title id 0100D8500EE14000), and got an issue with the scenario. Everything else is fine.

$ ./sdu scenario dump-info output/main.snr 
Error: 
 ╺━━━━━━━━━━━━━━━━━━━━┅ Backtrace ┅━━━━━━━━━━━━━━━━━━━━╸

 0: Error: unexpected end of string when reading double-byte char
           While parsing field 'emotion' in BustupInfoItem
     at shin-core/src/format/scenario/info.rs:30
 1: While parsing field 'elements' in SizedTable
     at shin-core/src/format/scenario/info.rs:122
 2: While parsing field 'bustup_info' in ScenarioInfoTables
     at shin-core/src/format/scenario/info.rs:150
 3: While parsing field 'info_tables' in ScenarioHeader
     at shin-core/src/format/scenario/mod.rs:28

 ╺━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸

Design: run another scripter some amount of instructions ahead of the main scripter, tracking only assets to be loaded. Maintain a set of "assets needed in near future", load them into the cache.