- 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
- When I adapted `GBACart::ParseROM` to use `unique_ptr` instead of a plain pointer, I forgot to remove the code that copied the SRAM data
- That code was made unnecessary because of the move
