itch.io

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)

Hm, maybe I scuffed something up when building. Gimme a bit and I'll try and see if I'm doing the self contained build correctly.

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:

1. You can drop the ISO onto the window
2. You can use the `--startcd [path/to/iso]` (or `-s [path/to/iso]`) commandline option
3. You can use the `--faststartcd [path/to/iso]` (or `-f [path/to/iso]`) commandline option, which is similar to startcd but also skips the boot animation

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:

Also, for what it's worth, a few useful hotkeys you may want to know:

• F1 ejects the CD and restarts the console
• F2 restarts the console, but does not eject the CD
• F3 ejects the CD, but does not restart the console
• F4 dumps loaded audio samples to WAV files for debugging

Good news, .NET has an option I can take advantage of called "self-contained builds" which means Dreambox should now bundle the .NET runtime instead of relying on it being installed. Maybe give it a shot and see if it works now!

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.

Try './dreambox' instead? (dot forward slash)
At least on Linux Mint, just typing 'dreambox' has the same effect, but './dreambox' works

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

I can look into it, but I don't have access to a Debian machine right now. I'm not super sure what would prevent the Linux version from running in Debian though for what it's worth, are you running into specific problems?

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.

It's because we're outsourcing the costs of our dastardly agenda. Truly terrible stuff, really, ranging from "eating food" to "paying the bills"!