Hello, g’day and howdy-doo!
I’ve created this topic to have a space where I can post cool things I’ve been working on in Exray. This initial post isn’t going to be empty, far from it. It’s gonna be how things have been going from 0.6.0 → 0.7.0 (wip), the Raylib update from 5.0.0 → 5.5.0 and a bunch of other junk that’ll razzle and perhaps even dazzle your neurons.
So to start things off, yesterday when I posted the initial “Here’s Exray” topic, about an hour later Raylib shadow-drops 5.5.0. The important changes are mainly for WebAssembly build targets, which made my brain itch a little. I had a look at the current pipeline for Exray and noticed things were looking a little static. Mainly, the precompiled binary blobs which Bundlex uses to generate compile-time OS dependencies. Sure, I could leave it as the stock standard PLATFORM_DESKTOP with no Raygui, no custom frame control and no real options for customization- Specifically in the direction of optimization and logging. However, I decided to take a little bit of a different approach as an experiment.
So the exray pre-precompiler was made. It’s early stages, but the idea is that people can fork this project, build Raylib to their exacting specifications and upload a release tarball to their git. Then, in functions I haven’t written yet, be able to hand args to the Compiler.Exray mix task for the custom URL. This will let people use whatever flavour of Raylib they want, even stripping out all the functionality and just having Window functions and Raygui in an ANDROID build target. Or even the N64 as a build target, I think- Raylib added new targets. However, actually packaging that to hand to an N64 is a totally separate issue which I won’t dive into because I’ve got other priorities.
I tinkered with Livebook and to my absolute shock it actually compiled and ran. Granted, it took a little strong arming to mock a project definition into existence, but I figured it out in the end.
Here’s an example .livemd where you can just open and close a window. Nothing fancy, nothing un-fancy:
Livebook MD Source
# Exray Livebook Testing
```elixir
Mix.ProjectStack.start_link([]) |> dbg
Mix.State.start_link([])
Mix.TasksServer.start_link([])
defmodule ExrayLivebook.Project do
use Mix.Project
def project do
[
app: :exray_livebook,
version: "1.0.0",
deps: [{:exray, "0.6.0"}],
compilers: [:exray] ++ Mix.compilers()
]
end
end
Mix.Task.run("deps.get")
Mix.Task.run("compile.exray")
```
## Open and close a window
```elixir
import Exray.Core.Window
if not window_is_ready?(), do: init_window(500, 500, "Hello World!")
```
```elixir
import Exray.Core.Window
if window_is_ready?(), do: close_window()
```
When I created that livebook and I closed the window twice, knowing it’d crash, I decided it was time I started wrapping the unsafe C in safe C. This has led to me writing out unit tests on expected functionality for the Core modules, ensuring that instead of always returning an :ok we in some instances want to return a :noop due to the fact we’re not running the NIF as expected. For example…
alias Exray.Core.Window
alias Exray.Core.Drawing
# We haven't initialized a window. Let's call begin_draw()
Drawing.begin_draw()
#> :noop
Window.close_window()
#> :noop
Window.init_window(200, 200, "beans")
#> :ok (window starts!)
Drawing.begin_draw()
#> :ok
Window.init_window(500, 100, "toast")
#> :noop
While the last Window.init_window call returns :noop, I’m looking into ways to increase the ability to make Raylib more distributed, so we can call Drawing, Cursor, Keyboard, physics updates and animation stuff from GenServer which calls back to the main window process with what it’s got.
In summary, busy day. Learned a lot, had a lot to share and this topic is where I’m gonna just scream into the void with out-of-the-box solutions to problems nobody has.
Replies welcome and encouraged! 
