00:00:28.960
Hello everyone! That was me trying to say hi.
00:00:39.559
I'm back and I'm so happy to be here. I was here four years ago for RubyConf Taiwan and I presented on running mruby on Dreamcast back then.
00:00:46.680
This time, I'm back with my Dreamcast. I don't want to lift it too high because it's all connected, but I brought my spare Dreamcast and my Nintendo Wii.
00:00:52.440
I'm really excited to share my work on developing cross-platform mruby software for Dreamcast and Wii. First of all, I'd like to apologize.
00:01:01.120
I had hoped to run the entire presentation from my Wii, but I encountered several critical bugs that I couldn't resolve.
00:01:07.840
I tried to fix them up until earlier this week, and I decided it would be better to present from my MacBook instead.
00:01:12.960
While this means the presentation is being shown from my MacBook instead of the console, it's also a lot nicer to read as the screen output is more eye-friendly. I'll still show you what I've got running on the Wii at the end of this presentation.
00:01:30.960
I believe that sometimes we need to be ambitious. If we never fail, we're probably not trying hard enough. Although I didn't quite achieve what I wanted, I hope you'll still find this presentation enjoyable and interesting.
00:01:42.360
Here's a table of contents for my presentation: I will talk a little about myself, discuss Dreamcast and Wii, explain mruby, cover the motivations behind my work, discuss the similarities and differences between Dreamcast and Wii, and share insights about the development process.
00:01:56.400
I'll also address the challenges I faced and the changes that were required in both C and Ruby code. Finally, I hope to demonstrate my working software and conclude with a summary and useful links.
00:02:10.399
About myself: I'm Yuji Yokoo from Tokyo, Japan. I grew up in Tokyo and have been living in Adelaide for about a decade. However, last weekend I started moving back to Tokyo.
00:02:18.040
I have packed up my townhouse in Adelaide, but I still don't have a permanent address in Tokyo. I currently work for Cipher Stash, a startup in Sydney that focuses on database encryption technology.
00:02:29.519
If you're interested in encryption technology that enables data lookup, please come and speak with me. I mention this as they are my speaker sponsor, even though today's topic is unrelated to their work.
00:02:39.320
Now, let's talk a bit about the Sega Dreamcast. I have a fondness for the Dreamcast for many reasons; I believe it's one of the best video game consoles ever made.
00:02:50.080
Released in 1998, it features a Hitachi SH4 processor running at 200 MHz with 60 MB of RAM and a GD-ROM drive that allows for about one gigabyte of data storage.
00:03:01.120
Except for the later revision consoles, all Dreamcast units can run custom code by just writing a specially formatted CD, meaning no exploits are needed.
00:03:10.399
This feature has facilitated the continued release of indie games, and I recently purchased a game disc called Driving Strikers, which was released this year for Dreamcast.
00:03:19.680
Now, let's move on to the Nintendo Wii. Released in 2006, it was not particularly powerful compared to other consoles of its generation, but Nintendo chose not to compete in processing power and graphics.
00:03:27.599
The Wii features a 729 MHz processor and significantly more RAM than the Dreamcast, indicating a considerable difference in capability.
00:03:38.879
Interestingly, it comes with an SD card slot, but by default, it does not allow non-official software to run unless properly released.
00:03:48.000
However, there are several easy exploits available.
00:03:50.880
For example, I previously used an exploit on the Wii called Smash Stack, which uses vulnerabilities from the Super Smash Brothers Brawl disc.
00:04:01.120
More recently, I employed another exploit called Letter Bomb that involves using a specially crafted message file saved on the SD card and opened in the Wii’s message board.
00:04:10.600
As a result, exploiting the Wii is relatively easy, but no one can produce a self-booting disc for it unless they are a proper manufacturer.
00:04:20.520
Now, let's briefly talk about mruby. Many of you are likely familiar with mruby as it's a lightweight implementation of Ruby.
00:04:28.720
If you're not sure which implementation you're using, you're likely using CRuby, so know that alternatives like JRuby and mruby exist.
00:04:39.159
Mruby is designed for embedded systems and integrates well with C programs.
00:04:45.760
Since 2012, mruby has supported Dreamcast out of the box, including a build configuration file for Dreamcast.
00:04:54.640
And just this October, it also received a build configuration file for the Nintendo Wii, allowing for library development with only one command, provided you have the necessary platform software installed.
00:05:06.759
Now let’s discuss the motivation behind why I pursued cross-platform development between Dreamcast and Wii. The Wii was an incredibly popular console, selling over 100 million units worldwide, which is impressive.
00:05:21.480
Given that the Wii is a more recent console, many units likely remain unused, providing an opportunity to reach those potential users.
00:05:34.120
If I can develop software that works for both the Wii and the Dreamcast, I can significantly increase the number of developers working on Dreamcast projects.
00:05:41.799
The ease of exploitation is a significant factor, but perhaps the most compelling reason is that I have a Dreamcast at home.
00:05:57.120
As I mentioned earlier, there are many differences between Network architectures, but there are also similarities.
00:06:06.600
Both platforms have free open source SDKs and use GCC, which makes them good targets for cross-platform development.
00:06:12.400
Kalisto is the development environment for Dreamcast, also known as Chaos, and it provides access to file system control, I/O graphics, and other features.
00:06:23.839
Devkit PPC is geared towards PPC, providing GCC and linking tools, while libogc is a low-level library for Wii and GameCube.
00:06:33.320
Even though libogc is not very feature-rich, many libraries are built on top of it. Devkit PPC and libogc are designed to be used together.
00:06:40.199
In commercial software development using libogc and devkit PPC, you may need to carefully check the licenses as they differ.
00:06:47.559
Now let's look briefly at the development process. To get started, you need to write some C code, which performs platform-specific initializations.
00:07:00.440
This C code will set up mruby, define classes, attach functions, and load your program.
00:07:08.479
Once the loader is complete, you can write the actual Ruby code. You'll define your top-level Ruby file that utilizes the modules specified in the C code.
00:07:24.080
As you develop your Ruby application, you may find the need to write additional C code to access hardware features such as video RAM or controller states.
00:07:35.080
For instance, you will need to wait for a vertical sync (vsync) signal to keep the game running at a constant rate.
00:07:45.760
This C function typically returns a value that can be used in the mruby environment to maintain consistent timing in your game.
00:07:57.559
After writing your Ruby code, you will compile it and produce bytecode, which is a representation of your program in numerical format.
00:08:05.559
You don't have to understand the bytecode itself, but it's important to know that this bytecode is combined with the C code to produce object files.
00:08:14.399
These object files need to be linked against the platform's libraries and the mruby VM library to create the executable formatted for the console.
00:08:24.279
In most cases, even though the output is an executable, you'll need to perform an additional step to build an image required for the game console.
00:08:34.519
The tools provided with the platform SDK will assist with creating this image, which is necessary for Dreamcast; you can just burn it onto a writable CD.
00:08:50.959
I also have a modified Dreamcast that allows me to use SD cards instead of discs. When porting projects from Dreamcast to Wii, the goal is to use the same Ruby code across both platforms.
00:09:01.760
This can be achieved by ensuring that the Ruby API remains consistent, while the underlying C code must differ due to platform variations.
00:09:11.360
The libraries between Dreamcast and Wii provide different functions and data types, making it necessary for the C code to be adapted for each platform.
00:09:21.120
Sticking to common features such as screen resolutions is crucial, as each console can have many different video options. Settle on one common resolution to avoid unnecessary complexity.
00:09:32.920
Also, sticking to common interfaces simplifies the process. For example, while Wii features motion control, I chose to use a GameCube controller as it has more in common with the Dreamcast controller.
00:09:44.160
Now let's discuss some challenges I faced, particularly with the Dreamcast environment: many development tools assume usage of a Windows machine with an Intel processor.
00:09:54.479
While it is possible to run tools on other environments, such as Apple Silicon, porting 32-bit Intel Windows applications to an M1 MacBook can be challenging.
00:10:01.199
Additionally, my recent move from Adelaide to Tokyo caused issues, as I packed up all my Intel machines, which made the situation more complicated.
00:10:11.839
Moreover, many of the development tools I had were from 2003 to 2005, which resulted in numerous broken links, but thankfully, I found resources on archive.org.
00:10:23.160
Many tools are distributed as binary only, with no source code available. Therefore, tracking down the sources of problems can be very difficult.
00:10:30.079
Also, a lot of these binary-only tools are unsigned or outdated, meaning they may not run correctly, adding to the difficulties of debugging.
00:10:41.159
I encountered a lot of obscure issues that were hard to diagnose, as every bug is mysterious until identified. This led to a significant decision not to proceed with presenting directly from the Wii.
00:10:50.760
Additionally, the debugging process is complicated on actual consoles, providing little visibility into internal operations.
00:11:03.080
Setting up a proper debugging environment has proven difficult; I attempted to set it up multiple times without success.
00:11:13.720
Now, let's highlight some changes I had to make in C code. These were primarily header and platform-specific changes.
00:11:23.560
The exact details might not be crucial, but many changes were necessary in the C code, reflecting a considerable amount of adaptation for the project.
00:11:34.879
Interestingly, one notable change involved using the Chaos library's drawing functions compared to those provided by libogc for the Wii.
00:11:45.240
The Dreamcast approaches handling pixel placements at a finer level while the Wii relies on a coordinate-based system using column and row specifications.
00:11:55.639
Additionally, on the Dreamcast, each pixel is packed in a 16-bit format with a ratio of 5 bits for red, 6 bits for green, and 5 bits for blue.
00:12:05.520
In contrast, the Wii encodes pixels in a YCbCr format, based on the historical method used in black-and-white television signals.
00:12:16.240
This adds complexity to the image processing since the Wii packs multiple color values into a single space, making it a challenge to manage.
00:12:27.520
After all these changes, you might wonder what modifications were necessary within the Ruby code itself. Fortunately, there were minimal adjustments required.
00:12:40.280
I removed certain methods that were exclusive to the Dreamcast and adjusted the class name in a few instances. Instead of the P method, I implemented a new method, print_message.
00:12:51.000
On the second page of the adjustments, I also changed how the resolution worked, switching from 640 x 480 to 320 x 480.
00:13:00.920
This meant that calculations involving horizontal positioning had to be halved as well. I also resolved a minor bug noted in the code that caused unexpected issues on the Wii.
00:13:11.120
Now, it's demo time! Will it work? I'm not very confident, but let’s see.
00:13:23.880
Good, things seem to be going okay.
00:13:32.000
Here’s my video capture from the Dreamcast version, which I demonstrated four years ago. This is not what I did this time but serves as a baseline to show you how the original game looked.
00:13:38.920
This is the SD card loader screen, and now I'm booting the actual game.
00:13:45.520
Here it is; the game works in this manner on the Dreamcast.
00:13:54.040
This is the baseline from four years ago, and I also scored one point for deleting one line of code. Now I'll connect the Wii.
00:14:01.920
Please recall how it looked on the Dreamcast previously. This is the replacement boot screen on the Wii, allowing me to proceed directly into my applications.
00:14:14.040
Here comes the moment of truth. If this looks like what you saw on the Dreamcast, then that's a success. And... we go!
00:14:26.960
Oh! Let me play until I can score and erase another line.
00:14:39.839
There you have it! I scored 100 points, thank you!
00:14:48.160
The demo worked fine on the Wii as well. Now, regarding future plans for this project, I want to address the API unification.
00:14:57.600
The horizontal resolution is currently reduced to 320, and I intend to change that to 640.
00:15:05.280
Unfortunately, I didn’t manage to get the presenter working on the Wii, but I plan to work on that in the future.
00:15:14.080
Additionally, my goal is to execute the same code across both platforms using a single source, generating binaries for the Wii and Dreamcast by changing parameters.
00:15:22.760
In summary, cross-platform development is feasible! The Ruby code did not require significant changes, as most adaptations were achieved through the C code addressing platform differences.
00:15:40.480
However, debugging remains a significant challenge, especially when navigating international moves and presenting concurrently.
00:15:50.320
I want to take a moment to express my gratitude to the mruby developers, the devkit pro team, as well as the Simon game engine Discord server.
00:16:00.480
There’s a wealth of useful information available for anyone looking to work with Wii, and I’d like to share the links at the end.
00:16:10.000
Also, this is the source code for my demo game, specifically the Wii version. Thank you very much for your attention.
00:16:20.000
Now we will move into the Q&A session. Please feel free to ask any questions you might have.
00:16:30.000
Thank you for your presentation. I'm curious if there are any plans to port mruby to more modern consoles like the Switch or 3DS.
00:16:39.679
Currently, I do not have specific plans, although I know others have ported mruby to the Switch.
00:16:46.799
I believe there was a past presentation on that topic, and I'm open to exploring that possibility in the future.
00:16:54.440
Regarding debugging, I found that when using the Dreamcast, I could utilize an emulator that allowed console output to print debugging information.
00:17:03.360
Unfortunately, I’m not aware of any equivalent emulators for Wii that allow for debugging in that manner.
00:17:10.000
So, I primarily use print statements in my code for debugging on the Wii.
00:17:16.600
I know there are tools that support remote debugging, but I haven't had success using those.
00:17:24.559
In short, debugging on consoles is tough, and I’m working on finding better solutions.
00:17:32.679
This session is almost concluding, so if anyone has any last questions, feel free to ask.
00:17:43.639
I appreciate everyone being here today. It’s reassuring to know that many people are interested in this topic.
00:17:55.279
Thank you very much for participating, and feel free to connect with me after the session.
00:18:06.399
With that, we will wrap up this meeting. Let's take a short break before the next session, which will start at 2:25.
