OpenGL?

[David Parry]

Hi.

I dunno what others think, but Elixir would appear to be an ideal language for writing games in.

Any thoughts on what it would take to talk to OpenGL from Elixir?

Or does anyone know of an existing Erlang library?

I realise there is wxWidgets, but I can't really see that being a desirable goal for gaming. Or am I missing something?

[Augie De Blieck Jr.]

Looks like the last major attempt at this was with ESDL:

https://github.com/bjorng/esdl

But now the Erlang folks seem to agree on just going with wx...

Google also shows this project on Google Code, which is a framework
for using wx to make games.

https://code.google.com/p/erlworld/

(Google Code is still available? Who knew?)

It has actual games to show off the proof of concept, at least. Maybe
that's the trick -- someone needs to build the right framework to
utilize wx in an Elixirish way for game-making.

-Augie, not volunteering

> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-ta...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Parry]

Okay, thanks for that.

It seems that wxWidgets can be used for openGL, so I'll persevere with it.

For anyone else wanting to install Elixir 0.13.1, Erlang OTP 17 with wxWidgets and openGL installed on OSX, here's the magic formula:

brew update 

brew uninstall wxmac elixir erlang 

brew install wxmac --disable-monolithic --with-opengl 

brew install --with-wx --no-docs -v --devel erlang 

brew install wxmac

[Saša Jurić]

I don't have experience in game development, but on a hunch I don't think Erlang is a good fit for this, especially if you plan on writing some face paced game.

In general, Erlang is not very fast, so if you plan on running a lot of CPU intensive tasks, you might not be satisfied with the performance.

If you plan on doing it anyway, you may want to take a look at Wings3D. It is written completely in Erlang, and perhaps the code might provide some inspiration on what to use.

[David Parry]

Sure, Erlang may not appear to be the fastest VM when compared to Java, or even compared to native C/C++, but it outperforms things like Javascript & Lua and people write games in those.

But many of the patterns required to build a good game are extremely well addressed by Elixir/Erlang features:

• Games typically have many concurrent state machines and independently operating 'actors'.
  
• Network communications are often necessary.
  
• Being able to instantiate 100s of thousands of micro-processes that can send messages to each other, stably and without worrying about deadlock or race conditions: that's incredibly powerful and relevant to games.
  

I'm gonna continue on this path.

[Sasa Juric]

On 08 May 2014, at 12:11, David Parry <david...@suranyami.com> wrote:

> I'm gonna continue on this path.

Fair enough. Keep us posted on your progress. I’m really curious to see how will it develop, and wish you best of luck.

[Onorio Catenacci]

On Thursday, May 8, 2014 1:14:26 AM UTC-4, Augie De Blieck Jr. wrote:

Looks like the last major attempt at this was with ESDL:

https://github.com/bjorng/esdl

But now the Erlang folks seem to agree on just going with wx...

Google also shows this project on Google Code, which is a framework
for using wx to make games.

https://code.google.com/p/erlworld/

(Google Code is still available?  Who knew?)

It has actual games to show off the proof of concept, at least. Maybe
that's the trick -- someone needs to build the right framework to
utilize wx in an Elixirish way for game-making.

-Augie, not volunteering

 

Hi Augie,

Not to hijack the thread but is there now a strong preference to use wxErlang (as oppposed to tcl/tk) for Erlang UI work?  Or is wxErlang using tcl/tk under the hood?  Just curious.

--

Onorio

 

[Augie De Blieck Jr.]

Yeah, it would seem to me that it might not be right for a first
person shooter, but for an RPG game with lots of players running
around or something where having AI run down 100,000 possible Next
Moves across all your cores, it might be a good thing.

Of course, the first thing I wrote in Elixir was a card game that did
neither. But I can shuffle 100,000 decks of cards pretty quickly
concurrently. ;-)

-Augie

[Augie De Blieck Jr.]

Hi Onorio,

Good question, but I don't know. Hopefully, there's someone here
deeper in the Erlang world who might have a good answer...

-Augie

[Robert Virding]

The graphics wx interface in erlang is based on wxWidgets. As they say "A port of wxWidgets."

I haven't seen the term wxErlang before though.

Robert

[Sasa Juric]

