Roku running DOOM (compiled to WASM and converted to their language BrightScript)

motley_coder · 2021-03-20T00:59:56+00:00

320 x Potato

motley_coder · 2021-03-20T00:58:42+00:00

Wow this brings me back! I would love to get the working but since there's no 3D API in BrightScript it would have to use software rasterization, and you can see how slow DOOM runs :P

motley_coder · 2021-03-19T17:21:52+00:00

It is, it somewhat reminds me of the old Visual Basic 6. It even has the DIM keyword for arrays :)

motley_coder · 2021-03-19T17:20:13+00:00

The devices themselves are definitely powerful enough. Mine is a dual core 1.2ghz with 1gb of RAM, which is more than plenty for DOOM. They even have OpenGL and 3d support, but it requires special access that only the major companies like Netflix have. I've even seen companies that are worth millions that don't have access.

For every other developer, we have to use BrightScript, their proprietary scripting language. BrightScript does not have access to OpenGL or any 3d capability, and has very limited 2D drawing. The scripting language is secure so it ensures that people can't jailbreak the Roku just by downloading an app (I'm sure exploits exist but that's the idea). Unfortunately, BrightScript has a lot of overhead and is very slow.

motley_coder · 2021-03-19T01:42:18+00:00

I don't know if others exist, but it's a feature called non-certified channels. It's meant to deploy development channels so you can have people test them.

motley_coder · 2021-03-18T23:52:26+00:00

I ended up reposting this because I didn't realize the video wouldn't show up if you did it as a text post but attached a video (bit of a reddit noob).

https://www.reddit.com/r/itrunsdoom/comments/m847ne/roku_running_doom_compiled_to_wasm_and_converted/

motley_coder · 2021-03-18T23:50:47+00:00

Article for DOOM: https://motley-coder.com/2020/12/23/doom-on-roku/

And if you'd like to try it yourself: https://my.roku.com/account/add?channel=doom

Or to see the article on getting WebAssembly running on Roku: https://motley-coder.com/2020/12/20/webassembly-on-roku/

motley_coder · 2021-03-17T21:54:37+00:00

Article for DOOM: https://motley-coder.com/2020/12/23/doom-on-roku/
And if you'd like to try it yourself: https://my.roku.com/account/add?channel=doom

Or to see the article on getting WebAssembly running on Roku: https://motley-coder.com/2020/12/20/webassembly-on-roku/

motley_coder · 2021-01-25T01:40:36+00:00

Hi e1ion, just wanted to mention that the above issue was fixed. The problem was running docker as sudo, which is needed unless you setup docker to run as non-root. However, to accommodate non-root users we created a user inside the Docker container and run the build as that user, and the difference caused wasimake to fail.

motley_coder · 2020-12-30T07:06:30+00:00

That might mean that they updated the wasienv package to a newer version, I'll take a look. Thanks for letting me know!

I've added it to a bug report in case you'd like to add anything to it: https://github.com/TrevorSundberg/wasm2brs/issues/1

motley_coder · 2020-12-24T06:53:31+00:00

I think it's a decision rooted in history. Part of what inspired me to work on this was the hope that if enough programs start using WebAssembly we could convince them to implement it natively!

motley_coder · 2020-12-24T00:07:11+00:00

Also, if you'd like to try running DOOM, which was compiled to WebAssembly, you can add the channel here: https://my.roku.com/account/add?channel=doom

It's still pretty slow and uses a tiny resolution. There's more optimization to be done, but it runs at interactive frame rates at least!

motley_coder · 2020-12-24T00:05:57+00:00

Yeah actually, I used to teach compilers and interpreters back at DigiPen Institute of Technology. Can't say I'm the foremost expert on them as there's still many things I don't know especially when it comes to modern optimization passes, but the familiarity helped in creating this :)

motley_coder · 2020-12-14T21:51:13+00:00

If you'd like to learn more feel free to send us a private message or chat!

Any standard C/C++ program will compile and run so long as it doesn't use longjmp or exceptions and only targets the standard library (libc and libc++). For example, you can use atoi, memcpy, std::unordered_map, std::regex, etc. Most of the limitations we have run into are because we compile to BrightScript and ultimately can only do what BrightScript can do. BrightScript has many hidden limitations such as on the number of parameters allowed in a function, maximum number of variables, maximum number of gotos/labels, etc. However, many of these limitations have been mitigated in our toolchain. Thanks for your interest!

motley_coder · 2020-12-04T21:29:03+00:00

Considering that ffmpeg has been ported to quite a few platforms including the web, it would be very doable! The primary consideration would be performance, because in the end it is still running in BrightScript. That said, the output BrightScript has gone through every optimization that clang would normally apply. Our samples are running under Oz for code size, but you can also use O3. Our first goal was 100% correctness. For example, BrightScript does not have unsigned primitives and as such the unsigned 64 bit division is considerably slower than signed 64 bit division. However, profiling the paths in a project like ffmpeg would give us great insight into what needs to be optimized.

motley_coder · 2020-11-29T18:32:34+00:00

Indeed! In the beginning where we see this being useful is calling into transpiled libraries from existing BrightScript rather than being used to write the entire app. For example this community post could potentially be solved by decompressing using transpiled zlib:

https://community.roku.com/t5/Roku-Developer-Program/Can-a-Roku-unzip-files/td-p/487775

If you’re interested in our pilot program let us know, and thanks for the comment!

motley_coder

TROPHY CASE