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.
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.
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:
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.
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.
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 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 :)
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.
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.
It may be worth noting that the sprites are registered trademarks of Taito. So be careful…
(I learned this the hard way: I once had a rather poplar 404 page featuring a variant of the game [1], until I received a cease and desist letter from Taito…)
So, I just had a look: Oct 2013, processed by a local attorney (Vienna/Austria). This was following to the page gaining some traction and popular attention in Japan. (Without intending any interpretation of this: I believe, in principle, you have to defend a trademark in order to uphold the rights – and at this point it was well in their radar.)
The invaders positions shouldn't all be updated every cycle, they should be updated one at a time, or in a separate thread, this is what the arcade machine does and due to its limited processing speed this naturally leads to the aliens speeding up as fewer aliens remain.
This implementation starts with the aliens going at what might be considered "full speed", and is probably much more difficult.
For anyone interested in making little games in Golang, Termloop[1] is a terminal-based engine (though it uses text to render rather than this iTerm-specific feature).
Also, for non terminal-based things, Raylib is really nice.
It's originally a C-based games-library, but the bindings work well for playing around in Golang.
My understanding is that Go's ffi overhead[1] makes game development impractical at a certain level, due to the amount of opengl calls you have to make. Is this still the case?
Maybe if you are doing deprecated GL_BEGIN stuff -- but that is ridiculously inefficient even in languages with native bindings!
I don't see how FFI overhed would be a big deal for modern GL code. Most of the bindings happen only once. Then, sure, you update some buffers and ask the shaders to draw, but the buffer updates are likely limited by available bandwidth between primary memory and GPU, and the actual drawing is done in-GPU by shaders -- the single FFI call to start that process does not seem like a big deal in comparison.
It would be about 13,000 calls into C per frame, to waste 1 ms with call overhead.
1ms would still be a lot when you only have ~16ms to work with,but I don't think even AAA games make within an order of magnitude of that many opengl calls per frame? Even writing in pure C you want to batch things as much as possible. I think typical is well under 1000 calls per frame, but I've only got experience with small hobbyist projects.
This is awesome, and something I was doing as well for fun! Go's image package has some pretty nice primitives. One thing I think would make this even simpler is you could simply sequence the individual sprites using image.NewRGBA and simply setting the Pix slice to the values to draw the appropriate images, then you can avoid going to the os at all!
I was thinking I might see Go in a device-control application, but alas not. The program uses a modern computer's video system. The original Space Invaders code likely had to shift pixels out to the video display in realtime. So a different programming feat entirely, but still cool!
I have used go in an embedded application (raspberrypi) in a soft realtime manner controlling and LCD over I2C and staying under a 1.5ms looptime. The hardest part is to undo all the things the kernel does and get access to memory so you can do memory based io, but luckily the go stdlib has everything you need to make it happen.
Nice! I have a project of my own [1] in a similar vein although not as low level as yours. Using an RPi3 with the official TFT LCD and touchscreen and rendering graphics via OpenVG. Getting about 45fps (~22ms per frame) on the Pi itself to render an 800x480 UI filled with some round-rect buttons, rotary dials, and text. Rolled my own very basic UI controls library and cross-platform host isolation library [2] to achieve this. Tested and working on darwin, win64, and raspberry pi 3.
- The built-in concurrency primitives are designed with real time systems in mind, freeing you from the need of constructing a cyclic executive and scheduling manually.
- The tools to deal with time constraints and diagnose why deadlines were not met are very high quality. The Ravenscar profile essentially guarantees that all scheduling decisions are known statically.
- Not strictly real time related, but
since real time systems are often safety priority systems I'll mention it anyway: Ada makes memory management hard to get wrong.
If you're interested, I think Programming Real-time with Ada 2005 over at Embedded.com[1] provides a really good overview. Many of those features are meant for safety critical hard deadline systems and are consequently overkill for bedroom experiments, but for those projects you can just take the default basics and get 98% of the way there.
(If the article seems outdated in some aspects, recall that there were some further imptovements to the standard in 2012.)
