BearLibTerminal: a pseudo-terminal window library for roguelike

[Cfyz]

and now when I import it, I'm getting strange errors.

This is because wrapper (.py) and binary (.dll) do not match. Specifically, you import the old wrapper since there is no such lines in the new one. There is no PyBearLibTerminal.py anymore either (see this), so you probably just copied the new dll only without updating the wrapper/repacking the app.

When I bundle the script with py2exe, it notices the 'from bearlibterminal' import clause and copies the module files (module installed by pip) into the bundle so there is no need to have an additional PyBearLibTerminal.py in your source. The .dll is another story, no bundler seems to be capable to auto-include binaries, so you have to copy this one manually to the exe directory.

[KM]

This is typically what makes me lose interest in Python; I can never get all the dependencies right.  I'm not able to pip anything; what should a folder with this working contain?

EDIT:
Nevermind, thanks Cfyz, I've got it working again. 

[Saafris]

I've been working on a project using this library (very happy with it!), and I'm planning for the future - specifically, if I want to do more advanced graphics than just what is included in the library.

For example, if I wanted a little orb to be circling around a character, I might use BearLibTerminal for placing all the tiles and sprites, but then do some graphics coding of my own for the orbiting orb.

Don't suppose there's any easy way to getting at the OpenGL so I can implement my own additional graphical effects on top of what's rendered, is there? Or would I have to fork, modify, and compile the library on my own?

Edit:
Project is in C++, by the way.

[Cfyz]

Don't suppose there's any easy way to getting at the OpenGL so I can implement my own additional graphical effects on top of what's rendered, is there? Or would I have to fork, modify, and compile the library on my own?

Indeed, there is currently no way to do custom rendering. Reliable custom rendering requires support and guarantees from the library, which is far from its focus of abstracting the output.

That said, I do try to make the library capable to perform various tricks without diving into relatively low-level stuff. For example, a circling orb may be implemented via overlayed tile with offset. Take a look at "Extended 1: basics" (lines 42-49) entry in SampleOmni, those circling characters are flying around one spot.

[Avagart]

Just figured out that you made BaerLibTerminal bindings for Go. It's awesome, I'll check it in the near future, but - already, thank you very much

[Elronnd]

Hi, is it possible to make it so that the cursor doesn't blink at all?  I tried setting terminal.set("input.cursor-blink-rate=0");, but that only made the cursor blink as fast as it could.  Can you special-case 0 so that the cursor doesn't blink at all when you set the cursor-blink-rate to 0; or set another boolean value, input.cursor-blink?

[Elronnd]

I made a set of D bindings!  Now guaranteed not to segfault: http://code.dlang.org/packages/bearlibterminal

[Cfyz]

Can you special-case 0 so that the cursor doesn't blink at all when you set the cursor-blink-rate to 0

Good idea. I was about to suggest using some really large number as a workaround in the meantime, but noticed you've done exactly that =).

I made a set of D bindings! Now guaranteed not to segfault

Ah, in the end I was not fast enough =|. Good in any case!

[Elronnd]

I made a set of D bindings! Now guaranteed not to segfault

Ah, in the end I was not fast enough =|. Good in any case!

Heh.  Yeah, it turned out that I just didn't know how to allocate memory properly.  I was going to write an sfml gui for my game, but then I decided I'd take just *one* more shot at getting bearlibterminal to work...and it did!

[Junkyardfreak]

So, can someone share a code snippet of a simple menu program in python with a title and 2 options; one to print something and the other to exit the window? I was unable to find much info about the Python bindings. Thanks!

[Cfyz]

The 'official' python binding follows the library API fairly closely. The simple snippet would probably be something along the lines:

Code: [Select]

from bearlibterminal import terminal
terminal.open()
while True:
terminal.clear()
terminal.puts(2, 1, 'Choose wisely:\n1. Print something\n2. Exit')
terminal.refresh()
key = terminal.read()
if key == terminal.TK_1:
terminal.clear()
terminal.puts(2, 1, 'something')
terminal.refresh()
terminal.read()
elif key in [terminal.TK_2, terminal.TK_CLOSE]:
break
terminal.close()
The clear+puts+refresh+read combination is a generic 'wipe clean, print some text and wait for any keypress' routine.

There are also some more sophisticated samples transcribed to Python available: https://github.com/ibatugow/blt_samples

[Saafris]

Don't suppose there's any easy way to getting at the OpenGL so I can implement my own additional graphical effects on top of what's rendered, is there? Or would I have to fork, modify, and compile the library on my own?

Indeed, there is currently no way to do custom rendering. Reliable custom rendering requires support and guarantees from the library, which is far from its focus of abstracting the output.

That said, I do try to make the library capable to perform various tricks without diving into relatively low-level stuff. For example, a circling orb may be implemented via overlayed tile with offset. Take a look at "Extended 1: basics" (lines 42-49) entry in SampleOmni, those circling characters are flying around one spot.

OK, that makes sense. I'm considering grabbing the source code of the library, and trying to modify it just so I can slide some of my own draw calls in before BearLibTerminal refreshes.
Any suggestions on where to start with that (or if it's even feasible)?

[Cfyz]

Any suggestions on where to start with that (or if it's even feasible)?

If you're doing this for your own project, it is actually very easy. After all, the overall scope is limited and you do not have to care about future compatibility that much.

At the very bottom of Terminal.cpp there is a small Terminal::Render function. Which invokes a full redraw+flush. The point between Redraw() and SwapBuffers() is probably the best place to insert any custom on-top rendering (or a callback to it). Currently there is little caching is done and no fancy features are used, so it is fairly safe, just do not mess with any global state like viewport or matrices. The projection matrix is configured to pixel coordinates suitable for using glVertex2i to draw 2D figures. Resources (textures, buffers) may be initialized pretty much anytime after terminal_open() since everything is already set up after that call.

The OpenGL version is not enforced in any way meaning you may end up with as little as OpenGL 1.2 but no higher that 2.x (the old fixed pipeline is used). This will break somewhat when I add support for OpenGL ES (which does not have fixed pipeline). Everything remotely complex (from mere NPOTD textures to shaders) must be tested for availability and loaded manually  before using.

[Saafris]

...custom on-top rendering (or a callback to it)...

Awesome, I'll look into that! It sounds like interacting with BearLib's layers would be more difficult and involved?

And what you're saying is the OpenGL I use will need to be functions available below version 2? I'm curious as to why you chose such an older version to work with - I admittedly don't know that much about the different OpenGL versions.

[Cfyz]

It sounds like interacting with BearLib's layers would be more difficult and involved?

A bit. The Terminal.cpp, line 2054 is where layers are drawn and same file, around line 2102 is a probable place to insert custom inter-layer rendering. The nuance is that textures are not switched/restored between layers unless necessary so you need to be careful here and restore texture state if changes were made.

I'm curious as to why you chose such an older version to work with

The answer is simple: to cover as much hardware and platforms as possible. For example, low-end hardware like EEE PC or virtual machines with severely limited graphics support. OpenGL 1.2 is enough for core functionality. This is what I meant by extra library support necessary to provide full-featured custom rendering -- the library would need to provide means to select/assert OpenGL versions and fallbacks across multiple platforms.

I plan to use some of the newer functionality, e. g. framebuffers and shaders for better scaling/filtering or cleartype-like glyph rendering, but this will be strictly optional.