XaiJu
FruitbatFactoryDevelops
FruitbatFactoryDevelops

patreon


Making 100% Orange Juice Free From Windows

We asked our staff to geek out about something they've been working on. The following is a treatise by Rapha, who has been working on many of the under the hood changes to 100% Orange Juice, on the ongoing work to modernize the game engine. Please enjoy!

100% Orange Juice runs on a custom engine born from the underground Japanese game dev scene. This enigmatic engine was known by many names – Luna, Lune, Lue, Selene... a whole lunar collection! They just didn't name it Lua, probably because the language created by Ierusalimschy at PUC-Rio was four years old and well known at that point. It was created by Mr. Noriyuki Hiromoto, who over the years worked at SQUARE ENIX for Final Fantasy 14 and today is CTO at Spark, a middleware company that helps companies create games like Blue Protocol, Soul Hackers 2 and... Final Fantasy 14! I guess some things never leave your life! You can find Mr. Hiromoto on Twitter at @hrmtnryk.

Our version of Luna dates to around sometime in the first half of the 2000s, it was originally a DirectX8 library, but was thankfully ported to DirectX9 around 7~8 years ago by the amazing Rive, one of the OG Fruitbat OJ Devs! It was old to the point of having shaders written in Assembly! But let's get back to the present day.

Seeing the code for the first time sparked a fire in me. While the official focus was on a future with Unity, I knew I could slowly chip away at the early 2000s-era Windows tech holding the game back, even if it became 100% Orange Juice Classic or something with the intended Unity release. This meant meticulously reorganizing code, swapping out small sections, upgrading the C++ standard, replacing code reliant on dated Visual Studio extensions, taking notes on everything needed for a more modern build and countless other considerations. After all, you can't just overhaul everything at once without risking unforeseen consequences.

It reached the point where stuff could actually be changed with some willpower around the same time Unity's bombshell announcement, last year, became the perfect catalyst. It was time to truly dive in!

For cross-platform C++ game development, there's a hero – the Simple DirectMedia Layer (SDL). Created by Sam Lantinga in 1998, SDL has become the knight in shining armor for developers weary of battling platform-specific woes like WinAPI or X11. It lets you focus on your game's magic, not the underlying system's intricacies. And with the right NDAs in place, even console ports become a possibility, further expanding your reach!

Taming the window and input system was the first hurdle. Some callback wrangling later, and voila – a streamlined codebase with fewer assumptions. Pretty easy overall if you knew every single place you needed to change the code.

Then it was time for audio! Originally, the game relied on Ayame, a library built for doujin games in the same way as Luna. Created by Kouhei Akiyama, it handled audio formats like Vorbis and WAV. It even had a fun quirk – it could sometimes force Windows into trying to play files unsupported by it! This creative workaround allowed some modders to use MP3s in the past. However, for the smoothest experience, especially with music that loops seamlessly, we now only support OGG files in mods going forward, please update your files! It's easy!

Kouhei Akiyama, is a bit of an enigma. Interestingly, there's a Kouhei Akiyama credited with numerous Capcom games from the 1990s. Could it be the same person? Would be interesting!

The initial hurdle? Ayame was a precompiled library, meaning we lacked the source code to break the game free of its 32-bit chains. This became a personal quest for me. After reaching out to anyone who might have a clue – a flurry of LINE messages and emails later – a hero emerged! Someone had unearthed a version of Ayame with some modifications credited to a Sazanta around 2006. With this, the game could finally shed this limitation!

And that was the beginning of a bug that is still unexplained to this day and may be until the end of time, because it was fixed indirectly. For around 2 years, the 64-bit version of OJ could get stuck on the loading screen, and that only happened when running the 64-bit version! Strange right? Thankfully, the audio switch began and proved as a fix. The new solution for audio chosen was SDL_Mixer.

Implementing it was a bit of a pain at first because Ayame used hard-coded sample points given directly to it for looping to work, and SDL_Mixer only supported it via metadata on the OGG files, but thankfully, through some creative (and probably not-to-be-repeated) solutions, the problem was solved. And after a lot of testing, it was definitely as similar as my ears could sense to the original.

The last challenge for audio, the files. Originally, raw voice files ballooned the game's size and took forever to load. Talk about a performance bottleneck! Background music was another culprit, stored in a strange, proprietary format despite being simple OGG files. It was time for a makeover! I swapped the voice acting to Opus, a codec specifically designed for speech, shrinking a whopping 2GB of data to a mere 200MB – impressive! The final touch: bundling everything – background music, voices, and sound effects – into a single, game-ready file. Bingo! Not only did load times plummet, but the pesky 64-bit bug vanished together with the old DirectSound implementation. Talk about a win-win!

With the audio revamp complete, it was time to set our sights on what we really set our sights on: the game's graphics!

Migrating a game with almost half a million lines of code from DirectX9 to OpenGL without going around changing the game code is a challenge, as DX9 and OpenGL represent fundamentally different design approaches. DX9 offers a higher-level abstraction, shielding programmers from some of the nitty-gritty details of a lot of things, like texture loading, model loading, etc. In contrast, OpenGL adopts a more do-it-yourself approach, it gives you triangles and nothing else.

While most of the rendering code is inside Luna, the way the game thinks ends up being DX9-like, the coordinate space, the way textures are projected, the way math is done, it considers blindly that the game is DX9. This disparity would translate to a significant amount of code rewriting, and a significant amount on 500K is HUGE. So porting Luna required careful translation, ensuring the new OpenGL calls achieve the same results as their DX9 counterparts. Even if a lot of converting was needed, it was worth the result.

After porting Luna, specific parts of the game that used DX9 directly had to receive alternatives for those code paths, and we finally got into the current state of things!

For now, 100% Orange Juice runs internally perfectly on Windows and Linux (this time natively) using OpenGL without many perceivable problems! We still need testers to confirm it completely, but as soon as that is done and the bugs that will probably arrive from that are fixed, everyone will be able to enjoy OJ without old tech!

Since we are targeting OpenGL 3.3, since that's more than enough to the current state of the game, computers and devices from around 2010 should still be able to run the game. And it opens a world of possibilities, some with specific caveats, but compared to the challenge up until now, they will just be simple stones.

Comments

Bravo, Rapha!! This is a really engaging read 👏 You can tell they have a passion for the way these games tick.

Logan McCarthy

Woah, for such a cutie and simple looking game, you'd think there wouldn't be so many issues. A well written blogpost, and quite a nice look under the hood of 100%OJ. Keep up the updates!

onic2999


More Creators