BearLibTerminal: a pseudo-terminal window library for roguelike

[Omnivore]

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

Guilty through pessimism, my apologies.

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?

Yes that would work.  Best would be if the default mapped functions could be accessed individually when the "input.alt-functions=false".  In other words, rather than alt-enter (assumed default) switching full-screen, the same switch could be accessed via a menu in the application's UI. 

An example of a custom mapping might be: CTRL-(1-9) sets a 'recall' position, ALT-(1-9) teleports to that position.  Another might be a plugin that enables some plugin-defined behavior with a multiple SHIFT-ALT-(some key) sequence, or a user remapping of keybindings.  Also, in a left-hand on keyboard, right-hand on mouse setup, the ALT-key is, at least on some keyboards, adjacent to the spacebar and easily thumb-accessible while other fingers are on 'main' keys (qwer-asdf-zxcv).  In games (example ASCII-Sector) which combine both turn-based and real-time play (depending on mode), the difference between easy to reach ALT and (relatively) hard to reach CTRL may be significant.

If some mode allows ALT key both as key press and key modifier to be accessed then such custom mappings can easily be accomplished.  ALT key as modifier being the most important for general use I believe.  Would there be any harm in allowing ALT key as key press/key modifier even when input.alt-functions=true ?

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.

Oops, I missed that usage of terminal_setf.  If I'm reading that sample correctly, then loading from stream to memory and then making the terminal_setf call would handle most reasonably sized bitmap files assuming the pixels are in the correct color format.  Does that call result in the lib making an internal copy of the passed data, or does the application need to hold that data in memory after the call?

For TTF, there is a version of the FT_New_Memory_Face call that accepts a memory buffer address, so that may give an alternative entry point.  Not sure about the code page text files although, given that they are likely to be a small file, a kludge fix might be to copy to a temp file and load that.  Of course the same kludge could be done with TTF fonts. 

For streams, yeah the interface would be a problem, especially given the multiple language mappings.  Frankly I'd be happy with just using memory buffers as long as the expected format of the byte buffer and call are well defined.  It would also be preferable I think if the lib made a copy of the passed buffers so that the caller could discard the buffer after the call to terminal_setf.

I'll try to be less silent in the future, maybe a bit more optimistic

Thanks,
Brian aka Omnivore

[Cfyz]

Best would be if the default mapped functions could be accessed individually when the "input.alt-functions=false".  In other words, rather than alt-enter (assumed default) switching full-screen, the same switch could be accessed via a menu in the application's UI.

Yes. Actually, while you cannot disable Alt+Enter in the current build, you still can manually set "window.fullscreen" option and inspect the current TK_FULLSCREEN state from the code.

Would there be any harm in allowing ALT key as key press/key modifier even when input.alt-functions=true ?

Can't think of anything 'harmful' but that will leave things a bit fragile. A simple example would be zooming which is commonly bound to plus(in)/minus(out)/zero(reset) so default shortcut will overlap with hypothetical Alt+0 'teleport to position' command.

Does that call result in the lib making an internal copy of the passed data, or does the application need to hold that data in memory after the call?

Yes, a copy is made. Memory is not precious enough to make user juggle with buffers lifetimes =).

As you can see, not much of in-memory loading is supported right now, only raw BGRA bitmaps. It was more like a proof-of-concept for low-level library API (you can pass a System.Drawing.Bitmap object into Terminal.Set function in C#, a table of pixels in Lua, etc. =_=). Looks like I'll have to expand this functionality soon.

[Omnivore]

Would there be any harm in allowing ALT key as key press/key modifier even when input.alt-functions=true ?

Can't think of anything 'harmful' but that will leave things a bit fragile. A simple example would be zooming which is commonly bound to plus(in)/minus(out)/zero(reset) so default shortcut will overlap with hypothetical Alt+0 'teleport to position' command.

Wouldn't any custom CTRL-[0=-] bindings also make CTRL fragile in this case?   
[EDIT] Assuming the zoom functions were bound to unmodified [+-0], obviously CTRL bindings are non-fragile if zoom is ALT-[+-0].[/EDIT]

I know its popular these days to protect programmers from themselves, but given good documentation, overlapping a non-disabled default binding with a custom binding would, to me, be programmer error on the part of the library user.

Does that call result in the lib making an internal copy of the passed data, or does the application need to hold that data in memory after the call?

Yes, a copy is made. Memory is not precious enough to make user juggle with buffers lifetimes =).

