Hey all,
I discovered Elixir and I love it. I always wanted to learn a functional programming and I intended to go for Haskell, but after discovering Elixir, I think I will spend a lot of time learning it well. For web development seems to be a great tool.
This is just out of curiosity, more than a practical question, but I want to understand the limits of this technology.
Can you make games in Elixir and deploy them on client systems?
I know it works in Erlang Vm, but I suppose the VM can also be installed on the client. But can Elixir render rich graphical content and use graphical resource?
In theory, you can use erlangs :wx module to have GUI, you can even do OpenGL, but to be honestā¦ Donāt!
The interface to :wx and OpenGL through erlang is very clumsy, because a multi-layered inheritance graph has been hammered down into a single behaviour. Mixed with a kind of mutable state that feels foreign in erlang/elixir, its no fun at all.
Also OpenGL is plain OpenGL, not the cool helpers which make OGL āaccessibleāā¦ Many of the very useful helpers are missing and you need to rebuild them yourself.
Also there have been versions of SDL for the BEAM, but AFAIK they are all abondoned.
So I wouldnāt suggest to build the client with āpureā BEAM technology.
What could work though, is to build logic in the BEAM and also have a āPortā which communicates to another prgram which deals with user interaction/communication.
You can use any language you like for that interaction-Port.
You might probably require two different run-time systems on the clients computer. The BEAM and maybe the one for the Portā¦
And at the end of the post, I do remember, that @Qqwy or @OvermindDL1 planned to make a GUI package on top of a FRP-framework he build himself, but Iām not sure who of those twoā¦
Perhaps you can build on top of that if it is already ready to useā¦
Yes, I was busy building a Functional Reactive Programming wrapper on top of :wx, but it is quite the ambitious project, and I have not been able to devote a lot of time to it lately.
There is also a QtQuick bridge that would be pure awesome if it works well. I havenāt had time / motivation to try it out yet, but QtQuick is a declarative UI system that is absolutely fantastic (ok, I am biased: I worked at the company that made it, and was involved with its evolution in the first several years) ā¦ itās like what HTML5 should have been
Thank you for the answers. It helps being able to have a view of what you can and can not do with a thing you plan to learn. So far, I love Elixir, and plan to learn as much and as fast as I can. I will focus on web development, as I already do at this point in PHP and JS. The reason I asked is because I hope one day I will be able to build apps that do not need a browser to run. But is clear that I have a lot to learn until then. Maybe by then, the ecosystem will have more tools. At this point I donāt feel that confident to be the one to make any of them.
Which IMHO is very, very unfortunate. BEAM languages, especially Elixir, would be amazing to write client applications in if there was a good rich GUI facility. wxWidgets is not that (just look at the fun the last weeks on the erlang list about this!), but one can imagine such a thing existing. The lack of a good modern toolkit is one of the last things that holds the BEAM forever on headless services.
Concurrency is absolutely huge for modern GUI applications, something weāve been working around for the last couple decades with one hack or another. Threading is a nightmare, so it is often faked with event loops and async I/O to varying degrees of success.
Good, modern UI toolkits put as much of the UI as possible in threads (QtQuick does this in several ways, as well as putting as much on the GPU as possible) leaving the application code to languish in yesterdayās development paradigms. It would be absolutely wonderful to be able to develop rich client applications with a language that gave you good concurrency out of the box. The other benefits like FP rather than OOP and all the other bits and pieces would be the icing on the cake.
If you like to do some functional web client I think Elm might be a nice option.
If you would like to create an installed client you could take a look at Arcadia. It is built on top of unity so for more serious projects it is nice to be able to leverage all the features off a fully fledged game engine.
Both of which could be combined with an elixir backend ofc
Iām not planning writing game yet, but I heard about some topics related to it. Probably the most interesting was Vulcan API. Do you know if there is any possibility to āconnectā features from Elixir world and Vulcan API?
Todayās CPUs (also in mobile devices) have lots of cores, for example 8 cores is not something new. I think that it could be awesome to have game data processing and process managing in Elixir and combine it with Vulcan API. Last time I saw a card game in beta version that does not loaded images for all cards and really fast I got idea like: Here Supervisor would be just perfect!.
And think about that ad: First game that could use full power of your CPU! It's written using Elixir and ...
Vulkan (not Vulcan) is significantly lower level, manage your own memory and all, and very unforgiving for errors. Overall you will not get much of a speed difference if any between well written OpenGL and well written Vulkan except in a few very specific cases. Mostly Vulkan is just OpenGL cleaned up of itās ancient cruft.
Eh Iāve already been doing so in C++ (custom engine) and Rust (amethyst, new engine). ^.^
Elixir/BEAM would not be performant for a client, at all. Maybe as a scripting layer, but not much beyond that at allā¦
Yes, I always make mistake here, because some words in Polish with k letter are translated to English equivalent word with c letter.
Yes, but it started with excellent support. For example OpenGL drivers from AMD (at least for my old GPU) are ā¦ I heard that implementing Vulkan makes them much more fast rather than old OpenGL drivers that probably needs a good rework, but I donāt have so much time to test it.
Why not? Can you say something more? I think that some groups of games could have Elixir parts without problem:
# 1. If there is something that needs as much CPU power
I know that we canāt say that ā¦ language is x times slower than ā¦ language, but we can assume some things, just for example:
This ā¦ game part is from 5 up to 10 times faster in C++ than in Elixir. So letās say that Elixir have 1 point and C++ have 10 points. But all of that happen in only one thread, so if we have 8-core CPU then C++ still have 10 points, but Elixir have more: 1 * 2 * 8 => 16 i.e. 1 point per each thread.`
Of course itās not so simple to say, but something like it.
# 2. Network things - imagine that our game allows multiplayer mode, so it could be client as same as server. Each Elixir process per connection with player should work well.
# 3. Supervising processes
If something goes wrong when drawing then we could restart drawing process (Vulkan port) and initialize it again that redraws specific area.
# 4. Simple website editor for creating new cards
I said something about card game. I donāt believe than C++ will have much more FPS that Elixir also in 1 thread for this case - not even talking about 8-core CPU here ā¦
What we could have there?
Options + files (load & save settings)
Network things (client + server code)
Process for each player and card for storing stats and do simple math (damage, health etc.) + listener for events - i.e. simple game engine (not draw engine)
Supervisor for managing drawing process + communication to Vulkan - i.e. change health => call draw another integer in card
3rd-party libraries for example for OS notifications and similar also really small things
All hardest things here are rendering and animations.
I can understand that in some cases there is need to use pointers to memory and other low level things, but I donāt think that itās so bad for some types of games or maybe I missed something?
There is a word Vulcan in English, just in this case the spec is named Vulkan, yes it is weird. ^.^;
Theyāve gotten significantly better in recent years actually.
The utter and sheer amount of data that has to be sent to the GPU I could not see being done efficiently via BEAMās message passing. Perhaps updating a rendered scene state in a native code world via the BEAM would work, but the act of rendering itself and all the synchronization points (āFlushesā in GPU parlance) that have to be serialized would never allow it to perform anywhere within a factor as well as native code.
Maaaaybe if you make NIFās and program them very carefully would it work somewhat decent. But even then keeping the rendered āstateā and just sending over changes to native code would be significantly more efficient.
This is one of those cases that is very CPU/Memory bound, which the BEAM is not suited for.
I honestly think that even 5 to 10 times faster in native code is being kind, Iād really honestly believe that except in very simple demoās that it will be multiple orders of magnitude type difference, which is the difference between a smooth 60 fps and getting 2 fps.
Network would be awesome on the BEAM, that is what it is practically designed for after all. ^.^
However using those network packets to do things like, oh, handle Physics processing or so forth, that would fall flat again.
If your GPU code is crashing then depending on the quality of the drivers you will crash the entire OS or just have a significant speed hit as the rendering pipeline has to be flushed and cleared (Iāve seen stalls of this routinely cost well over 1 second per frame, which drops you to <1fps instantly). GPU coding has to be done right or it is not a ācrashingā issue but rather you become unplayable just because the hardware has to reset its state.
This is generally done once, so it does not matter where it is done.
This itself is fine on the BEAM, but what is done āwithā those packets may not be.
Itās not just the player but the entire world that you have to simulate, this is hugely CPU bound and will not be done well in the BEAM except for absolutely trivial scenes.
This will not be done well on the BEAM. A draw call to the GPU can be batched up in command buffers and so forth, but they have to be flushed at times and at certain points and these are absolutely timing critical (micro-second kind of critical to the hardware).
Eh, notifications and such are pretty trivial.
Some ātypesā sure, like a card game would not matter for sure. Potentially even something as complex as a 2d shooter becomes infeasible unless the object count is kept extremely low.
I donāt know if I understand you correctly. You are talking about bigger games where there is a number of things that could change small detail and therefore make huge affect on computations, right?
Originally I think about 3 steps:
Elixir as a master process - like website backend that simply manages data. I donāt want to integrate Elixir with JavaScript, HTML and CSS - just use multi thread ability and if there is really big performance problem then optionally:
1.5 make a NIFās for lower-level language, but I donāt see that is really needed (of course it depends on how much data we need to process and how fast). Anyway it could be possible to manages NIFs to run computation on all cores/threads instead of one - like in normal games, right?
Btw. one time I have a network problem and I was need to save data (that I normally fetches from sites) and I saved them to file using :erlang.term_to_binary and was surprised how fast it reads really big files back to Elixirs types and Iām working on really old laptop that is not recommend for games from release date. So here I believe that Elixir could make lots of awesome things also for at least some games ā¦
A library/framework or something like graphic engine that connects Vulkan with Elixir by NIF instead of try to use Vulkan API directly in Elixir (I donāt need to be expert to know that itās bad idea) and therefore donāt force Elixir to make any graphic work - just manages and process information data that will be directly used in framework as argument to draw specific things.
Finally Vulkan API that makes as much as possible work on GPU.
If we are still in topic ā¦ vs ā¦ then if so itās 30x bigger fps, so we only need 15 (60 / 2 threads / 2 fps) core CPU to have similar results in both cases - of course itās not a gaming CPU, but itās really not a problem for todayās technology.
Hmm, you are talking about sending rendered image? I donāt think that sending informations about changes on map is a really big problem especially on better PC setups with fast SSD.
# receive opponent moved, shoot and destroyed one item in map
# process required information
Framework.send_data_to_render(data)
Oh, thatās what I donāt expected. I know about drivers, but not whole GPU code, wow. +1000 respect for all people that works on GPUs.
I can understand that working on GPU form Elixir to create game like GTA V could be a little () problem, but I think about something really other.
I believe that for all 2D games Elixir + NIF with Framework + Vulkan/OpenGL should work really well and here Elixir should not be close to use whole CPU power. We probably are talking about different solutions. I believe that there is not much data in really big number of games (also 3D).
Problem begins when we need to have calculate position of every body on map (not just simple movement with jumping, but also move by explosions and more) and in second case where we have a really big number of data to manage like in games with open world.
I donāt think to make a clone of Unreal Anthology in Elixir, but what Elixir offers should be too much for simpler cases like clone of M.U.G.E.N., 2D mob games or card games.
More cores rendering will not increase FPS like that. You can only use multiple cores to build up multiple CommandQueues, but even then executing those is serial and that tends to be the slowest part, not the building of the CommandQueues (except for some very exotic work that almost no game does at all). Extra cores can improve rendering by loading, say, multiple textures at the same time to the GPU, but the actual rendering will not be helped by more cores at all.
Yeah, I forgot about serial - here was my mistake. Now I see what you are trying to say.
So with Elixir we can optimise some parts of every game, but not rendering part. From what I heard developers already achieve what they should (I mean here about OpenGL/Vaulkan), because rest heavy depends on hardware + drivers + of course whole code quality.
Thanks for explanations!
Uh, not really? That is just a port mapping library (which you can already do in straight OTP/BEAM without libraries) to an external app that you have to build? ^.^;
So, ErlangVM already supports that by nature? So I guess this project was started before?
Anyway, do you think it will work? Here is a more expanded view on this:
