Milestone tracking for "Prettify"

[Helco]

This is an issue where I collect my thoughts about the next milestone and track issues. I might create an actual GitHub milestone if there are enough related GitHub issues.

Next Milestone

My current high-level plan for zzio has these milestones:

1. Gameplay working from London to leaving Endeva (without trainer fight)
2. Polish experience of that gameplay section
3. Start adding fights (<- we are here 😳)
4. Draw the rest of the owl

The reason for this is this in-between milestone is to ensure that the systems are working stable before beginning another massive section of this project.

Tasks to do

in no particular order

Features and bugs

• [x] #337
• [x] #322
• [x] #185
• [x] #321
• [x] #315
• [x] #316
• [x] #269
  Enough combiner parts to support fairy glows (only needs ParticleEmitter Particle/Models)
  Maybe check necessary parts for "Slight Quake" spell and/or "Impact"?
• First steps to scene effects
  • [x] Combiner
  • [x] Lens Flares
• [x] #308
• [x] Fog rendering
• [x] #298
  If we do need to add sorting, I would like to know before the next milestone
• [x] #274
  Just to clean up RWBS and most likely speed up loading
• [x] #309
• [x] #313
• Sound
  What would fights be without the pew-pew?
  • [x] Prepare bindings repository
  • [x] Integrating ~SoLoud~ MojoAL + Silk.NET.OpenAL + NLayer
  • MojoAL supports multiple contexts per device, so multiple windows should just work
  • [x] Spawning 2D and 3D sounds of actual gameplay as PoC
  • [x] Sound effects during teleporting
  • [x] Scene Sample3D
  • [x] #320

Architecture and dependencies

• [x] Configuration variables?
  • Could be used to fix #307
  • Easy to use way to disable music/sounds for development
  • Could prove necessary (at least beneficial) to AI implementation
• [x] #180
  ~I might want to think a bit longer on this.~
  It is bothering me and I have a less clever approach in the works
• Cleanup dependencies
  • [x] Veldrid does not need OpenGL or Direct3D anymore
  • [x] Veldrid.SPIRV will not be necessary anymore
    Only present in zzmaps anymore pending #270
  • [x] Mlang.MSBuild should not add runtime references
  • [x] Replace Veldrid.SDL2 with Silk.NET.SDL
    This should also preemptively fix issues for the cross-platform stuff
  • [x] Remove Veldrid.StartupUtilities after that ^
  • [x] Upgrade ImGui.NET
  • [x] #265
  • [x] Replace SafeStbImageSharp with SDL
    One dependency less
• Logging
  • [x] Serilog looks good, how about that?
  • [x] Is enrichment by class name possible?
  • [x] Logging should be configurable by CLI options
  • [x] Log to Remotery
• [x] Readd ImGuizmo after fixing cimgui on Windows
• [x] Replace DeepSource #312
  • Maybe just dotnet-format?
  • Recheck if .editorconfig works good enough
• Remotery
  Performance seems not as good as expected, Remotery should easily show the culprit and be helpful for any future performance analysis
  • [x] Preparing bindings repository
  • [x] Add to Zanzarah, Game, UI and Sequential*System
• [x] Remove legacy PipelineCollection
• [x] Mlang pipeline overrides to reduce stored variants
  Although instead I added variant filters to Mlang reducing both compiled programs as well as stored variants by more than half

Cross-platform testing

If possible both for developer as well as user experience
Leaving the possibility to postpone larger issues if they come up
Of course this should be one of the last topics for this milestone

• [x] Windows x64
  No good access to Windows ARM right now, maybe ask MM
• Linux
  • [x] Debian-based x64
  • [x] Arch-based x64
  • [x] Raspberry PI
    It apparently is Vulkan-conformant
    Quick test: vkcube is running and it can almost build (no native shaderc). Not bad, but no dev on RPi4 for now :)
• Mac OSX
  The newer Vulkan SDK and MoltenVK really do not like Veldrid very much, even with Pizzas fork. Maybe fix myself and talk to Pizza about merging. (meaning porting to Pizzas fork might be necessary for this)
  • [x] x64
  • [x] ARM
  • [x] Add GitHub CI for osx-arm (thanks to the ARM runners)

Good-to-have

Meaning I am not sure yet whether to tackle these in this milestone

Postponed

