* check if an nds save file can be opened for writing
also add the ability to open a file in append mode
* fix multi-instance saves
also move the check for file writability into a separate function (probably uneeded?)
* implement check for gba roms
* move rom load error messages into the functions
also finish gba slot (oops)
* improve error string
* check write perms before saving path settings
* fix memory leak
* check for writability of firmware/nand/sds
* add secondary checks for nand/firmware
* add check for config file being writable
* Return the file write error as a QString to avoid the invalid char*
causing a garbled error message.
Qt wants it as QString either way.
* Switch to using Qt 6
* Use Ubuntu 22.04 for newer dependency versions
* Combine AppImage and regular x86_64 builds so it doesn't have to build twice
* Misc cleanup
* Use macOS 14 M1-based runners for macOS CI
* Hopefully make the universal build erroring not fail the build (does sometimes with delete-artifact)
* Update vcpkg version
- According to GBATek, all DSiWare games have a high title ID of 0x00030004
- Some homebrew apps set the Unitcode bits to DSi mode to enable support of DSi features
* First crack at ensuring the render thread doesn't touch GPU state while it's being serialized
* Get rid of the semaphore wait
* Add some extra fields into GPU3D's serialization
* Oops, TempVertexBuffer is already serialized
* Move vertex serialization into its own method
* Lock the GPU3D state when rendering on the render thread or serializing it
* Revert "Lock the GPU3D state when rendering on the render thread or serializing it"
This reverts commit 2f49a551c1.
* Add comments that describe the synchronization within GPU3D_Soft
- I need to understand it before I can solve my actual problem
- Now I do
* Revert "Revert "Lock the GPU3D state when rendering on the render thread or serializing it""
This reverts commit 1977566a6d.
* Let's try locking the GPU3D state throughout NDS::RunFrame
- Just to see what happens
* Slim down the lock's scope
* Narrow the lock's scope some more
* Remove the lock entirely
* Try protecting the GPU3D state with just a mutex
- I'll clean this up once I know it works
* Remove a duplicate method definition
* Add a missing `noexcept` specifier
* Remove an unused function
* Cut some non-hardware state from `GPU3D`'s savestate
* Assume that the next frame after loading a savestate won't be identical
* Actually, it _is_ worth it
* Don't serialize the clip matrix
- It's recalculated anyway
* Serialize `RenderPolygonRAM` as an array of indexes
* Clean up some comments
- I liked the dialogue style, but oh well
* Try restarting the render thread instead of using the lock
- Let's see what happens
* Put the lock back
* Fix some polygon and vertex indexes being saved incorrectly
- Taking the difference between two pointers results in the number of elements, not the number of bytes
* Remove `SoftRenderer::StateBusy` since it turns out we don't need it
- The real synchronization was the friends we made along the way
* Reload the SD card for `CartSD` and all subclasses
* Make `ROMManager::LoadDLDISDCard` delegate to `GetDLDISDCardArgs`
* Add a method overload for `CartSD::SetSDCard`
* Initialize new SD card images with the correct size
* Sync the old card to the host (if applicable) when move-assigning a new one
* Only sync the old card to the host if it's not read-only
* Remove static state in `FATStorage`
- Replace `FF_ReadStorage` and `FF_WriteStorage` with lambda functions
- Keep open and use the single `File` handle throughout the `FATStorage`'s life
* Resolve some warnings
- Their frequent appearance in the build logs is driving me nuts
* Silence warnings about `offsetof`
* Don't apply `-Wno-invalid-offset` to C, only to C++
* Align some two-element `u32` arrays as `u64`s
- To pacify "unaligned read/write" warnings from UBSan
* Align some more arrays based on how they're accessed
* Integrate support for building with dependencies from vcpkg
Configure the build using -DUSE_VCPKG=ON to use vcpkg. By default
recommended triplets targeting the OS versions official builds support
are used. You can opt out of this with -DUSE_RECOMMENDED_TRIPLETS=OFF.
* Add the vcpkg manifest
* Fetch vcpkg with FetchContent if we don't have it
* macOS cross compiling fixes
- can't use the x86_64 one as host triplet on arm64 because building Qt
fails for whatever reason. Because of course it does :D
- vcpkg doesn't always like periods in triplet names so removed those
* x86_64 macOS should also use its recommended target when building arm64 builds
Luca D'Amico