Hitting compilation during runtime is avoidable in julia. It’s really just a question of how the engine is implemented.
2 Likes
That’s really just part of the problem of shader compilation. Shaders have to be compiled for the player’s hardware, and it is only possible to do that once in advance for standardized consoles. So shaders give PC games a similar tradeoff of JIT latency vs long loading times, though the compilation is otherwise very different from Julia’s. The middle ground is caching compiled shaders so you can load them instead of compiling them again, but it’s still a WIP. The Hi-Fi Rush link says PSO caching was the tool they used, but the article does point out that it’s not perfect and doesn’t work well for another developer’s projects.
Maybe people’s work on shader caches can inspire Julia’s precompilation. Caching shaders is more incremental, while Julia’s precompilation or PackageCompiler is more all at once. On account of multiple games competing for the cache and combinatorial explosion of shader variants, there can be too many to store all at once, hence why clearing a shader cache is a step in some troubleshooting articles. Maybe someone’s solution to prioritizing cached shaders can be utilized for Julia’s precompiled code.
Yes, it’s a quite solvable problem though. E.g. proton on Linux has done great work on resolving shader compilation that’s now being copied over to various game engines.
Honestly, I think the trouble with making a game engine in julia would just be the usual problems with making game engines – it’s a gigantic, hard, and expensive undertaking that requires a huge amount of engineering effort.
If anything, I’d guess that one of the biggest hurdles wouldn’t be technical but social. How and why would someone hire game engine designers and convince them to create a brand new engine from scratch, and do it in a language like Julia?
2 Likes
Any details? I did read about fast pipeline linking + background optimizing-compilation in Vulkan, but not sure if that’s what you’re mentioning. Also not really sure how that could be translated to Julia’s compilation, maybe some sort of interpretation/threaded compilation thing.
100%. On top of that, there’s a massive amount of code reuse and wrapping in “new” software. Why rewrite perfectly usable C code in Julia if it’s only going to be used on the same few numerical types, might as well put that effort into a wrapper (e.g. PortAudio.jl). Like I said though, it’s still worth making all sorts of new libraries available to Julia users, even if it doesn’t yield a full game engine soon and they’re not written in pure Julia.
For a pure Julia project, maybe adapting Julia for game scripting as you mentioned? Not sure how feasible it is for solving a two-language problem, though. Lua is useful precisely because it is lightweight and embeddable, whether interpreted or JIT-compiled. I don’t know if Julia can serve the same purpose without sacrificing features and optimizations too much.
I think gaming client using julia would only become realistic after gaming server backend has already been good practice in julia, while even the latter isn’ t happening soon. So I feel a way to push this is to enhance networking backend libraries in Julia, optimize memory and concurrency to limits.
1 Like
Why make a new game engine? Well, because some disagree on principle and want to make a new game engine. As for shaders… Oh well… it’s different from Julia’s code. Shaders are once per object. Julia codes are a few times per function. Why make a new engine? Well, a new different principle? Maybe it would be a good idea if there is an idea that deserves a new engine.
I do have some issues with current games being big/cosmetic objects floating around. Maybe I’d want to try an engine based on a large number of simple objects/particles instead. Well, that’s just an idea.
Games have been here for a long time and the triangle-based rendering has been with us forever. Now that they’re sub-pixel level small, maybe they’re no longer the most efficient way to represent objects. Maybe someone could make a new game engine from the first principle?
My idea of a game is an interactive simulation. As for now, I see current games as a bunch of crude hitboxes with cosmetics.
Still… I don’t know what it takes to not only create a new game engine, but a game engine from the first principle.
I think Lua is the right target to consider here. The main application for Julia would be for what Lua is currently doing in this space. There are potential benefits if we can outperform Lua while also bringing multiple dispatch and composability. Performant modding could a lot easier to access.
1 Like
I’ve always been kind of attracted to real-time rendering of simulations, which is almost exactly what games are, and in the past I’ve worked quite a bit on Glimpse.jl. It’s a 3D rendering engine that’s quite flexible and based on ECS through Overseer.jl.
I’ve not yet found the time to write documentation, finalize the api and publish it, I think it is not a bad starting point for some engine kind of work and I’d be happy to put some effort into polishing it if there’s interest. The examples can give some idea on how it would look.
That being said, I think Julia can totally be used for game dev, but again, there’s a lot a lot of infrastructure out there in different languages and it simply takes a lot of effort to get that type of infrastructure going from scratch.
3 Likes
Well yes, you can write a wrapper. Ccall is very efficient in Julia, though it should support how Julians do things, for example, I’d think the Julian way of doing graphics might not be to have whatever custom screen buffer type and prefer a simple 2-d array which can be fed either to the screen, a game AI’s neural network, etc…
Let’s shift the question a bit. What are game engines? Game engines are collections of tools needed to make games such as physics, shaders, scripting, etc… There are a few things in the Julia ecosystem such as physics simulation, modeling, and geometry libraries/etc may also exist. Many game engines are monolithic, coupling the GUI editor, runtime utility, etc in one system, but it does not have to be. We can make a Julia game engine by bundling relevant packages together. I’m asking whether or not the Julia ecosystem is ready (has enough relevant packages) to start assembling a game engine.
Yeah, looking into it in more detail, it seems that what I was recalling is that Vulcan has some fancy stuff for compiling the shaders during game installation and then loading them faster than DX12.
The reason I was thinking of Proton is that Proton runs DX12 games through a translation layer and then runs them in Vulcan. The reason I remembered this was that Elden ring launched with some pretty intolerable shader compilation issues on Windows, but on Linux Vulcan was mostly solving the problem with stuttering due to compilation (though it had some other issues at launch).
So maybe or maybe not directly applicable stuff to julia, but still. I think that things like this are already being worked on and explored pretty agressively in julia for non-gamedev things just because people are trying very hard to overcome Time-To-First-X and Time-To-Load problems. I maintain that by the time someone actually managed to make a big ambitious 3D game engine in julia, technical shortcomings wouldn’t be the blocking issue.
1 Like
3D scanline rendering (still mainstream I think), is mature, but ray tracing (or path tracing) is not mature(?), which is the future. Or NeRFs. Computer graphics is developing very fast now with neural network tech.
There is GitHub - eigenvivek/NeRF.jl: Neural Radiance Fields (NeRFs) in Julia. but it’s not the Julia package I had in mind, or I recall a cool video in the README.
Yes, but getting better (e.g. precompilation), or almost solved? While the problem with ray-tracing is traversing (and maintaining) a tree. Not really a problem or setting it up, but in a dynamic scene things move about so I’m not sure the tree stays the same (or only some parameters in it change, rather than nodes being dropped). Adding nodes isn’t the problem, rather the GC activity when dropping nodes or any heap-allocated structure, and traversing the heap/trees. I recall tree benchmark in the Debian benchmark game an exceptionally bad example (maybe it’s better in 1.9.0, haven’t checked yet). Most other code is fast.
No one mentioned it, but Makie.jl is already pretty much a game engine:
Our interactive visualizations for science are getting pretty close to games these days… so we’re building all the tools by accident. But packaging will be the problem.
18 Likes
Can you expand? Do you mean in terms of shipping a binary? Or packaging dependencies?
If that the former is solved, I think the dependency management of Julia would be an enormous strength (as it is for scientific computing), especially with infrastructure like BinaryBuilder.jl
Julia is just famously bad at making small executables. We have PackageCompiler but it needs the whole julia runtime.
For game size these days that might be irrelevant? but it would still be nice if someones indie demo wasn’t 300mb minium. Once you add Makie.jl and precompilation it will be much larger…
(I think dependency management would be pretty good, as you say, and would just build into the package compiler image)
3 Likes
I think this is true for the most part, for the same reason Julia developers are okay trading off computation time for disk space with the new precompilation mechanism in 1.9. Space is cheap!
That does come with the (admittedly large) exception of mobile game development, where application size has strong inverse correlation with installation numbers.
2 Likes
This post got very long before I found it, so sorry if this was already mentioned, but re: you need a GUI to be a useful engine, the Godot engine supports multiple scripting languages.
I have no idea how scripts interact with the engine, but I have to assume there is a standard API if they are already multi-language.
If some of the other ideas here got figured out (GC, precomp, etc) then we could probably piggyback off Godot to flesh out a “full engine” experience and incrementally build out Julia’s capabilities in the space if the goal is a pure Julia solution.
1 Like
Yes, rather large, by default but solvable. You can drop the largest dependency LLVM (and e.g. BLAS likely), since Julia now precompiled to native code and you just want to make sure no code is left out. So depending on what you mean by “whole runtime” that’s just not true, I’ve also cut down the sysimage by half.
With games already pretty large (and in one case in petabytes, but on server side, latest flight sim streamed), I wouldn’t say this was Julia’s largest problem… Well, maybe poor choice of words since yes large, and extra. Game engines are likely very large already, so what’s the minimum size for Unreal, Unity or Godot based games now? Julia is extra unless the game engine can be wripped out in part or in full as in Miner.jl example. How does its size compare to the otherwise comparable Minsweeper (with its Java installed)?
For Godot:
You can mix languages, for instance, to implement demanding algorithms with C or C++ and write most of the game logic with GDScript or C#.
So you could have e.g. GDScript (reference count, no tracing GC) for game logic (Julia doesn’t really provide much benefit for non-speed critical code), and StaticTools.jl for tiny Julia libraries for some code, instead of C++ (or C#), and it would be faster or as fast. Right now StaticTools doesn’t support Windows (I think it should be easily solvable, someone just has to work on it, make it a priority, for this or other reasons).
1 Like
Miner.jl will probably be over a GB with GLMakie.jl and all its dependencies precompiled + julia. You might have a hard time getting rid of LLVM from it.
Its a nice solid challenge tho: Make Miner.jl as small as possible! Maybe I will be surprised.
StaticTools.jl for julia core would also be great, but its still pretty much a toy and doesn’t have many dev hours going to making it a real thing.
What we want at a minimum for 2D or 3D game is Windows (since most common) and Linux support (most developers). I do see for one of the games (macOS also important):
Unfortunately, this game (and SDL2/Gamezero in general) do not work very well on Macs with Retina screens.
Could someone investigate, is it really about SDL2, i.e. out of our hands and/or held fix that. We want GameZero to work on macOS too, by some fallback non-SDL2 support, or replace SDL2 for all platforms. It’s for 2D games, something Julia should aim for solid support first. Good 3D games are a higher target for Julia, and less realistic (i.e. the advantages of game engines are even more there relative to Julia).
Mobile games, or any mobile, is even more far off for Julia. It would be nice if someone worked on it, at least for Android, if not iOS too. I don’t see it as a realistic target yet, but do people consider it a priority to support all platforms, and then what consoles too?