Unos minutos eligiendo assets de kenney.nl, un par de funciones para que tenga soporte de audio (sí, todo el audio viene del código) ... obviamente no hay colisiones todavía, y todo es ... precario.
A group of crows is called a murder of crows. A group of hares is called a council of hares.
In fact, that's just a bunch of things victorians made up because they had lots of free time and they
hadn't invented the Internet yet, and most of those were never actually widely used.
BUT what's the name for a group of things that are in a minimally viable state?
Well, CobraPy, my 80s-style python programming environment is slowly crawling into becoming one of those.
Of the components I want, I have one of each. They all suck but they suck in the same way a 3 year old
playing pool sucks. He will not be great but it's still cool.
I am going to punt in having the editor I want because I can make do with Micro for the time
being (works flawlessly in my terminal!)
The REPL is not great but it can do what it can do
The graphics server works (although its API is limited to drawing circles)
The terminal is better than expected, could really be used as a daily driver except for some
programs really not liking it.
And also, I have combined all the things so that you can start a window that:
What next? I could think about what next. Or ...
I could try to write a simple game and implement all the things that don't exist.
Except for input. I need to solve how to do input. You see, the user-created programs don't run in the same
space as the window. That's why we have a graphics protocol. The program puts things in it, the window reads them
and graphics appear.
But input needs to go the other way around. So I need to add a second protocol to send back events and it needs to be pretty fast. I don't think it's going to be a problem (user actions happen only once every few dozens of milliseconds!) but after that's done?
It's going to be time for ...
Or actually, to fail at implementing it, but improving the platform in the process. Because failure is what improvements are made of.
As it happens in early stages in fun products, progress in CobraPy has been both faster and slower than expected.
In the past few days a number of things happened:
I made that terminal a whole lot nicer
I already had a terminal but I fixed a number of things.
The keyboard handling is much better, it now recognizes pretty much all keys, which is always a nice thing.
It sorta supports things like "á" via mode-switch (no deadkeys support probably ever)
It has 24-bit color support! I didn't know terminals could support that kind of thing!
I added a graphics protocol to it!
Terminals with graphics support have a very long tradition. This is a VT55, released in 1977
displaying graphics:
How did it work? Well you can read the programmer's manual if you want, but basically you sent a control sequence that put it in "graphics mode" and then sent
commands describing what to display.
Similar ideas with different protocol details were used in many different future terminals, including ReGIS graphics and Tektronix vector graphics and you could even trace this all the way to a current Linux
desktop's X11 graphics.
So, what did I do? Not that, exactly. I am creating a side-channel as a sort-of-RPC where
you send serialized python method names and arguments.
I wrote a Python REPL
I wanted an interactive mode that was slightly friendlier than Python comes with, but not something
overwhelming and powerful like IPython or BPython.
I did some research, and found ptpython which is pretty
awesome, but still a bit too much awesome.
And then I started on a much, much lamer version of it. Still embrionic, but it does work. I have some plans for it.
I learned a lot more about Raylib
All the graphics and basically everything you see in this project is done using the
awesome raylib and a homegrown CFFI binding for it. I was not
using it right, now I use it better, and things that took several hundredth seconds
now take a few dozen microseconds.
I integrated the whole thing, sorta
So, I integrated it enough that you can start the terminal, launch the REPL in it, and
use the graphics protocol to draw something!
Por otro lado, el que dibujar 10 círculos usando IPC tarde 20 segundos sí hay que optimizarlo ahora :-) pic.twitter.com/0ywf9nzxkH
CobraPy is in large part about reinventing wheels. We do, after all, have
perfectly fine 80s-style development environments in the millions of 80s computers floating around, as well as
emulators, things like the Maximite and so on.
However, I only want to reinvent fun wheels, so I am not doing a text editor. And probably gonna hack a terminal-based REPL. And there's no way I am doing my own wifi config tool (again) so, I should have a regular, ordinary terminal.
But the things I want that terminal to do are ... unusual, like raster graphics, and sprites. So ... why not do my own terminal
for this?
It's not the first terminal I write! I wrote a dumb terminal emulator around 1998 and I wrote a very basic one using python, pygame and pyte a few months ago. It's on video!
But this time I wanted a better one, since I want this to look good. So I went and wrote one.
It uses many 3rd party things, because life is short.
Pyte for all the nitty gritty of terminal emulation