From what I’ve seen, Erlang is a good fit for game servers (see http://www.slideshare.net/eonblast/an-erlang-game-stack for some examples).

When I was expressing my concerns, it was mostly for using Erlang for GUI part, where I’d expect speed to be critical. But again, I’m just guessing, since I have zero experience in gaming department.

You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-talk/sYJSb4180Ys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-ta...@googlegroups.com.

[Matheus Lima]

Great observation.
If you start an ElixirGL thing, please let us know.

[Onorio Catenacci]

On Thursday, May 8, 2014 9:13:20 AM UTC-4, Robert Virding wrote:

The graphics wx interface in erlang is based on wxWidgets. As they say "A port of wxWidgets."

I haven't seen the term wxErlang before though.

For what it's worth (in case anyone else is wondering about wxErlang):

http://www.erlang.org/doc/apps/wx/

--

Onorio

 

[Dave Cottlehuber]

> > > The graphics wx interface in erlang is based on wxWidgets. As they =
say =22A port of wxWidgets.=22

BTW the best way to see what can be done is to try in iex, =60:observer.s=
tart=60 which also has lots of interesting things to explore inside your =
running BEAM. Obviously your Erlang will need to have been compiled with =
wxwidgets support, & wxwidgets installed on your system. There=E2=80=99s =
also =60:wx.demo=60 which should be self-explanatory.

=E2=80=94 =20
Dave Cottlehuber
dch=40skunkwerks.at
Sent from my Couch

[Josh Adams]

Yeah, `:wx.demo` shows some wx GL stuff

--
Josh Adams

[Jim Freeze]

Cool demo. It bugs me though that the animation stops when I scroll the code window. :(

Jim

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Jim Freeze

[Daniel Goertzen]

The problem is that in games you need the actors to constantly interact with each other and you need them to execute synchronously.  Erlang processes don't support that well; they are highly isolated from each other in terms of exchanging information and execution timing.  Getting around that takes a lot of work and gives you all your deadlocks and race conditions back.

Functional languages taught me that not everything is an object like the OOP books said it was, but you also have to realize that not everything is a process.

Dan.

[David Parry]

Great points raised by everyone here!

A couple of things that occur to me:

speed != latency

Often it's latency that makes the difference with GUIs. A lot of the raw speed requirements nowadays are off-loaded to the GPU, which is a whole other discussion. If anyone remembers BeOS, one of its defining features was that everything on it was threaded: the UI felt magically responsive, even on lousy hardware. This kind of behaviour is a by-product of 1000s of microprocesses.

async versus synchronous

I'd question that a game's internal world must be synchronously updated, but that may well just be my naivety. I could only be proven right by stepping up and building a framework that works that way. Better pull my finger out.

Certainly some of the poor behaviour in the wx demos are reason to doubt that this is a good language. As Jim Freeze points out above: why does the GL animation stop when scrolling? I'd say that's most likely coz it's a quickly cobbled-together demo and not an example of best-practices for a responsive GUI.

I suspect that it's a bit of a chicken & egg situation with the erlang/elixir community: it hasn't been used for GUIs/graphics/games much, so no-one wants to use it, so there's no support, etc.

Anyway, enough talk from me.

I'll get coding. wxErlang looks like a good start!

I also had a quick look at seagull (https://github.com/oslampa/seagull), could be interesting.

[Paul Schoenfelder]

I know I'd be interested to see what you put together. I have an idea for a 2D isometric game that I'd like to build at some point, and if I could use Elixir to do it, that would be awesome. Definitely keep us posted!

Paul

[Frank Hunleth]

On Fri, May 9, 2014 at 9:57 AM, Paul Schoenfelder
<paulscho...@gmail.com> wrote:
> I know I'd be interested to see what you put together. I have an idea for a
> 2D isometric game that I'd like to build at some point, and if I could use
> Elixir to do it, that would be awesome. Definitely keep us posted!

I'd be interested to hear how this works out too. Also, I didn't see
the following link mentioned, but there's another Erlang/SDL project
that may be worth investigating: https://github.com/ninenines/esdl2

Frank

[Alexei Sholik]

Great discussion!

I just wanted to chime in to clarify that there is a huge gap in both time, effort, and required knowledge between writing a game engine from scratch using SDL or OpenGL and developing an actual game.

It is quite common for games to use scripting languages to implement the high-level logic (basically, game mechanics), while the underlying graphics, physics, and other subsystems are implemented in C++.

I honestly don't think that calling into OpenGL from Erlang/Elixir will yield anything whatsoever. Any client of OpenGL will be tied to its single-threaded architecture. If there is a bottleneck in the graphics code, it's most likely in the GPU which does not get any benefit from Erlang VM that runs on CPU.

But the idea of modelling the AI and other game entities in a concurrent language is super awesome! So I would imagine an architecture where there is a backend process (a set of threads or an OS process) that implements all the graphics-related functionality (maybe also event-loop and input-handling) and there is the Erlang-VM-side of the application where game logic is being computed.

Those two high-level components will be mostly asynchronous. Basically the architecture will resemble the familiar client-server model: send data to render and process to the low-level engine, do AI and game logic processing in parallel with rendering, maybe synchronise some state at one point; repeat this sequence for each game frame.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Best regards
Alexei Sholik

[David Parry]

You certainly have a point about the amount of time  & resources that would be needed to make a whole game engine talking to OpenGL & such...

But, I guess one of the things I'd like to see would be something a little akin to three.js and its relation to WebGL?

WebGL is still pretty low-level, and you need to know all sorts of arcane voodoo to do anything with it. three.js adds a much more accessible layer over that, and many 'mere mortals' do all sorts of wonderful things with it.

Seems to me there's a possible gap there in the Elixir/Erlang world. Yes, you can do OpenGL through wx. But that sounds hard!

As for building a game engine, well, that's a whole 'nother thing!

Maybe some deconstructing of three.js might lead to something useful?