BearLibTerminal: a pseudo-terminal window library for roguelike

[LisacPisac]

How well suited would BearLibTerminal be for developing a MUD?

EDIT: For example, the implementation of a scrollback buffer?

[Cfyz]

How well suited would BearLibTerminal be for developing a MUD? EDIT: For example, the implementation of a scrollback buffer?

Well, the library is built around a grid of cells, so there is no built-in scrolling buffer. But take a look at example #9 "formatted log" in SampleOmni. The library supports formatted output with wrapping and cropping, which should make implementing scrollable buffer easy.

I notice that certain tricks and interesting things aren't mentioned in the API reference. Things like the various tags that can be used in print functions and such. It'd be great if you could expand the documentation in that direction.

Somehow missed your post. Hm, string formatting is documented (see terminal_print function). I agree that less obvious features and techniques should be pointed out and explained, though.

[NoahTheDuke]

Is there a bug in the Python binding, in color_from_argb?

I've tried to recreate the Basic Output sample, and the color-shifting has thrown me:

Code: [Select]

for i in range(long_word_len):
    factor = i/long_word_len
    red = (1 - factor) * 255
    green = factor * 255
    terminal.color(terminal.color_from_argb(255, red, green, 0))
    terminal.put(2+n+i, 1, long_word[i])

