Hacker News Reader

Comment by takumo | Hacker News Reader

Looks cool but really should mention early on that it doesn't use SDL or OpenGL to render the game but uses a specific feature of iTerm2 to render a series of images in the terminal, on other terminals it just shows a black screen.

View on HN

Ouch. Not so interesting after all then.

Does Go even have some "standard" SDL bindings? I was googling the other day (with the aim of learning Go through doing something fun) and I found like 6 results only on the first page. Didn't go and try any of them because to be honest that's depressing... i bet that if there are 6 different bindings none is feature complete.

Is Go useful just for server side stuff then?

https://github.com/go-gl has opengl and glfw bindings which would serve many of the same purposes.

See? That's the problem. Two different bindings recommended already. Better than 6 tbh, i might look at those 2.

And to the twitch guy I'm sorry, I'm old enough to prefer written documentation :)

>See? That's the problem. Two different bindings recommended already.

You were recommended one binding for SDL and one for GL. Obviously they're different.

Ah sorry, my bad. I thought that since i asked about SDL bindings i got recommendations for SDL bindings ;)

opengl and SDL are different things.

glfw and SDL are similar things, in that one may use one or the other to do basic operating system tasks like "get a window" which you can then draw to with opengl (or vulkan or whatever)

Even if you were programming in C++ you would have the choice between glfw or SDL for that kind of thing (or directly talking to your operating system's API!), so Go is not adding any confusion here that doesn't exist already.

I talk a bit about this in the EP 6 stream that you are too old for =) (I prefer written docs too! EDIT here: https://www.khronos.org/opengl/wiki/Related_toolkits_and_API... )

I know, except SDL also has OpenGL support ;) Plus enough stuff to handle the rest of your game.

My main confusion is I know some SDL and OpenGL, but no Go. Thus, I don't know how to choose a SDL binding. Fighting with the binding is not a good thing when you want to learn a new language by doing a space invaders clone :)

https://github.com/veandco/go-sdl2 is the SDL binding most people are using. It is solid.

Replying to myself because I can't reply to my reply - guess too many reply levels.

Thank you mr/mrs/whatever gameswithgo! That's what I wanted to hear!

There's nothing about Go that makes GUI programming hard, it just hasn't taken off. Probably because maintaining bindings isn't fun, and bindings are rarely pleasant to use (impedance between C and the host language). And writing a decent GUI toolkit from scratch is a huge amount of work. Besides, competition from web apps and things like electron is eating GUI apps' lunch, regardless of programming language.

Go is a general purpose programming language, so it's suitable for basically anything in the Java/Python/.Net world modulo availability of libraries.

Flappy Gopher[1] uses SDL and comes with an instructional video for the beginners.

[1] https://github.com/campoy/flappy-gopher

Go has an excellent set of SDL2 bindings: https://github.com/veandco/go-sdl2

They do a very good job of making the API relatively idiomatic to Go without adding overhead, and I haven't run into any bugs yet.

I have been using them as part of a twitch series that teaches programming via small game projects. I go through how to get SDL2 up and running in episode 6:

https://www.twitch.tv/jackmott42/videos/all

There are aspects of Go that should make it better for game related programming. The low latency GC is a very good thing, compiling to native binaries means quicker start up time, and better responsiveness than a JIT, and easier distribution. Fast compile times are also very nice for many game programming workflows.

Awesome. Thanks for the link to those videos, I plan to watch them all.

https://github.com/fogleman/nes is a nintendo emulator that uses https://github.com/go-gl/glfw/

Terminals can display images?

Wow.

I'd consider that pretty amazing and useful for displaying visual information like charts, flame graphs, latency plots etc.

Is this a (de-facto) standard? If not, it should be!

Nope, just an iTerm2 feature.

Surprisingly there's nothing similar for Linux distributions - iTerm is for Mac only.

notty [1], although I believe it's dead currently.

[1] https://github.com/withoutboats/notty

xterm supports some graphics through Sixel rendering. Never saw a real use of this. On X11, some text browsers, like w3m render images on xterm by painting directly in the xterm window.

xterm has a Tek 4014 mode. Here's an older comment with some examples: https://news.ycombinator.com/item?id=7776904

Well there is HTerm which is available for Linux.

http://41j.com/hterm/

Not just graphics, iTerm2 has a whole bunch of other features that you can't find in one terminal on Linux.

Sure but I was responding specifically in the context of GP.

>> Terminals can display images?

You know we live in strange times when Linux falls behind Mac OS on terminal support.

This is a major annoyance for me, a former OS X user (stopped using it turned to shit in all other regards). I have had to work really hard to get text to render well in Linux terminal emulators -- iTerm2 had good typography out or the box, modulo the default typeface.

DEC Sixel has been around since the '80s, although I'm not sure how many modern terminal applications support it.

Reply on news.ycombinator.com