BearLibTerminal: a pseudo-terminal window library for roguelike

[Quendus]

I always use "import PyBearLibTerminal as blt", which lets me write things like blt.put_ext() clearly and quickly. I'm not sure what the benefits of that pull request are supposed to be. A pip package would be wonderful, no matter whether the names are global or not.

I'm not too bothered about whether mouse events are included in the default filter or not, as long as it's easy to change.

It takes a few hours for virtualbox to log in, but if no-one tries it on a real mac soon, I'll test 0.13.1's keyboard input.

As far as I know the standard for shortcut keys on cross-platform applications is to use Command in place of Control in all cases. Exceptions are either quick-and-dirty ports of linux apps, or terminal applications for which shortcuts using the Command key are sent to the terminal rather than the application.

[Quendus]

One disadvantage to the new single-threaded architecture: I often develop interactively (using the Python REPL or IPython). When I leave the window open without regularly calling read(), Windows greys out the BLT window and marks it as not responding. I guess this is unavoidable?

[Cfyz]

When I leave the window open without regularly calling read(), Windows greys out the BLT window and marks it as not responding. I guess this is unavoidable?

Fortunately, it is fixable. Though there nothing can be done about necessity to call some methods regularly (event polling), the problem can be worked around with a bit of support from the interactive shell. Python conveniently provides a hook for polling GUI during it's interactive input. I've updated the Python wrapper adding such hook, it relies on ipython package being installed.

I've also found and fixed a bug in the Windows' event polling code which could cause the library to hang (running through the hook increased the chances enough to notice that). Please download the next 0.13.2 version.

[Quendus]

I'm using 0.13.2, and I've checked that the relevant line has run, but the window's behaviour in IPython hasn't changed.

[Cfyz]

Hmm, that's strange. Does shell stay responsive when the window is grayed out?

Actually, how do you use it?

Code: [Select]

$ ipython
<...>
In [1]: import PyBearLibTerminal as T
In [2]: T.open()
Out[2]: True
In [3]: T.refresh()
Out[3]: 1
In [4]:
This would be the minimal test case. You don't even need ipython shell, this works in regular python interactive shell as well (the hook itself is Python feature, ipython dependency is for convenient IPython.lib.inputhook module).

I get consistent results on a wide variety of platforms: Windows XP, Windows 7, Ubuntu, OS X (WMVare), 32 bit and 64 bit, Python 2.7 and 3.5 (this looked fairly platform-specific so I checked a lot of them but behavior is almost identical) and everything matches the documentation well.

[Quendus]

Sorry, I should have been clear that I was talking about IPython notebook. I just tried the minimal test case in the Python and IPython consoles, and it works as intended (though I now have to call close() to get a clean exit).
In IPython notebook, the same code leaves the BLT window unresponsive.

[Cfyz]

There you go: PyBearLibTerminal.py (relevant diff). You need to manually enable integration by "%gui blt" command in ipython notebook.
Cute how all this very environment-specific machinery added to the wrapper introduces literally zero overhead unless actually run from an interactive shell or notebook.

[Quendus]

Perfect. Thanks so much!

Here's a BearLibTerminal sandwich for you:

[Jan]

BearLibTerminal is really nice! I was looking for a long time for a way to make roguelikes in TrueType fonts, so I am glad I found it!

I learned a lot from Jotaf's libtcod python tutorial, and to educate myself on BLT, I modified the tutorial game for BLT display. It was suggested here before, but I don't know, whether anybody did this already...

Anyway, if someone is interested, here is the download link for the source code .py file and the Win32 package for running the game by an executable.

https://sites.google.com/site/iolx3home/TOMBS_BLT.rar?attredirects=0&d=1

I hope this helps someone, at least it was great fun for me. It is not at all perfect code, but it should give ideas. I will consider BLT for sure in future projects.

However, quick comment: It would be really great to have background (or transparent flag when needed) on additional layers. Libtcod consoles are a little easier here (menu covers the screen below).

[Quendus]

However, quick comment: It would be really great to have background (or transparent flag when needed) on additional layers. Libtcod consoles are a little easier here (menu covers the screen below).

One way to simulate background above layer 0 is to use the unicode block drawing characters, in particular the full block. This fails if the font size doesn't match the cell size, so you might prefer to use a plain white tile from a spritesheet instead. You can use alternate layers for foreground tiles and background blocks, or just turn on composition and put them on the same layer.

[ffred60]

Hi,
just discovered BearLibTerminal. looks great ! 
is there Lua use documentation or a small example somewhere..?
Thanks.
ffred