results in a value of `4294901760.0` being sent to `_library.terminal_color()`, which results in a `ctypes.ArgumentError: argument 1: <class 'TypeError'>: wrong type. I don't know much about bitwise operations, but does

Code: [Select]

def color_from_argb(a, r, g, b):
    result = a
    result = result * 256 + r
    result = result * 256 + g
    result = result * 256 + b
    return result

return the same result as

Code: [Select]

TERMINAL_INLINE color_t color_from_argb(uint8_t a, uint8_t r, uint8_t g, uint8_t b)
{
return ((color_t)a << 24) | (r << 16) | (g << 8) | b;
}
?

Have I made a gross mistake in my for-loop?

Thanks either way! This library looks great, once I figure this out.

EDIT:

Fixed the problem! I changed the "return result" to be "return int(result)" so the program now runs, but it's displaying the colors differently than the provided compiled exe:


Left is provided exe, right is my Python test. Is one of them wrong? Is the sample code more recent than the sample exe? Either way, thanks!

[Quendus]

In Python 2,

Code: [Select]

factor = i/long_word_len sets factor = 0 each time. In Python 3, the same code sets factor equal to a floating point value each time. I assume you're using Python 3. Then

Code: [Select]

red = (1 - factor) * 255
green = factor * 255 sets red and green equal to floating-point values, which you pass into BLT's color_from_argb(), which returns a floating-point value. BLT's color() only accepts integer values.

Hopefully this should be fixable by just using int(red) and int(green) when calling BLT's color_from_argb().

[Sceptre666]

I've been toying with this library for the past month or so and I have to say I'm really loving it. I'm using it to build a roguelike project, but it's also been my go-to whenever I need to write up a school project and don't want to deal with Curses. It's a shame I haven't seen more completed projects out there, considering how much time and love has obviously gone into the project.

Figured I would link something simple I made, hopefully to get the ball rolling a bit!

Conway's game of life, written in C.
https://github.com/SceptreData/cLife

[Omnivore]

Running into a strange bug with png fonts.  If I use set inside the program, I can set the font without any problems.   However, if I use the equivalent config file, I get a message: [error] Failed to set some options: Tileset::Create: main value attribute is missing.

Weird thing is, all the other settings in the config file are read without problem and apply just as if I'd used set in the program.  Only the font is a problem.

Otherwise, everything I need seems to be working quite fine.
Thanks again,
Brian aka Omnivore

PS: this is with the 0121 version, using 32 bit dll with Python v2.7.9 (32 bit) on Windows 8.1 (64 bit) platform.

[Cfyz]

If I use set inside the program, I can set the font without any problems.   However, if I use the equivalent config file, I get a message: [error] Failed to set some options: Tileset::Create: main value attribute is missing.

Yep, there was a bug. Fix is already pushed to the repository and I'll update binaries soon.

[Omnivore]

Nice  

Is there any way to specify a path for the font/tile files?  In an os independant manner?  I'd like to stick them in a 'data' or 'resources' folder/subdir.

Thanks once again,
Brian aka Omnivore

[Cfyz]

Is there any way to specify a path for the font/tile files?  In an os independant manner?  I'd like to stick them in a 'data' or 'resources' folder/subdir.

Yes. 'SampleOmni' does exactly that, keeping media files in ../Media directory. You should use Unix path separators (forward slashes) and Windows version will replace them with backslashes when opening a file.

[karlnp]

Nice work. Does BLT support building with VS2015?

[karlnp]

Also I can't for the life of me get it to work on CLion/Cygwin. I'm fairly inexperienced with CMake, though.

[Cfyz]

Does BLT support building with VS2015? <...> Also I can't for the life of me get it to work on CLion/Cygwin. I'm fairly inexperienced with CMake, though.

I have not paid much attention to building the library with different compilers/IDEs. Yet.

The idea was that binaries are fairly compiler and language-independent and there is no significant need to rebuild frequently (or as a part of a bigger project, even), just use a suitable header/binding. Right now if you do not trust provided binaries (this is Internet, after all) you can build BearLibTerminal standalone way from a command line (or CMake GUI) and then use it as a regular third-party dynamic-link library. This way you'll only need a recent CMake and a sane MinGW with POSIX threading model, i recommend TDM-GCC or mingw-builds.

I said 'yet' because sooner or later I'll make sure it works with popular IDEs, I'd just like to finish some refactoring before that.

[Aukustus]

I must say that I tried this with both C# and Python and I really liked this. If I had the energy I'd rewrite the rendering of The Temple of Torment into this one surely .

It was pretty hard to get started with it though, it required some experimentation, for example in getting multiple font files to work. It was mostly "hmm, lets see what happens if I do this", for the most part it worked as I expected though a good tutorial would have helped.

It would be pretty awesome if the RogueBasin's Python tutorial was modified by someone to use this for rendering and the libtcod would be used for the pathfinding and other utilities.

[Cfyz]

<...> in getting multiple font files to work. It was mostly "hmm, lets see what happens if I do this", for the most part it worked as I expected though a good tutorial would have helped.

This is one of the aspects I'm trying to fix =|.

While we are on this topic, I'll outline the things I'd like to address soon. Comments are welcome.

1. Multiple fonts seems to be useful (nice feature overall) but implementation is more of a hack around forward-backward codepage mapping. I plan to make fonts named so that one will be able to use a configuration like

Code: [Select]

font: UbuntuMono-R.ttf, size=12
bold font: UbuntuMono-B.ttf, size=12
icons font: Icons.ttf, size=14, spacing=2x1And then

Code: [Select]

terminal_printf(x, y+0, "[font=bold]AARGH[/font]");
terminal_printf(x, y+1, "Requires 2 [font=icons]*[/font] and 3 [font=icons][U+2345][/font]");There is also a 64k codepoints restriction. It would be nice to support full Unicode codepoint space, there are TrueType fonts with ranges beyond BMP.

2. There is one very internal thing. I've tried to make the library at least halfway thread-safe so as long as you do not call functions concurrently, which thread they are called from does not matter. This was achieved by running input and rendering from a separate hidden thread. However, on some platforms (e. g. OS X) you just cannot work with windows (i. e. input) from non-main thread and on some others (e .g. X11) things are not guaranteed to work reliably, though they usually does. This will not require to alter the API but some functions would be restricted to be run from the main thread (open/close, set, has_input, peek, read, read_str). You'll still be able to invoke all other functions (including refresh) from whatever thread. I just wonder how many people even thought about multi-threaded interface processing in terminal-like application >_< it's possible no one will even notice.

3. And after that, it would be possible to write some technique articles/examples as the feature/quirk set should hopefully be completed =_=.

[NoahTheDuke]

It would be pretty awesome if the RogueBasin's Python tutorial was modified by someone to use this for rendering and the libtcod would be used for the pathfinding and other utilities.

I'm working on my own roguelike, and once I'm at a place I feel comfortable sharing, I'm going to iterate over it in a tutorial fashion, and then post it up on RogueBasin. Which is to say, give me a month! :-D