Repository navigation
Home
Don't know how to use rid-tools to get the most out of Unity for 3ds? Well, here you'll find all the information you'll need to do it! But first of all...
After importing the .unitypackage, you'll notice a new tab in the Unity editor called "RID-Tools". Clicking on it will open a drop-down menu with two buttons. The first will open a configuration menu window for post-build patches, while the second will inject some DLLs into Unity to change the editor's behavior (these would be the pre-build patches).
Unlike post-build patches, these do NOT open a new window, but rather modify a section already present in Unity.
To access the pre-build patches, click on (RE)Inject Extra Patcher, then go to PlayerSettings, and if you click on the Splash Image section, you'll notice that it's no longer empty but now contains all these settings.
Note: SDMC Access unfortunately didn't work.
To access the post-build patches, click on Config Menu and... just save your config or make a cia with patches
Retro Indie Dev, a litle discord server, next question.
It's a set of tools and patches for both the Unity editor and a resulting .cia file with extended permissions, capable of utilizing 80MB of device memory on the old3DS.
Well... it does exist, but it's because they reverse-engineered an old alpha rid-tools made in Python before we published the Unity-ready source code in C# (at least some credit would have been nice, you know? :c)
Depending on the patch to be applied, post-build patches are applied by "disassembling" or "unpacking" the .cci file generated by Unity, modifying the game's .rsf file to force the use of a different system mode than the one the app can use by default, and repacking everything.
Pre-build patches are different; they're applied directly to the Unity editor to provide additional features not included (some unfortunately don't work, like SD card support, but hey... we tried :c). The most notable feature is the ability to compile to the maximum possible size for 3DS games, meaning 4GB cartridges, while Unity by default has a 2GB maximum. So... with RidTools you can make games with MUCH more content UwU
This is part of a big project we've been planning for a while, and it's slowly becoming a reality.
In this particular case, it's a small REST API that allows anyone to register their own titleID in a public database. That way, no one else can use your titleID because, well... it's already taken, duh.
The goal of RID is to create a complete retro development ecosystem, a centralized platform where anyone can upload their homebrew, manage it, and distribute it to different consoles. We call it the RID System, and it would consist of:
-
Tools: These would be different sets of tools not only for the 3DS but for different platforms and development environments.
-
API: A list of endpoints to query and record different types of information.
-
Database: Currently, there is an early alpha version of this in two variants (MongoDB only for titleID and UniversalUpdater Unistore to download apps and games directly to your 3DS).
-
AppStore (Client): Downloads, purchases (maybe not), ratings, and reviews.
-
AppStore (Admin): Version control, download statistics, payments (again, maybe not), responding to reviews, average ratings, and, of course, data uploads.
-
Visual Game Engine (like Unity or Godot): our most ambitious project, geared towards discontinued platforms and the only one whose development will NOT start soon
The Nintendo 3DS family of consoles has something called SystemMode, which is the mode or amount of RAM that a specific application is allowed to access or use.
These modes are only visible on a developer console (3DS Panda, for example) using the SDK's config application. Some of these are:
- Prod - 64MB
- Dev1 - 96MB (No browser/Miiverse)
- Dev2 - 80MB
- Dev3 - 72MB
- Dev4 - 32MB
- Snake Prod - 124MB for New 3DS
- Snake Dev1 - 178MB for New 3DS (No browser/Miiverse)
- Snake Dev2 - 124MB for New 3DS
A very few retail consoles can access one or more of these modes when forced to install the development firmware, but this is completely random, and generally, the consoles cannot access a different mode except for Prod or snake Prod
System Memory is the main or default memory, to which these modes are applied. In the case of unity, it uses them as follows:
Device Memory: Used when hardware beyond the CPU needs to access it. Also used as a fall-back option for things which the GPU needs to be able to see, but which don't fit into VRAM. Contents:
- Textures which don't fit into VRAM.
- When triple buffering is selected, the bottom screen’s frame buffers reside here instead of VRAM.
- Buffers used by the photographic camera.
- Sound effects.
- ORCS dump workspace.
System Memory: Can only be accessed by the CPU. Contents (basically everything not listed above):
- Code.
- Data.
- Models
Objectively... we don't know, we suspect it's due to operations performed by the Unity engine itself that set the memory usage slightly higher than it actually is (as is well known, when trying to load something into memory without having enough space, the console displays an arm11 core 0). These modes exist only to keep open the possibility that someone might make them work in the future.