search

mordak / Term48

50 stars 20 forks source link

Feature Request: Graphics API #11

Closed halfnibble closed 8 years ago

halfnibble commented 8 years ago

What

Not sure if this is even feasible, but I'd like an API to modify the terminal display programatically. I'm hoping since the terminal itself is coded in SDL that this may be possible?

Why

Recently, I was playing around with ncurses on term48. Then I messed around with my Arduboy dev kit. (More about Arduboy). And I thought maybe, I could make a portability layer to run Arduboy games in term48! The Arduboy game library is written in C++, and is extremely basic. I just need a way to draw basic graphics in the terminal (I'm talking about pushing pixel by pixel to the screen).

I can use ncurses, but it would be much better if I could draw pixels instead of characters.

mordak commented 8 years ago

Hmmm.. The standard 'graphics' API for terminals is the termcap/terminfo interface, which is what ncurses is linked into. This is what games like nethack and worm use, and it's really just sending control characters down the tty from the program to the terminal emulator. As far as I know, there isn't a more advanced graphics API than that, and the interface is character based anyway, not pixel based.

Typically, if you need a drawing API more advanced than what curses provides, then you would make an application that links into one of the graphics APIs available (Qt, SDL, X, etc.). Term48 uses SDL, but the only interface it has to any programs running inside the shell is through the tty (stdin/stdout in the program). I imagine it would be possible to expose the SDL API through custom terminal control sequences, but on the client side this would boil down to re-implementing the entire SDL API to work over a tty, it would be incredibly slow, and it would be more work than just making a standalone application that links against SDL by itself. Looking at Arduboy, it seems like an emulator/portability layer to bring that to BB10 would be best done as a standalone application, which would give you much more control over what happened to individual pixels without having to worry about running inside the graphics stack of another application. You should be able to get results a lot faster that way, and you'd have the full power of the BB dev tools available to you (ie. a debugger).

Anyway, thanks for the suggestion, but I think this falls outside the scope of a terminal emulator.