[Edit:]
sorry, first post here and already replying to myself..
after a few tests, here is my simple Lua "Hello World". (but of course, if someone got a link to doc or bigger example, still interested)

Code: [Select]

local T = require "BearLibTerminal"
T.open()
T.print(2, 1, "Hello, world!")
T.refresh()
T.read()

[Cfyz]

It would be really great to have background (or transparent flag when needed) on additional layers.

One way to simulate background above layer 0 is to use the unicode block drawing characters, in particular the full block.

Using special characters is more or less the right way. Cell background color is a very basic feature and if you are doing something advanced like floating menus and windows, you may as well use more versatile 'tools'. Like this (Python source):


Btw, there is a bug (half of it is in the library, another half is was in the Python wrapper; I wonder when they will stop appearing) preventing put() from working with non-ascii characters like 0x2588. Please get the fixed PyBearLibTerminal.py from repository.

This fails if the font size doesn't match the cell size

Good catch. Looks like library should generate these characters for cell size, not for the font size. Can't think of a situation one will need Box Drawing / Block Elements symbols not matching the size of a cell.

Edit: this case still won't work with bitmap fonts that provide their own borders/blocks symbols (e. g. Dwarf Fortress fonts) since handpicked bitmap tiles have priority over auto-generated ones.

is there Lua use documentation or a small example somewhere..?

Reference documentation is virtually the same for all languages, just function/const names change slightly, e. g. terminal_state(TK_SHIFT) vs BLT.state(BLT.TK_SHIFT). So all examples (e. g. C++ ones) should translate from one language to another fairly easily. Sadly there are no proper language-specific tutorials yet.

[ffred60]

ok, thanks..

[Omnivore]

Also, Omnivore, are you here? I've meant my response on bitbucket as an invitation to discussion. Can you provide some examples of what are trying to do? Maybe there are even some conventions about keys and shortcuts in cross-platform applications on Mac?

Oops, I seem to have missed this earlier.   

I simply do not believe an I/O library should be making UI decisions for me.  How any particular OS or GUI implementation handles ALT keys is really not the point.  Fact is, no other I/O library that I have used or can remember examining discards ALT key presses and ALT key state.  Also, IIRC, your response on bitbucket indicated you were going to embed certain alt-key presses in the lib for uses such as full-screen switch.  I am totally opposed to hard-wired UI behaviors in an I/O library.

It is, of course, your library, however given your response to the bitbucket issue I raised and my disagreement with your stated intentions, I've moved on to other solutions.  There was one other issue I was going to raise that I consider equal in importance to the ALT key handling, but have not raised it previously since I've moved on.  I'll raise it below just in case other users may find it of interest.

The other issue is that I desire a solution that is compatible with either or both resource streams and PhysicsFS https://icculus.org/physfs/ type file systems.  Both of these solutions allow single file binary distributions of both DLLs and media as part of an executable or plugin.  The major change to BearLibTerminal would be to allow loading of media as byte buffers as an alternative to files.  A minor change might be required for some wrappers in order to allow dynamic loading of the BearLibTerminal DLL itself. 

I would still recommend BearLibTerminal to anyone who doesn't desire ALT-key handling and/or no install, single file, distributions.

Hope this helps,
Brian aka Omnivore

[Cfyz]

Whoa. Do I sound that firm in my argumentation? >_<

Just a bit more about my point of view: I feel that as a pseudo-terminal library, BearLibTerminal may behave a bit like other real terminal windows, e. g. gnome-terminal or PuTTY which handle or ignore a lot by themselves and no one find that strange, e. g. zooming, clipboard, etc. Or Alt+Enter toggling fullscreen which is a very common combination that does exactly the same thing everywhere it is implemented, so why not enable it by default? Strict comparison with other I/O libraries is not fair since those libraries are general-purpose, while here I trying to be a bit specific in scope.

That said, wouldn't everything be OK if BearLibTerminal had these UI shortcuts simply enabled by default with an option to disable them? Like "input.alt-functions=false" and then you are on your own with that key? All these shortcuts are just conveniences, not a core feature. My previous questions (what are you doing and why) were to find out if there is something that might be better accounted for or integrated into these library tricks. If what you need is some 'raw access', then why not?

Support for streamed/archived resources is something I lazily thought of (mostly because no one voiced it before) but there is some support already as BearLibTerminal can load images from in-memory buffers (look at relevant line in the sample). This is not complete: you cannot load TrueType fonts or text files (codepages) from memory =/. It would be nice to make possible to load resources from streams but I just cannot figure out how API for that should look like.

With all due respect, sir, I accuse you in being silent.