• 319 (might depend on #311)

• 137
  Apart from item-scripts this is "easy" work without much benefits for other systems

• Add map markers
  Same reasoning as ^, complete systems that are available in the supported gameplay section
• Zanzarah Cursor
  • Testing the DepthTest feature of `EffectCombiner``
  • Fixing #317, #304, #154
• Remotery: Add Vulkan samples
  Veldrid currently does not give us a native pointer to CommandList so no GPU samples for now...
• Steam Deck
  Should work anyway
• Mobile ports
  This will be only exploration which larger issues occur.
  • Android
  • iOS (remember Silk.NET.MoltenVK.Native for this)

[Helco]

Preliminary results of Cross-platform testing

✔️ Windows x64

Still works

✔️ Linux Debian/Arch-based x64

• ✔️ libdl is not loaded properly due to an outdated NativeLibraryLoader.
  Switching to Pizzas Veldrid fork should fix this
• ✔️ MojoAL was linked statically with SDL2, causing conflicts. This was fixed.
• ✔️ Ubuntu as debian-based distro was tested
  • 🚧 The shaderc library was broken as expected as we have no Silk release with fixed libraries yet. Overwriting as CI does works fine though.
  • libdl could be worked around like on Manjaro
• I consider linux x64 to be working after #323, the shaderc stuff will fix itself on time and can be worked around easily enough. If the issue persists unreasonably we can probably switch to pizzas interop or manually change the library in a Mlang update.

❌ Rasperry PI (Linux ARM64)

There are many missing libraries and the libdl problem might appear as well.

• SDL2
  Ask the Silk.NET folks whether they might include Linux ARM64 builds
• cimgui/cimguizmo
  • I guess I should rework ImGui-Nativebuild properly, put all artifacts into an archive and include more platforms
  • Maybe send both repo changes as PR, maybe they get accepted...

✔️ OSX x64/ARM64

I am putting these two together as they are very similar.

• There is a branch with temporary fixes
  With these both platforms seem to work fine.
• ❔ libvulkan.dylib is not found, copying them from the Vulkan SDK fixes this.
  It is questionable whether this is just a developer task or whether this should be fixed somehow, maybe with the Ryujinx MoltenVK dependencies?
• ✔️ Vulkan portability mode with MVK
  • The big validation error. It can be fixed rather easily in Veldrid but this is neither fixed with Mellinoe nor Pizza, maybe prepare a proper PR and send to both.
  • PR sent to veldrid/veldrid#525
• :heavy_check_mark: D24_U8 is unsupported
  • The easier fix would be to just check that the other platforms support F32_S8 and switch (done that for now)
  • The better fix would be to introduce pipeline overrides to the ShaderVariantCollection after all and switch per platform
• Vulkan validations
  • ✔️ VUID-VkBufferCopy-size-01988
    This I believe is a Veldrid bug as all other commands are checked for size==0 except one.
    (For us we can workaround by checking empty atomics in WorldMesh)
    PR sent at veldrid/veldrid#524
  • All following issues seem to be fixed by using TechPizzas fork, even the SPIRV version one...
  • ✔️ VUID-VkShaderModuleCreateInfo-pCode-08737
    This is a Mlang bug, we have to figure out the right pairs of Vulkan-SPIRV-SPIRVBinary versions and create modules accordingly
  • ✔️ VUID-VkImageCreateInfo-imageCreateMaxMipLevels-02251
    This and the following could be Veldrid bugs, but also could be fixed in Pizzas fork.
  • ✔️ VUID-VkPresentInfoKHR-pImageIndices-01430
  • ✔️ VUID-vkAcquireNextImageKHR-fence-01287
  • ✔️ VUID-vkAcquireNextImageKHR-surface-07783
• I have only encountered this on ARM64 but this might occur on x64 as well: F2 key does not work unless it is enabled in the system settings. Thanks Apple.
• Validation is much happier with us since #323, however there is another error when closing the window. This seems to also happen on windows just without the validation? It should be a general race condition:
  • ✔️ > Unhandled exception. Veldrid.VeldridException: A Vulkan validation error was encountered: [VK_DEBUG_REPORT_ERROR_BIT_EXT] (VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT) Validation Error: [ VUID-vkDestroyImage-image-01000 ] | MessageID = 0xf2d29b5a | vkDestroyImage(): can't be called on VkImage 0xde4e51000000008b[] that is currently in use by VkImageView 0x8f5f070000000095[ImGui.NET View]. The Vulkan spec states: All submitted commands that refer to image, either directly or via a VkImageView, must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.275.0/mac/1.3-extensions/vkspec.html#VUID-vkDestroyImage-image-01000) at Veldrid.Vulkan.VkGraphicsDevice.DebugCallback(VkDebugReportFlagsEXT flags, VkDebugReportObjectTypeEXT objectType, UInt64 object, UIntPtr location, Int32 messageCode, SByte pLayerPrefix, SByte pMessage, Void* pUserData)

❔ Steam Deck (Linux x64)

We should expect similar problems like for Windows/Desktop Linux here.

❔ Proton

untested

❔ Steam Runtime

untested

❌ Windows ARM64

There are some mythical stories about some Windows ARM device that supports some Vulkan in some preview, but currently there is no SDK, no drivers, no experimental previews of these and no roadmap forward.

Untested, but I might have access to a device... There will be several missing native dependencies. Also it is unclear whether Vulkan works on Windows ARM at all (or on my device), which would be an instant blocker.