The ISOs that Dreambox expects are just regular old ISO-9660 .iso files, exactly the same as you'd burn to a CD-R. The only requirement is that the ISO file should have the "main.wasm" file located in the root directory.
There's a few utilities you can use to make ISO files. If you are ok with installing cargo, you can use that to install the "mkisofs-rs" utility and use that to bundle your ISO files, which is what the Rust toolchain for Dreambox uses under the hood.
It's *definitely* changed a lot since this devlog!
A small recap:
Anyway...
It is extremely unlikely that I will be able to port it to Dreambox, as it is implemented with RPG Maker MZ (written in JS and HTML5). I would need to rewrite the game from scratch in order to do this - it's possible, but would be a significant effort and tough to really justify as it wouldn't really benefit me in a whole lot of other ways.
Hello!
I am using the AdvSaveHandler plugin in conjunction with the CLI cook tool for my game Foxblade Fable, which I distribute via Itch.IO.
I primarily work on Linux, and I noticed that on Linux when launching a game from a Flatpak version of Itch.IO, rather than putting the save folder in the user's home directory Flatpak will instead redirect those paths to a temp directory (at least by default - you can manually grant home directory permissions to the Itch.IO app, but frankly I would prefer my game run out of the box without nasty surprises like losing save data)
To improve this, I ended up tweaking AdvSaveHandler myself to support the XDG base directory specification - it's an extremely simple change: instead of just using the home directory, it will instead use $XDG_DATA_HOME, or fall back to $HOME/.local/share otherwise (which the spec defines as an appropriate default for $XDG_DATA_HOME). The change looks like this:
if (process.platform == "linux") {
home = process.env.XDG_DATA_HOME || path.join(systeminternals.homedir(), ".local", "share");
}
Now when launching on Linux, it will either put its folder in ~/.local/share, or it will put it wherever $XDG_DATA_HOME is defined (when running under Flatpak Itch.IO for example, the save game folder is put in ~/.var/app/io.itch.itch/data)
Hm, that could be tough - later on I can give cross-compiling to Mac a shot, most of what I'm using should have native libs for Mac, but I don't have a Mac machine so I won't be able to test any of it fwiw.
(worth noting that I'm also working on an HTML5 port of the runtime which'll run in Electron or even in a browser, so that might be another option for ya)
No you're not missing anything, usage docs are still lacking right now & in dire need of some attention (I've just been really busy with other stuff, so I haven't been able to dedicate as much time as I'd like to projects like this)
For what it's worth you have three ways of loading an ISO into Dreambox:
Additionally, for keybinds, they are stored in a config JSON file created when you first start Dreambox. On Windows, that will be located at `C:\Users\[username]\Documents\SavedGames\dreambox\dreambox-savedata\AllPlayers\config.json`. On Linux, I *think* that would be something like `~/.local/share/dreambox/dreambox-savedata/AllPlayers/config.json`? I can verify on my laptop in a bit.
FWIW the default keybinds are:
| Gamepad Button/Control | Keyboard Mapping |
|---|---|
| A | L |
| B | P |
| X | K |
| Y | O |
| D-Pad | Arrow Keys |
| L1 | Q |
| L2 | Left Shift |
| L3 | Left Control |
| R1 | E |
| R2 | Right Shift |
| R3 | Right Control |
| Start | Enter |
| Select | Space |
| Left Stick | W/A/S/D |
| Right Stick | T/F/G/H |
Also, for what it's worth, a few useful hotkeys you may want to know:
You asked for a Debian version, there is a Linux version which should work on Debian. I'm sorry you have to go through extra steps to get a working runtime environment, but that's kind of how the cookie crumbles when you're using Linux.
At the moment that's probably the best I can do for you. Getting a version that doesn't depend on the .NET runtime would probably involve rewriting the whole thing in a language that isn't C#, and considering I have made a grand total of $6 ever on Dreambox that's probably not super feasible for me. I also don't have access to Chromebook hardware, and do not plan on obtaining one, so a native app is also probably off the table.
The officially supported language is Rust, and is the language covered by the tutorials here:
https://dreambox3d.dev/getting_started
However, Dreambox games use WASM binaries, and so technically anything that compiles to WASM can also be used (including C or C++ via Emscripten). In fact, a set of C headers are provided in the Downloads section which you can reference to link to Dreambox APIs.
However, it is worth keeping in mind that rather than taking a raw WASM file, Dreambox games actually consume CD ISO files, which embed a "main.wasm" in the root directory and any other files referenced by the game, so the C/C++ route will involve some extra steps to bundle everything as an ISO file. Meanwhile, the Rust tools provided above will handle all of these details for you
Probably not as it stands?
Right now the whole thing is built on a couple of underlying frameworks: .NET core, wasmtime, and FNA. All three of those are likely to pose issues with porting to the Wii, not least of which is FNA - as it is an open-source implementation of XNA which mainly targets modern rendering frameworks (D3D11, OpenGL 3.x, Vulkan, etc), using lots of features that just wouldn't work on a fixed function pipeline like the Wii. I get the feeling that a dynamic JIT compiler based runtime (WASM) may also pose a few issues.
That said, it *may* be possible to take a different approach - it could be theoretically possible to write a framework for the Wii which exposes all of the same functions as the Dreambox WASM host does, and then use maybe something like wabt to translate a Dreambox WASM game into C, and statically linking it with the aforementioned framework and compiling it for the Wii. Lots of extra steps & complications though.
I had at one point considered seeing if something like this was possible for the Dreamcast, but decided against it as none of the compressed texture formats would be supported so it'd be of limited utility. I also have made a grand total of $6 on Dreambox ever so it doesn't leave a whole lot of room for experimentation on niche things like this ;)
At the moment I don't believe any actual games have been released for it - thus far I've only made a handful of tech demos (an ROQ video player, a Quake BSP viewer, and a little character physics / skeletal animation demo), and I'm not aware of anything anyone else is working on.
Sadly I've been kept too busy at work & on other projects to really be able to focus on making full games for the thing myself 😔
That's a pretty broad question, so it's a little tough to answer, but I'll try and talk about what I did to make Dreambox.
The thing with Dreambox is that I started with a strong idea of what I wanted it to feel like, and what kind of capabilities it should have, and from there started trying to answer more specific questions (like, "how do people make Dreambox games?" -> "they should be able to use native languages like C++ or Rust to make games", "how should playing a Dreambox game work?" -> "games should be bundled into single files that users can drop onto the Window to play", "what 3D capabilities should Dreambox have?" -> "developers should be able to submit vertex-colored and textured geometry, but no shaders or render textures").
From there I guess I just tried to narrow down exactly how each of those worked. Like, I knew I wanted people to be able to use C++ or Rust, so I decided on using WASM because both of those are relatively easy to compile to WASM and there are ready-made runtimes I could use to execute WASM code so I wouldn't have to spend too much time on that aspect.
For Dreambox I also picked an environment I was very familiar with, so it's written on C# and FNA3D as I am very familiar with both. This reduced the amount of effort I was spending learning something new and made the development process go faster.