- 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
- 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
* Simplify the SRAM's representation in `NDSCartArgs`
- I overthought this one.
- I could've just checked `args && args->SRAM`, but then some other poor bastard might make this mistake.
- Don't mix `pair`, `optional`, and `unique_ptr` all at once, kids.
* Fix a `nullptr` read
* Fix detection of native NDS ARM BIOS images
- Instead of checking for built-in BIOS images, now the altered methods check for native ones
- The CRC32 must match exactly; patched BIOS images will result in `false`
* Encapsulate `NDS::ARM9BIOS` and `ARM7BIOS`
- Also compute the checksum only when setting the BIOS
* Allow 3D renderers to be created without passing `GPU` to the constructor
* Make the initial 3D renderer configurable via `NDSArgs`
* Fix a compiler error
* Sprinkle `const` around where appropriate
- This will make it easier to use `NDS` objects in `const` contexts (e.g. `const` parameters or methods)
* Remove the `const` qualifier on `DSi_DSP::DSPRead16`
- MMIO reads can be non-pure, so this may not be `const` in the future