- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
This issue was observed in MGS Master Collection Volume II, MGS4: Guns of the Patriots, Chapter 4: Shadow Moses
That title is a bundle, and that specific chapter is a program (MGS 1st stage), launched by a program (MGS4), launched by an application (main title bundle).
Upon decoding guest panic message, it was exposed that an abort was triggered after trying to create a save in nand/temp/gclvar.bak file.
Further instrumentation exposed the error on that file's path, caused from a previous deletion of that folder.
In the same session that folder had been already cleaned and created successfully, which evidences an undesired re-cleaning of the temp structure.
The issue was the fact that the MGS4 to MGS transition also calls EnsureSaveData>...>SaveDataFactory creator, and that was destroying the previous created temp structure. After that stage, the return from MSG to MSG4 was causing the same issue again.
By moving the deletion to the guest application level, the factory creation was called only once, as it should be, and the issue is gone.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4375
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: lizzie <lizzie@eden-emu.dev>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
This is intended to fix Hades II save loading issue.
By analyzing panic dump it was found out that the error code was 0x160A. By decoding firmware it was found that error comes from 'nn::codec::InitializeHardwareOpusDecoder'.
Further decoding revealed that SDK tries to allocate multiple opus instances, up to the fw limit of 24 instances, and when it receives return error ResultOutOfOpusDecoders (385), a software fallback is gracefully used.
Implementing the limitation and the limit reached error code return makes saves load properly, multiple times in a row in both windows and android.
I still wonder why the game allocates too many parallel instances, but the current implementation is a real fw compliant solution, and whether the 24+ is real or some leak may be investigated later, or not.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4384
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reduces the page entries from 32 bytes to 8 and rewrites `VirtualBuffer` to be more efficient in memory usage and specifically for large zero regions.
The page table will now only reserve 1GiB instead of 4GiB and of this memory it should only use at most ~8MiB.
This PR has the side effect of using Eden on Windows on low memory systems much more plausible since it would previously require ~10GiB of committable memory at front (despite using ~5-6 at most, inadvertently stalling other processes) where as now it should only require around the amount that it'll actually use.
Co-authored-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4219
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
Problem: In cyrilic idioms, Absolum won't past beyond 1st area (intro miniboss).
From the user panic i`ve extracted these strings:
> GlobalState.request_next()
> save_state_to_saveGame(...)
> platform.ProcessSave()
> bin_serialize_to_file(...)
> StandaloneTypeModel.Write(SaveGame, ...)
> Write(SaveGame.AdventureSaveSlot, ...)
> Write(PlayerState, ...)
> ProtoBuf.ProtoWriter.WriteString(...) + 0xcc
> ProtoBuf.Helpers.DebugAssert(...)
> Debug.Fail(...)
By debugging ProtoBuf.ProtoWriter.WriteString(...) argument it was found that the string Отлично! (Great! expression for combos between 6 and 30 iirc) was reaching a size comparison of different values and causing an assert in guest side..
It seems the game tries to save highest combo level. I've managed to skip this bug by doing a perfect combo for entire level, so that the problematic word never was generated or attempted to be saved.
After further research, the issue chain was identified: Game maths literal string size via two ways and compare, and one of them was getting replaced by a wrong value due to Eden letting the literal string be interpreted as a real instruction.
Logic added:
const bool pair = decltype(l)::ExtractValue(raw) & 1;
const bool fixed_rt2 = decltype(rt2)::ExtractValue(raw) == 0b11111;
return pair || fixed_rt2;
- pair checks bit 21 (L & 1): register-pair instructions actually use Rt2, so they remain accepted.
- For single-register forms, require Rt2 == 31. The table word fails this check, so NCE leaves it intact.
Sources
https://www.scs.stanford.edu/~zyedidia/arm64/stxrb.htmlhttps://www.scs.stanford.edu/~zyedidia/arm64/stxp.htmlhttps://github.com/qemu/qemu/blob/master/target/arm/tcg/a64.decode#L344
Altough the solution is a case specific guard, it is data agnostic: This is a true fix to avoid a specific case in which a literal may be interpreted as a valid instruction, without interfering with other true instruction cases.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4369
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Replaces all instances of ankerl's unordered map/set with boost's
`unordered_flat_*` classes. This uses std::hash since boost::hash is
actually a lot slower.
Also adds an abstraction layer in `Common` so future changes are quicker
and easier.
Other implementation details:
- ankerl provided hash specializations for tuple and pair, so those were
ported here
- std::erase_if doesn't work on boost, so just used the ADL'd erase_if
This should be about equal or superior performance as unordered_dense for everything except iteration.
Signed-off-by: crueter <crueter@eden-emu.dev>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4326
Reviewed-by: Lizzie and Samuel <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
lizzie