As you can see, not much of in-memory loading is supported right now, only raw BGRA bitmaps. It was more like a proof-of-concept for low-level library API (you can pass a System.Drawing.Bitmap object into Terminal.Set function in C#, a table of pixels in Lua, etc. =_=). Looks like I'll have to expand this functionality soon.

Personally, for purposes of loading bitmap data, raw BGRA format is fine.  If necessary can always do format conversions either pre-build or inline in the source language of the app.  For TTF, most languages should provide some method of loading a binary file as a byte array which could then be passed with no format changes.  I'm unsure of what would be required for CP files.

Since you already have the capability for raw bitmap data loading, I don't know if I'd consider the addition of the TTF/CP/other bitmap format handling to be a high priority.  It is always possible to use the kludge of copying to temp file as an interim workaround in the app language source.  Of course, that depends upon the usage patterns, where for my needs seem to be perhaps a half dozen to a dozen bitmap files, one TTF file, and at most one CP file.  Not sure if that is typical.

In any case, thanks
Brian aka Omnivore

[Cfyz]

An update. Say, 0.14 (these numbers were mostly arbitrary right from the start).

1. Alt key issue should have been resolved. I've added the TK_ALT keycode with corresponding input event and state always available. By default the library will intercept some key combinations, but this can be turned off with 'input.alt-functions' option.

2. Resource loading has been cleaned up a bit. Now anything can be loaded from a memory buffer by specifying <address>:<size> pair instead of a filename, like this:

Code: [Select]

terminal_setf("font: %p:%d, size=8x16, codepage=437", buffer, size);
terminal_setf("0xE000: %p:%d, raw-size=%dx%d", pixels, W*H*4, W, H);Because consistency. Also why decode embedded images to pixels when library can do that already.
Note that 'raw-size' is a required option for raw bitmaps now, since library need to know that is is not a file somehow. More or less documented.

3. Extra fonts management looks decent at last. Extra/alternative fonts is when you can use additional styles alongside the main one, like italic for emphasis or some ornate square one for menu.
It should be very straightforward now:

Code: [Select]

terminal_set("font: UbuntuMono-R.ttf, size=12");
terminal_set("italic font: UbuntuMono-I.ttf, size=12");
terminal_print(2, 1, "Its eyes are [font=italic]glowing[/font].");

[LisacPisac]

Hey,

I'm trying to add BearLibTerminal to PyCharm in Linux, but I'm not meeting much success. I'm not even sure how to get the system to use the shared object (if python even uses it?). I get this error:
    "RuntimeError: BearLibTerminal library cannot be loaded."

Do you have any advice on what I should do?

PS: Honestly, it'd be great if you could create a pip package that we could easily install.

[Cfyz]

This happens because libBearLibTerminal.so is not in the place the wrapper looks in. With default PyBearLibTerminal.py wrapper, the library binary may be either in default system path, or in the same directory as wrapper. The easiest way to fix that is to copy the .so to the source directory. If you want to have it somewhere else (e. g. /src and /bin separate) then you may add a new path directly to the wrapper (_possible_library_names variable).

Indeed, pip package should fix that as the binary (installed with the package) will have a well defined location. I'm working on that.

Why does PyCharm show members starting from _ in its intellisense? Aren't they considered hidden by convention?

[LisacPisac]

The __ members are useful meta variables that have their place in the python langauge and are supposed to be used, as they add new options to developers.

[Cfyz]

Code: [Select]

pip install bearlibterminalAnother step to enlightenment. Works (or should work) on Windows and Linux, 32 and 64 bit. OS X package is not built yet, my virtual machine with OS X is such a pain.

Use it like this:

Code: [Select]

from bearlibterminal import terminal

The __ members are useful meta variables that have their place in the python langauge

I was talking about single-underscored members of a module. Like terminal._library which should be considered internal:

[Quendus]

Code: [Select]

pip install bearlibterminalAnother step to enlightenment. Works (or should work) on Windows and Linux, 32 and 64 bit. OS X package is not built yet, my virtual machine with OS X is such a pain.

Use it like this:

Code: [Select]

from bearlibterminal import terminal

Yes! Excellent. That makes distribution without py2exe much easier.

Edit: Actually, the command isn't working for me (Windows, 32-bit Python 3.4.2):

Code: [Select]

Downloading/unpacking bearlibterminal
  Could not find any downloads that satisfy the requirement bearlibterminal
Cleaning up...
No distributions at all found for bearlibterminal
Storing debug log for failure in C:\Users\***\pip\pip.logI just installed coverage without issue, so it's probably not a problem with pip.
Further info:

Code: [Select]

------------------------------------------------------------
C:\Python34\Scripts\pip run on 07/07/16 10:19:47
Downloading/unpacking bearlibterminal
  Getting page https://pypi.python.org/simple/bearlibterminal/
  URLs to search for versions for bearlibterminal:
  * https://pypi.python.org/simple/bearlibterminal/
  Analyzing links from page https://pypi.python.org/simple/bearlibterminal/
    Skipping https://pypi.python.org/packages/41/b4/d6a4adbc6e55a6de2da4a19ecde5754b2751afb0a2343b27825bcff8b263/bearlibterminal-0.14.1-py2.py3-none-manylinux1_x86_64.whl#md5=b13677b4d7684c647f0cc6ac6edb8826 (from https://pypi.python.org/simple/bearlibterminal/) because it is not compatible with this Python
    Skipping https://pypi.python.org/packages/92/6c/31ba239c46aed3f9646aa5933b34c248518bf81ac849a008d9130b9f45bd/bearlibterminal-0.14.1-py2.py3-none-win_amd64.whl#md5=39041b4b091a07506796a024db280a47 (from https://pypi.python.org/simple/bearlibterminal/) because it is not compatible with this Python
    Skipping https://pypi.python.org/packages/b3/68/42e384a8aaaa947444860a14e72c631c307c03b021ae2f28ed81a07d88bf/bearlibterminal-0.14.1-py2.py3-none-win32.whl#md5=5751a886a02ed66ccff8dde7167dfc2f (from https://pypi.python.org/simple/bearlibterminal/) because it is not compatible with this Python
    Skipping https://pypi.python.org/packages/e3/a5/ecdffa53ddea705c0e5300cec3d156d66eef7f7a3a352223adcf62c887b5/bearlibterminal-0.14.1-py2.py3-none-manylinux1_i686.whl#md5=5882658e846bfbd5d3cc32a5a1862da1 (from https://pypi.python.org/simple/bearlibterminal/) because it is not compatible with this Python
  Could not find any downloads that satisfy the requirement bearlibterminal
Cleaning up...
  Removing temporary dir C:\Users\***\AppData\Local\Temp\pip_build_***...
No distributions at all found for bearlibterminal
Exception information:
Traceback (most recent call last):
  File "C:\Python34\lib\site-packages\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Python34\lib\site-packages\pip\commands\install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "C:\Python34\lib\site-packages\pip\req.py", line 1177, in prepare_files
    url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File "C:\Python34\lib\site-packages\pip\index.py", line 277, in find_requirement
    raise DistributionNotFound('No distributions at all found for %s' % req)
pip.exceptions.DistributionNotFound: No distributions at all found for bearlibterminal
It looks like "https://pypi.python.org/packages/b3/68/42e384a8aaaa947444860a14e72c631c307c03b021ae2f28ed81a07d88bf/bearlibterminal-0.14.1-py2.py3-none-win32.whl#md5=5751a886a02ed66ccff8dde7167dfc2f" should have been identified as compatible with my python version.

[Cfyz]

Looks like your Python somehow does not accept a fairly generic 'py3-none-win32' tag. Can you show me what does it print for:

Code: [Select]

import pip
print(pip.pep425tags.get_supported())

[Quendus]

Code: [Select]

[('cp34', 'none', 'win32'), ('cp34', 'none', 'any'), ('cp3', 'none', 'any'), ('cp33', 'none', 'any'),
('cp32', 'none', 'any'), ('cp31', 'none', 'any'), ('cp30', 'none', 'any'), ('py34', 'none', 'any'),
('py3', 'none', 'any'), ('py33', 'none', 'any'), ('py32', 'none', 'any'), ('py31', 'none', 'any'),
('py30', 'none', 'any')]

[Cfyz]

Edited out.

[Cfyz]

From the current pip code (here) it looks like pip must list py3-none-win32 as supported. Is your pip outdated by any chance? There was a relevant bug two years ago.

[Quendus]

Updating pip fixed the problem. Thanks!

[Bretsky]

Been working on a project using your terminal. Everything works great, except one little thing. I think it's due to the way I've written my code. When I run my game, the BearLib Terminal window pops up blank, and stays blank until there is some kind of input.

The basic structure of my code is:

Code: [Select]

brlb.open()
brlb.set('window.title={d}; font: roguelike_font.ttf, size=12; window.size={w}x{h};').format(d=self.dungeon.name, w=self.screen_x, h=self.screen_y))
brlb.refresh()
closed = False
while closed == False:
brlb.refresh()
if brlb.has_input():
closed = self.on_move_events() #handles input, updates screen, and returns True if the window should be closed

Am I doing something in the wrong order here that is causing that to happen? Not a huge annoyance, as the game appears as soon as you move your mouse, but I would like to fix it. Thanks again for making an awesome API!