dobiestation
patreon
Roadmap for the First DobieStation Release
🕑 Added 2020-06-01 17:18:45 +0000 UTCTo sum things up, we are planning to have an official v0.1 release, though there is no deadline on this. What we have in mind is more a list of features that are either essential or nice to have for the first release. DobieStation has been in development for over two years, and in that time it has went from barely scraping by trying to boot a few games to supporting a large portion of the PS2 library, even fixing games that don't work on other emulators like True Crime: Streets of L.A. Though Dobie will not be fast enough to be usable by most people, the official release will be an important milestone, showing how much Dobie has matured over its life.
Here's what's left to do, in no particular order...
SPU2 Redesign and Sound Dumper
Newcomer Ziemas has been working on a PR to dump sound that games play to a WAV file, as well as substantially improving the accuracy of our SPU2 emulation. SPU2 is the PS2's sound chip, and it has features like ADSR envelopes, reverb, and more. Many games rely on SPU2 to function correctly as they will poll voice registers to know when a sound clip has finished playing - if this happens too soon or too late, bugs can range from cutscenes finishing much faster than usual to softlocks and crashes. The original implementation was barebones, only enough to allow the first games to boot, but Ziemas has implemented all of SPU2's major features, fixing titles such as Burnout 3 and Gregory Horror Show. The PR awaits review but is otherwise finished for the time being.
Check out the PR here: https://github.com/PSI-Rockin/DobieStation/pull/333
Memory Cards
Fairly self-explanatory. Savestates are volatile and can break, especially for a newer emulator like DobieStation, so memcards are a safer way to save progress. Memcards can also aid in testing by allowing users to skip long cutscenes or just getting further in-game in less time. A PR exists for this that implements the core functionality, but additional work is needed to expose memory cards to the UI.
DMAC Stability Improvements
The DMAC is responsible for transferring data to and from memory and peripherals, such as the graphics chip and the Vector Units. Games heavily rely on this to upload textures and geometry for processing, and it is also required to communicate with the Input/Output Processor (IOP), which manages sound, controllers, and memory cards. Because the DMAC is such an important cornerstone for the PS2, games have many ways of exploiting the DMAC to get the most out of it they can. Games like Jak & Daxter and Ratchet & Clank will do work while a DMA transfer is ongoing and expect the transfer to finish in time without properly waiting for it. Dobie has synchronization problems between the EE and DMAC that break these race conditions, causing those games to have corrupted graphics or crash. DMA race conditions affect many PS2 games, so fixing those problems will allow many new games to work.
Texture Cache
Although texture caches are primarily used in hardware renderers to avoid expensive transfer operations between the CPU and GPU, a texture cache is also useful for Dobie's software renderer, which runs entirely on the CPU. Caching textures will provide a speedup by avoiding the need for format conversion calculations, but it will also fix visual glitches in games that use a technique called recursive drawing. The Graphics Synthesizer (GS), the PS2 GPU, stores textures and framebuffers in the same memory. Recursive drawing involves overlapping the texture buffer and framebuffer when drawing, which overwrites the texture. As the GS has its own texture cache, recursive drawing does not destroy the texture until after it has been read. Because VRAM is limited at 4 MB, games rely on recursive drawing to perform special effects without needing to create a temporary buffer to copy the framebuffer to; one example is the "Radiosity" effect in GTA: San Andreas. A texture cache will allow Dobie to handle these effects.
Automated Testing
ps2autotests provides dozens of tests, but Dobie has no way to run them automatically. Seemingly innocuous changes to the emulator may break games, so having automated testing allows us to catch bugs as quickly as possible.
One problem with ps2autotests is that they output results to a terminal driver on the IOP. Retail consoles stub out this driver, making the output go nowhere! To solve this problem, we can intercept commands sent to the IOP. The EE and IOP use a consistent server/client interface to communicate with each other through something called SIF RPC, ensuring that we can catch those commands and interpret them when they are sent. That way, when the tests send their results to the IOP, we can redirect them to a text file and compare the output with that taken from a real PS2, raising an error if there is a difference. There is a PR that handles the interception part, but it needs cleanup before it can be merged.
As a side note, catching IOP commands also greatly aids debugging, as it offers insight into what commands games send to the IOP. The work on this PR exposed a bug in how we handle dual-layer discs, allowing the unpatched version of Gran Turismo 4 to go in-game!
Hardware-accelerated Software Renderer
This may seem like an oxymoron, but in a way it makes sense. Though GS rendering is processed in software, there needs to be some way to display the final image on the screen. Currently Dobie relies on Qt, the GUI library we use, to render this image. However, rendering this image using OpenGL, Vulkan, or some other 3D graphics API is beneficial as it offers a framework for proper hardware rendering, which will be added in future versions of Dobie. Hardware acceleration also enables post-processing effects done through shaders, which could make the output appear as if it were on a CRT, for instance. There are no plans for shader support at the moment, but it is important regardless to have a foundation for it and hardware rendering.
External Controllers
Dobie currently uses the keyboard for input. This is inconvenient for testing, as a keyboard cannot properly do analog inputs, and some buttons on the emulated DualShock 2 are unimplemented. Controller support fixes these issues and makes Dobie more accessible to the casual user.
Closing
I'd like to thank everyone who has made DobieStation possible: the other developers who have added features and fixed bugs, our testers who have thrown hundreds of games at Dobie, and everyone else who has helped spread the word. Making a PS2 emulator is no easy feat, and it is only made possible through collaboration. I hope you're as excited as we are to see how Dobie advances in the future!
Comments
Lollie
Awesome to see Dobie gearing up for v0.1, wishing all devs and contributors the best of luck. ✌ On the topic of DS2 controllers and the problem of analog inputs: It might be worth looking into MUNIA ( https://munia.io/ ) and getting in touch with its developer. MUNIA (and its PS1/PS2 variant MUSIA, unfortunately currently out of stock) is made for input display, but it also doubles as a controller adapter for PC. In the case of MUSIA, it supports full HID access to its analog inputs. https://github.com/zzattack/munia/blob/df2bce23c4878c657045e3ccd8d7c2a7afe225ee/MUNIA-win/MUNIA/Controllers/MusiaPS2.cs I was in contact with its developer last year about PS2 analog input access - he floated the idea of having analog inputs act as a "separate" controller on PC, if RAW HID access didn't work out for whatever reason. If MUSIA does go this route and Dobie chose to support it, Dobie's controller support would need to allow for assigning inputs from multiple input sources, per emulator player. (I imagine this would be good practice regardless, as an accessibility feature for users with non-standard input schemes.) Aside, there is also the Bliss-Box range of adapters. https://bliss-box.net/ The last time I checked, Bliss-Box's support for PS2 analog button inputs is more limited (iirc, only four analog buttons at a time?), and so active analog buttons have to be manually configured. But it is currently readily-available as an option.
Faviann Di Tullio
Thanks for sharing that roadmap/objective. It's a lot of fun too to be able to follow and development through time. By the way I appreciate the work that went into the report to make the whole thing super easy to understand. It was clear, precise and made a lot of sense and was super easy to follow. Good work people
