3 ms·

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is s

by djur 11y ago

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. GC pauses in Go should not be a serious issue for games like the ones featured on the OP's site. The same general techniques used for high-performance manual memory management work fine in garbage-collected languages -- allocate on the stack if possible, allocate the heap you're going to need up front and reuse it (with object pools or the like). > The library support for games is quite poor I would say the same for C, honestly. Last time I was looking for game libraries to write a binding to (from OCaml) I found more C++ and Java options than C.

jeremyjh 11y ago
>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines https://en.wikipedia.org/wiki/List_of_game_engines
- yalue 11y ago
  Of course, a more or less 100% complete wrapper of SDL for Go exists, too, so SDL invalidates the original argument against Go if you're considering it for C.
- strangecasts 11y ago
  Another nice library is SFML[1], which has bindings for C and several other languages (including OCaml). [1]: http://www.sfml-dev.org/ http://www.sfml-dev.org/
  - seba_dos1 11y ago
    There's also Allegro[1]. While its popularity peak was on older versions, Allegro 5 has been completely redesigned and it's a pretty great modern C library now. [1]: http://liballeg.org/ http://liballeg.org/
  - djur 11y ago
    SFML is actually a good case of what I was talking about. It's a C++ library with a C binding. I found that (and C++ libraries with no C binding at all) to be more common than native C libraries.
- djur 11y ago
  SDL and Allegro are great, but there isn't a very robust software ecosystem around them. You can put together something great with SDL, chipmunk2d, and enet, but there's not a lot of options. It's really nothing compared to what's available in the C++, Java, and JavaScript worlds.

by djur 11y ago

jeremyjh 11y ago

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines https://en.wikipedia.org/wiki/List_of_game_engines

yalue 11y ago
Of course, a more or less 100% complete wrapper of SDL for Go exists, too, so SDL invalidates the original argument against Go if you're considering it for C.
strangecasts 11y ago
Another nice library is SFML[1], which has bindings for C and several other languages (including OCaml). [1]: http://www.sfml-dev.org/ http://www.sfml-dev.org/
- seba_dos1 11y ago
  There's also Allegro[1]. While its popularity peak was on older versions, Allegro 5 has been completely redesigned and it's a pretty great modern C library now. [1]: http://liballeg.org/ http://liballeg.org/
- djur 11y ago
  SFML is actually a good case of what I was talking about. It's a C++ library with a C binding. I found that (and C++ libraries with no C binding at all) to be more common than native C libraries.
djur 11y ago
SDL and Allegro are great, but there isn't a very robust software ecosystem around them. You can put together something great with SDL, chipmunk2d, and enet, but there's not a lot of options. It's really nothing compared to what's available in the C++, Java, and JavaScript worlds.