Show HN: Strife, a 2D game library for Go(github.com) |
Show HN: Strife, a 2D game library for Go(github.com) |
My kind of dream project here is to maybe make a little tutorial series on how to use the library making a small game with it. Maybe inspire a few young people to get into graphics/game programming to show how simple it is - in the go domain specifically. The library is kind of a no thrills graphics library, maybe I should market it that way.
The project doesn't really market itself too much right now, and I don't think I will focus on that till I've written a reasonably polished game in it either. But thank you for that link I will bookmark it.
Kind of just throwing the project up on here for people to look at & critique.
And that is a point... the feature project is a text editor. Though I think it looks a bit more impressive than the alternative which is a little game I'm working on in my spare time.
The library itself is worked on from time to time. The last commit was a few days ago (a small patch however).
Any examples of this being used for something non-trivial? I'm generally curious because I figured Golang would be a no-go due to the GC...
Huh? Tons of GC languages are used for games. Heck, web games use JS. Not to mention the whole C#/Unity thing that even powers AAA games...
In a lot of 2D games, simple patterns like object pooling are more than enough to squash any GC problems. There's a whole spectrum of performance requirements out there -- no need to discount a framework due to it's language.
It's a fight against the GC typically
I'm close to implementing hot code update -- in my Go game servers!
It is a matter how it gets used, not that it is present.
As a practical example, capturing variables in a closure will usually cause them to be heap allocated in Go, but in C++ capturing has no effect on variable storage.
That’s actually kind of a main theme of Go, that it’s very opinionated about what the right way to program is, and doesn’t do you any favors if you try to use it to do things in a way it doesn’t think aligns with that.
It's truly wonderful time for all programming languages in this space.
It is, but it's still an option. It's not like "language with GC" == no-go for games, as the parent implied.
Many forget that MSIL is rich enough to support C++, initially via Managed C++, later replaced by C++/CLI.
The major features in C# 7.3 are related to slices, improved stack allocation and reducing copies of value types.
I do have mixed feelings about LLVM for safe GC'd languages, though. LLVM is full of undefined behavior, and its support for precise moving tracing GC is not widely used. So I can definitely sympathize with not wanting to use LLVM for Go, but not for the reasons they cited.
What constitutes 'fine' depends on workflow, size of project, machine horsepower, and personal preference. Some projects require a bit more compile -> experiment -> change -> compile -> experiment -> change than others.
You'd almost truly have to go out of your way to consume browser-levels of memory.
Seems like it can go sub 1ms
In my view (which is the dominant view among compiler engineers for GC'd languages), spending a lot of effort to avoid allocation is a poor use of programmer time in a GC'd language. It is better to just improve the GC to make allocation fast. In a properly designed generational GC like that of Java HotSpot, allocation is about 5 instructions. That is a game changer: allocation is as cheap as a function call plus the prologue.
Unfortunately, Go's designers have so far not deployed generational GC, which is why we keep having these threads about avoiding allocation. (I've seen indications in the last couple of weeks that Go may finally be moving to a generational GC, though, and I hope they do.)
Then I fully agree with you.