Temple of The Roguelike Forums

Developers => Programming => Topic started by: Cfyz on February 27, 2014, 01:31:51 AM

Title: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 27, 2014, 01:31:51 AM
With mixed feelings of pride and uncertainty I present you a project I've been working on for some time. This is a library aimed to simplify the interface part of a roguelike development. Something along the lines of libtcod but focused primarily on output, maybe ncurses will be a closer example.

(Yup, I am no native English speaker so please bear with me =_=.)

The library is available from http://foo.wyrd.name/en:bearlibterminal (http://foo.wyrd.name/en:bearlibterminal). The documentation is also there, though somewhat incomplete. However, the rest will follow in time and the library itself is practically done, so I believe there is no point to delay its "international" release any longer.

This library provides you with a window and allows for easy tile and tileset manipulation while keeping pretense that the scene is mainly text or pseudographics. Quick example:
Code: ("c") [Select]
#include "BearLibTerminal.h"

int main()
{
    terminal_open();
    terminal_set("window: size=32x8");
    terminal_set("font: UbuntuMono-R.ttf, size=12");
    terminal_print("Hello, ωōrlд!"); // UTF-8
    terminal_refresh();
    terminal_read();
    terminal_close();
    return 0;
}

(http://foo.wyrd.name/_media/en:bearlibterminal:example_helloworld.png)

The library is not for C/C++ only. As it is a dynamic-link library, it also has bindings for C#, Pascal, Lua and Ruby, which should make it suitable for rapid prototyping. It also runs on Windows and Linux.

There is a showcase named "SampleOmni" included in the download archive. You may be surprised at how much can be squeezed from the measely 20 functions of the library API.

Well, I hope it helps someone =)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: koiwai on February 27, 2014, 05:39:37 AM
Looks neat. I read the original forum briefly, the library was in development for quite a while. And it looks versatile and crossplatform. The examples with layers resemble Cairo documentation, btw. I tried to compile the source code on my 64bit Linux, and it failed at libfreetype2. (Unless I did something wrong with cmake)
Code: [Select]
/usr/bin/ld: ../Dependencies/FreeType/libfreetype2-minimal-static.a(ftbase.c.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
../Dependencies/FreeType/libfreetype2-minimal-static.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Terminal/CMakeFiles/BearLibTerminal.dir/build.make:790: recipe for target 'Output/libBearLibTerminal.so' failed
make[2]: *** [Output/libBearLibTerminal.so] Error 1
CMakeFiles/Makefile2:128: recipe for target 'Terminal/CMakeFiles/BearLibTerminal.dir/all' failed
make[1]: *** [Terminal/CMakeFiles/BearLibTerminal.dir/all] Error 2
Makefile:75: recipe for target 'all' failed

But it seems that FreeType2 is available for my distribution, and most likely for other distributions too. Maybe, I can use my native library to build BeaR on a 64bit system?

Another question. Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?

Also, I suppose that the library is distributed under some unspecified free / open source conditions, right?  ;D I did not find anything specific about the license, but it's good to have one.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on February 27, 2014, 07:50:25 AM
This looks very useful. Having a license would be a good idea. If it's a permissive license I may use it instead of NotEye for this year's 7DRL. Also I'd recommend distributing as .zip or .tar.gz; not everyone has 7-zip installed.

Edit: looking at the source code, it seems to be distributed under the MIT license. I haven't checked all the source files for it and there doesn't seem to be a license file applying to the whole library.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 27, 2014, 08:21:42 AM
Quote from: koiwai
I tried to compile the source code on my 64bit Linux, and it failed at libfreetype2. (Unless I did something wrong with cmake)
It's unlikely to be your fault, the 64bit builds are just not tested yet. The code should be okay though, it mostly build configuration problem. I'll try to fix this soon.

However, do note that code relies on C++11 features, which essentially requires GCC 4.8+. I'll probably try to make it more compiler-friendly, as lower GCC versions had pretty good C++11 support and MSVC is improved greatly with VS2013 release, but for now it is not supposed to be a part of a project source. Instead, if there is no suitable build yet, compile it separately and include the binary in the project.

Quote from: koiwai
Maybe, I can use my native library to build BeaR on a 64bit system?
You should be, by replacing include_directories and target_link_libraries in the ./Terminal/CMakeLists.txt file. The intention behind including a copy of freetype2 code is to make sure the game will rasterize TrueType identically down to the pixels on every platform. It is important when mixing TrueType main font with bitmap tilesets.

Quote from: koiwai
Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?
Not sure I understood you here. The library binary is supposed to be distributed along with an application, but mostly because I do not imagine it in installer form =). The location of sources is up to you.

Quote from: koiwai
I did not find anything specific about the license, but it's good to have one.
Quote from: Quendus
If it's a permissive license I may use it instead of NotEye for this year's 7DRL.
The library is licensed under MIT. It is stated so in every source file, headers and bindings included =). Shoud have mentioned that on the site too, probably.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on February 27, 2014, 08:30:41 AM
Brilliant )))
A license file inside the source distribution would also help to make it clear.

The mouse input sample behaves strangely for me. When I scroll nothing happens, but if I then click, rhe scroll state updates. Would it be possible for the scroll wheel to emit an event (with the change in the scroll state) instead?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 27, 2014, 08:49:30 AM
Quote from: Quendus
The mouse input sample behaves strangely for me. When I scroll nothing happens, but if I then click, rhe scroll state updates. Would it be possible for the scroll wheel to emit an event (with the change in the scroll state) instead?
It can emit an event. In the demo there is a list of input mask flags at the top-left corner, you can select "mouse scroll" there. By default only key presses and releases produce the events but mouse movement (cell or pixel-level) and mouse wheel scrolls may be included there as well. The configuration string would be
Code: [Select]
terminal_set("input.events=keypress+keyrelease+mousescroll");and the event itself is TK_MOUSE_SCROLL.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Z on February 27, 2014, 02:37:58 PM
Is there any relation to Bear (http://forums.roguetemple.com/index.php?topic=4.170) who was a long time rgrd regular (I don't know if he is still posting there) and a RogueTemple poster?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 27, 2014, 03:25:06 PM
Quote from: Z
Is there any relation to Bear who was a long time rgrd regular
No =) "bear" here is a reference to the "BeaRLibrary" collection of roguelike-oriented libraries from the russian rlgclub.ru forum (like, russia = bears >_<). There are at least separate BearLibMG (map generation) and BearLibPF (pathfinding) libraries, though I have no connection to them.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: koiwai on February 27, 2014, 04:54:08 PM
Thank you for the clarification regarding the license.

Quote from: koiwai
Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?
Not sure I understood you here. The library binary is supposed to be distributed along with an application, but mostly because I do not imagine it in installer form =). The location of sources is up to you.
My question was mostly about packaging BearLibTerminal for Linux: A library can be installed as a separate package (like ncurses or SDL do, for example). Alternatively, I can simply copy BearLibTerminal source code in my source code, and distribute them both as a single piece. One more approach, when building from sources, is to fetch both my code and BearLibTerminal code from their repositories, build together at the user's machene and install the game.

Sorry for compicating things, but when developing an open source game, I want to be sure that a user will be able to build the game without much hassle.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on February 27, 2014, 07:37:24 PM
I used cmake to generate a VS2013 project for SampleOmni. It compiles and it can find the BearLibTerminal.dll file, but it crashes when main() starts. Maybe I configured it wrong.

However, I compiled the small example program and it runs fine. I'm playing with terminal_put_ext() now. I'll resist the temptation to put Cyrillic monsters in my 7DRL!

I think Python is very popular with roguelike developers, so a python binding would probably add a lot of potential users.

Also, it would be nice for code completion if the api functions and constants were in a namespace, like one of these:
Code: [Select]
bl::terminal_refresh();
blt::terminal_refresh();
bl::refresh();
blt::refresh();
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on February 28, 2014, 11:14:09 AM
I've made a simple example of smooth movement using exponential decay. You can find the code at https://dl.dropboxusercontent.com/u/6433222/bear_term_smooth.cpp (https://dl.dropboxusercontent.com/u/6433222/bear_term_smooth.cpp). It's public domain, so you're free to add it to OmniSample or do whatever you want with it. I expect you'll want to change the way I wrote the terminal_set() commands.

When you use a movement command, the character's map position changes, but its offset dx,dy is changed so that the screen position stays the same. Every frame, dx and dy decay towards 0 with a custom half-life (in milliseconds).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 01, 2014, 12:21:22 AM
Updated the library to version 0.9.8: http://foo.wyrd.name/en:bearlibterminal#download (http://foo.wyrd.name/en:bearlibterminal#download)

koiwai, I fixed the project a bit and now it should compile fine on 64-bit systems. Also I've changed CMake project structure for easier incorporation into another project's source tree. Now entire library source with all its dependencies is under ./Terminal directory (so the root CMakeLists.txt and this directory is all you need) and ./Samples is now optional. If you remove samples directory before CMake generation, it won't complain about that and will build just the library.

Quote from: Quendus
it would be nice for code completion if the api functions and constants were in a namespace
Well, the problem is that C++ header is also header for C which do not have namespaces. Where it is not a case (e. g. C# or Ruby) API functions are indeed grouped under some namespace. Also I'm not sure what you mean by "code completion", as IDEs auto-complete current variant just fine (checked MSVS and Eclipse).

Quote from: Quendus
I used cmake to generate a VS2013 project for SampleOmni. It compiles and it can find the BearLibTerminal.dll file, but it crashes when main() starts. Maybe I configured it wrong.
Whoa. I have not had my hands on VS2013 yet and given how different GCC and MSVC are I expected it to fail right from the start =) Looks like they did a good job fixing C++11 support. I will make library compileable by MSVC later, but for now you should either build it with MinGW or just use a prebuilt binary. Not that I discourage you from experimenting =)

If it crashes in terminal_open, it might not be MSVC's fault, as there was a mistake in calling convention of OpenGL extension function. Whether it will crash or not somehow depended on compiler optimization options and usually it was ok. Fixed now.

Quote from: Quendus
I'll resist the temptation to put Cyrillic monsters in my 7DRL!
Angry ё (like e but with eyes open), spider Ж, butterfly Ф, paired monsters Я and R. Well, there is not much actually, I think Greek is better material as it is generally more familiar (think math). My favourite one is Ω, which is, of course, a wind spirit (see fūjin (http://en.wikipedia.org/wiki/F%C5%ABjin)).

Quote from: Quendus
I've made a simple example of smooth movement using exponential decay.
Nice one. I think I'll include it into samples though most likely edit it beyond any recognition >_<. And I have some comments about the code If you don't mind...

It might be a matter of preference but I thing constructing configuration string that way is rather cryptic. There is a printf-like version of set:
Code: [Select]
terminal_setf("window: size=%dx%d, cellsize=%dx%d, title='%s'", TERM_WIDTH, TERM_HEIGHT, CHAR_WIDTH, CHAR_HEIGHT, TITLE_STR.c_str());
Quote
// what do I do if I want to use argc, argv?
Well, then you just do not use TERMINAL_TAKE_CARE_OF_WINMAIN macro and declare main yourself. It's just a bit of sugar to get rid of all those HINSTANCE and Windows.h include as most of the time graphical applications do not take command-line arguments anyway.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 01, 2014, 05:07:28 AM
Thanks for the comments. I didn't see terminal_setf when I looked at the API and samples. It's a much better solution.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 07, 2014, 01:11:06 AM
Is there any possibility of compiling this for mac as well? Would any changes to the source code be required?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 07, 2014, 11:35:28 AM
Right now it is impossible to compile it on Mac. The library creates a UI window on its own via OS API calls and that requires platform-specific code. Such code is isolated by implementing a subclass of the BearLibTerminal::Window, e. g. X11Window or WinApiWindow. However, after that the rest will require just a few simple tweaks. Mac is very close to Linux but interacting with OS requires Objective-C and right now I have zero experience with that. I do plan to port it to Mac, just can't say when =(

As a relatively quick hack I can try to make 'generic' window implementation via SDL. This will obviously introduce a library dependency, but can help with portability as the rest of the code is mostly platform-agnostic.

By the way, I lowered compiler requirement to GCC 4.6.3, which comes with much more distros than 4.8. Trying to support even lower versions will require rewriting a lot so I stop here for now. As for MSVC, VS2013 is pretty good, I'll make library code support it shortly. And actually Windows is more lenient here as one can use VS2013 to compile a binary that will run on any sensible Windows version, i. e. from XP to 8. In Linux 64-bit version can't link statically to libstdc++ thus for library to run on different distros, it have to use the lowest possible version of libstdc++.

Also, about compiling SampleOmni with VS2013. I've found a rather shameful mistake in sample code. In WindowsGlyphList.cpp the list of ranges was initialized from references to temporaries rather than actual objects, fixed now. Well, working okay with some particular compiler also falls under UB =)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 14, 2014, 12:27:17 PM
Contrary to how it might look, the project is alive. Not very popular though, but oh well.
Version 0.10: http://foo.wyrd.name/en:bearlibterminal#download (http://foo.wyrd.name/en:bearlibterminal#download)

I did try to make SDL-based window implementation but somehow it resulted into a mess. SDL is good, robust library when you start from it and build your app around its infrequient quirks. However, integrating it into project (half of which functionality is window management) halfway is not as simple as it seems. I've found myself working more against SDL than with it. Therefore, Mac port is delayed for now.

Instead I've refactored the input subsystem (which was a mess by itself) a bit and implemented a couple of new features. Nothing really breaking, though.

1. Minor adjustments in constants naming like TK_PAGEUP or TK_MOUSE_LEFT instead of WinAPI-legacy TK_PRIOR and TK_LBUTTON. Constants related to mouse or numpad are now grouped together: TK_MOUSE_xxx, TK_KP_xxx.

2. Input event categories are removed. There was an input.events option before which allowed to 'subscribe' on keypresses or keyreleases or mouse with somewhat inconsistent mechanics. For example, TK_CLOSE is better not to be ignored (what category it is?), same with TK_RESIZED. And actually there is no real difference between keypress and keyrelease for application as user always can press a whole lot of random buttons you will have to ignore anyway. So now the read function does read everything (like GetMessage, ha), you just have to handle only those events you're interested in.

3. Next is read_ext. A thing with somewhat obscure logic. It was introduced because it was necessary to read both event scancode and character code produced by that event: terminal_read_ext(TK_READ_CHAR). Ugh, somehow it did not fazed me in the slightest that there was already mouse events where you can read both the event and mouse properties at the same time: via terminal_state(TK_MOUSE_xxx). Therefore, the read_ext is removed and two new states are introduced: TK_CHAR and TK_WCHAR. They simply return the code of a character produced by the latest read input event, or zero if none was produced:
Code: [Select]
int key = terminal_read();
if (key == TK_ESCAPE)
{
   return;
}
else if (terminal_state(TK_WCHAR) > 0)
{
   str += (wchar_t)terminal_state(TK_WCHAR);
}
TK_WCHAR returns an Unicode codepoint of the character and TK_CHAR return an ASCII/ANSI codepoint translated accordingly to the codepage selected with the terminal.encoding option.

There was also non-blocking input via read_ext but it can easly implemented without additional API methods:
Code: [Select]
// Both literally,
int key = terminal_has_input()? terminal_read(): 0;

// ...and logically
while (terminal_has_input()) {
   int key = terminal_read();
   ...
}
Oh, there is also TK_EVENT that will return a scancode of the last dequeued input event.

4. Mouse input has been extended. There are new TK_MOUSE_X1 and TK_MOUSE_X2 buttons which are additional buttons on some mouse models. There is new TK_MOUSE_CLICKS state that return a number of fast consecutive clicks by the time of the last dequeued mouse button event. E. g. terminal_state(TK_MOUSE_CLICKS) == 2 indicated that this TK_MOUSE_LEFT event is the second one in double-click action.

Also, TK_MOUSE_WHEEL now returns scroll delta instead of some global counter.

5. You can press Alt+Enter to switch between windowed and fullscreen mode (with no display resolution change). The window.fullscreen option may be used to force the fullscreen mode programmaticaly.

6. You can press Alt+[plus/minus] to scale the window up and down. This may be useful if some application uses tiny tileset and you want to run it on FullHD+ display. For now it is done via simple OpenGL scene scaling. Later I'll try to take advantage of shaders where they are supported. But you cannot scale resizeable window (window.resizeable option) as it would allow for a number of difficult configuration cases I'm not yet sure how to deal with.

7. There is also a couple of debug key combinations: Alt+G will turn on cell grid and Alt+A will dump the texture atlas on disk.

The up-to-date reference on the input subsystem is located here: http://foo.wyrd.name/en:bearlibterminal:reference:input (http://foo.wyrd.name/en:bearlibterminal:reference:input)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 14, 2014, 01:57:41 PM
Another update: v0.11.1: http://foo.wyrd.name/en:bearlibterminal#download (http://foo.wyrd.name/en:bearlibterminal#download)

'print' function now allows for text alignment and autowrap. This is done via formatting tags.

Code: [Select]
T.print_(40, 12, "[align=bottom-right]Spike Vixen\nGrease Monk")(https://dl.dropboxusercontent.com/u/3661545/BearLib/2014-08-13/align-bottom-right.png)

Code: [Select]
T.print_(40, 12, "[bbox=30x10]Void Initiate: gain 1 rune. "
                 "You may banish a card in your hand or "
                 "discard pile.")
(https://dl.dropboxusercontent.com/u/3661545/BearLib/2014-08-13/bbox.png)

Dimensions of an autowrapped string may be calculated without printing with the 'measure' function:
Code: [Select]
int height = terminal_measuref(L“[bbox=%d]%ls”, width, ws.c_str());
Using simple in-text iconographics or alternative fonts is a bit easier now:
Code: [Select]
terminal_print(“One [font=0xE000]Two”);(https://dl.dropboxusercontent.com/u/3661545/BearLib/2014-08-13/fonts.png)

Code: [Select]
T.print_(2, 1, "This spell requires: 2[0xE004] 3[0xE022]")
T.print_(2, 3, "The scroll says \"[font=0xE100]whatewer[/font]\"")
(https://dl.dropboxusercontent.com/u/3661545/BearLib/2014-08-13/fonts-mixing.png)

By combining these features it is fairly easy to implement text output with basic formatting, scrolling dynamically adjustable output area. It is demonstrated in SampleOmni showcase. I would add a picture here but it is big and I can't find a spoiler tag =_=.

And there is now a Python wrapper which works with 2.x and 3.x versions:
Code: [Select]
import PyBearLibTerminal as T

T.open()
T.print_(2, 1, “Hello, wordl”)
while True:
    T.refresh()
    key = T.read()
    if key == T.TK_CLOSE or key == T.TK_ESCAPE:
        break
T.close()

#bearlibterminal #nobodycares #everyonereadsthetags
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Brigand on August 25, 2014, 02:55:59 PM
Wow, played around with this over the weekend, and it seems to be almost exactly what I am looking for - very nicely done! Makes me want to abandon my current project and start a new one using this. I like libtcod, but I only want that display functions and not all the other stuff it brings along (along with a bit of a learning curve.)


3 quick questions:

1) Do you plan on including any basic drawing functionality? We're just talking simple colored lines, or maybe an ellipse function. (For drawing UI borders and such.)

2) When using composition to stack tiles on the same location on the same layer, is there any way to make a copy of the composed tile and save it off as a temporary (or even permanent) tile that can be reused, or would I always need to rebuild (recompose) the tile each move?

3) Similar to question 2, is there a function to simply copy an area of the screen and paste it somewhere else? (It wouldn't need to retain all the layers; purely just a pixel copy of a designated space, placed into it's own layer in a different spot.)

Sorry if these question are already answered - I have been reading the API reference on your webpage, and I have a feeling they are already answered and I am just not searching for my answers with the right phrase.

Again, very nice library - please continue to develop it :)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 26, 2014, 10:07:24 AM
Thanks for your feedback =)

Quote from: Brigand
Do you plan on including any basic drawing functionality? We're just talking simple colored lines, or maybe an ellipse function. (For drawing UI borders and such.)
Not sure. Such "classic" drawing primitives do not combine well with cells/characters architecture. The library does not draw tiles the moment you issue 'put' or 'print' command but constructs a 'scene description' for later render. This allows more 'terminal'-way operation where you can replace some of the characters while leaving everything else intact. This also allows library to redraw the scene all by itself if necessary. Lines and circles are rather foreign to characters-based modifiable scene structure, and I do not see a way to make a clear API with those.

I had considered going all the way to the optional 'custom' output via some callbacks hooked into a scene (e. g. to a layer). Inside callback you would have a different drawing context where you can do things differently because it does not buffer drawing commands. And from the API perspective it becomes very clear that mechanics are different because mode change is intentional and obvious. However, it has a whole new lot of problems not completely thought out yet so the priority of this is fairly low.

As for UI, wouldn't it be enough to just prepare a few tiles for borders and corners?

Quote from: Brigand
When using composition to stack tiles on the same location on the same layer, is there any way to make a copy of the composed tile and save it off as a temporary (or even permanent) tile that can be reused, or would I always need to rebuild (recompose) the tile each move?
Right now the only option is to reconstruct them every time. Given the scene architecture it is not as straightforward as copying pixels, but I think its possible to allow to save an output string (which usually goes to 'print' and supports combining via formatting) as a precomputed template, e. g. like this:
Code: [Select]
terminal_set("0xE100: 'a[+][color=red]/'");
terminal_put(2, 1, 0xE100);
Though it will take a decent amount of coding =).

Quote from: Brigand
Similar to question 2, is there a function to simply copy an area of the screen and paste it somewhere else? (It wouldn't need to retain all the layers; purely just a pixel copy of a designated space, placed into it's own layer in a different spot.)
As I mentioned above, pixel copy is almost impossible and layers do make a problem. However, it indeed may be a useful feature, will think about it. What do you intend to use it for exactly?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Brigand on August 26, 2014, 12:09:12 PM
I had considered going all the way to the optional 'custom' output via some callbacks hooked into a scene (e. g. to a layer). Inside callback you would have a different drawing context where you can do things differently because it does not buffer drawing commands. And from the API perspective it becomes very clear that mechanics are different because mode change is intentional and obvious. However, it has a whole new lot of problems not completely thought out yet so the priority of this is fairly low.

As for UI, wouldn't it be enough to just prepare a few tiles for borders and corners?

Yeah, I could just use tiles to make the border and other effects....especially if I could scale and rotate the tiles  ;)


Quote from: Brigand
Similar to question 2, is there a function to simply copy an area of the screen and paste it somewhere else? (It wouldn't need to retain all the layers; purely just a pixel copy of a designated space, placed into it's own layer in a different spot.)
As I mentioned above, pixel copy is almost impossible and layers do make a problem. However, it indeed may be a useful feature, will think about it. What do you intend to use it for exactly?

I was just thinking in terms of performance, which probably isn't an issue :) If you have 10 enemies and the player, and each is composed of 10 layered tiles (body, armor, boots, cloak, weapon, helmet, effects, etc), along with other layered/composed parts of the scene... If you could save each off beforehand you could just redraw a single tile reducing the number of tile look-ups/copies by a factor of 10.

Again, this was just me thinking through a future problem - the reality is I probably would get to the point I described above and find the performance almost completely identical in both cases.

Either way, still very well done - whatever the ultimate answer is, it won't deter me from checking this out and seeing what I can do with it.

Thank you again for your hard work, and please keep at it - even if people don't seem to respond or give much feedback, there are some of us who still are very grateful for your efforts.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Wattmann on October 30, 2014, 04:29:49 PM
A newbie's question: any tutorial on using this work of art hehe?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on October 31, 2014, 01:22:27 PM
Sorry but there is no such thing yet. For now there are only a function reference (http://foo.wyrd.name/en:bearlibterminal:reference) and a number of short C++ examples (https://bitbucket.org/cfyzium/bearlibterminal/src/d798f8cec2301ccbef75858009e27c8e3cfa784a/Samples/Omni/Source/?at=default). I'd like to say I'm working on it but sadly I'm a bit busy right now =|. I do plan to make a regular tutorial though. Probably based off one already popular like libtcod's or something =).

However, I'll answer any questions. It would help to at least know what language and platform you are using so I'll be able to take those into account later.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Wattmann on November 01, 2014, 02:06:56 PM
Ah thanks a lot! So far I'll be playing with the reference and samples to see what I can do. I'm using C++ with MinGW GCC 4.8 (I think) or the latest regular Clang from 27.10.2014. (whichever I feel like I guess) on Win7 Ultimate 64-bit.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on November 28, 2014, 05:01:37 AM
#bearlibterminal #nobodycares #everyonereadsthetags
I care! BLT is my first choice for a roguelike display/input library at the moment. It has much more flexibility as a display system than libtcod, and isn't bloated with mapgen/fov features. Text alignment/wrapping, inline icons, and Python support are great additions.
I haven't written any games since the March 7DRLC (health problems), but when I start again I'll be very pleased to continue using BearLibTerm.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Wattmann on December 05, 2014, 06:40:34 PM
Been a while hehe but I've gotten round to playing with it again and, well, got this thingy here --- "error: 'terminal_delay' was not declared in this scope". Every other thing I've used works so it's not bad linking, and I copied it off the API reference a couple of times just to make sure I wasn't doing something bad. Oversight?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 09, 2014, 01:26:13 PM
Sorry for the delay, was somewhat busy =_=.

Quote from: Wattmann
got this thingy here --- "error: 'terminal_delay' was not declared in this scope". <...> I copied it off the API reference a couple of times just to make sure I wasn't doing something bad. Oversight?
Pretty much. I've updated the library but got distracted, messed up the links and did not post about it >_<. Try redownload the 0.11.3 version.

The 0.11.3 update:
* terminal_pick* (http://foo.wyrd.name/en:bearlibterminal:reference#pick) functions to examine cell contents.
* terminal_peek (http://foo.wyrd.name/en:bearlibterminal:reference#peek) to preview an input event.
* terminal_delay (http://foo.wyrd.name/en:bearlibterminal:reference#delay) to pause the execution a bit.
* There is no input.sticky-close option anymore (it has introduced more problems than it solved).
* Input filtering added. By setting the input.filter (http://foo.wyrd.name/en:bearlibterminal:reference:input#input_options) option one can select which events will be returned by terminal_read (e. g. keyboard keypresses only) and which will be ignored.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Wattmann on December 12, 2014, 02:40:08 AM
Made a brainfuck interpreter in the library for general practice :D

Might be offtopic, but the library is fast enough to make it viable!

Edit: hey, I'm gettin bits of issues: when I run the .exe normally it sets itself up OK but when I run it with cmd.exe it doesn't set up the font. Any ideas why?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on February 27, 2015, 09:22:00 AM
This is quite nice. I've got it working with C# already, I have dungeon generation ported in from an earlier game project, and the API of BearLibTerminal seems quite well-thought-out. Kudos! I'm just not sure how to use a custom codepage. If I have an image like https://dl.dropboxusercontent.com/u/11914692/Zodiac-Narrow.png (https://dl.dropboxusercontent.com/u/11914692/Zodiac-Narrow.png), where the first row corresponds to Unicode U+0000-U+007F, and the second row to U+2500-U+257F , how would I get the codepage to load? I've already tried making a file, custom.txt , with the text "U+0000-U+007F, U+2500-U+257F" like the encodings in BLT's source use, but every glyph displays as a box (the not-found glyph). Does the file have to be an embedded resource? The image isn't...
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 27, 2015, 11:26:08 AM
Quote from: Wattmann
when I run the .exe normally it sets itself up OK but when I run it with cmd.exe it doesn't set up the font. Any ideas why?
Somehow I did not receive any forums notifications and notice this question only now =/. As for the library behaviour, it most likely attributes to possibly different working directories when run in different ways. Try to look for bearlibterminal.log, the library will complain there if it can't find the file.

Quote from: notostraca
I've already tried making a file, custom.txt , with the text "U+0000-U+007F, U+2500-U+257F" like the encodings in BLT's source use, but every glyph displays as a box (the not-found glyph).
Hmm, every glyph? I've tried using your image:

Code: (test.lua) [Select]
T.set("font: ./Zodiac-Narrow.png, size=12x24, codepage=./Zodiac-Narrow.txt")
T.print(2, 1, "Hello, world! [U+256C] [U+2573]")
Code: (Zodiac-Narrow.txt) [Select]
U+0000-U+007F, U+2500-U+257F
And its mostly working. The regular text (U+0000-U+007F, "hello world" part) is output in the correct font. With the U+25xx glyphs there is a bug, though. The library has built-in generator for Box Drawing and Block Elements unicode ranges in case the font doesn't have those -- or if it is a TrueType font which rarely have useful Box Drawing characters. Bitmap fonts should have higher priority but I've made a mistake there. I'll upload a fixed version later today.

Even with this bug you should not be getting glyph-not-found boxes.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on February 28, 2015, 07:46:55 AM
My source is here, in case there's something obviously wrong: https://github.com/tommyettinger/DungeonRising (https://github.com/tommyettinger/DungeonRising).  The code starts in DungeonRising/Entry.cs (here https://github.com/tommyettinger/DungeonRising/blob/master/DungeonRising/Entry.cs#L81 (https://github.com/tommyettinger/DungeonRising/blob/master/DungeonRising/Entry.cs#L81)); it calls Terminal.Put(int, int, char) each time it wants to render something.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 28, 2015, 11:38:29 AM
Quote from: Cfyz
I'll upload a fixed version later today.
Here it is, 0.11.4 (http://foo.wyrd.name/en:bearlibterminal#download).

Quote from: notostraca
My source is here, in case there's something obviously wrong
Well, this gets weirder. I've downloaded the source, opened it in VS2013, switched startup project to 'Runner32' and hit 'Run': screenshot (https://dl.dropboxusercontent.com/u/3661545/dungeon-rising-1.png).

Try setting 'log.level' option before other configuration, i. e.
Code: [Select]
Terminal.Set("log: level=trace");
Terminal.Set("window: title='Dungeon Rising', size=110x45; font: Zodiac-Narrow-6x12.png, size=6x12;");
Post a screenshot and generated 'bearlibterminal.log', maybe that will give me some clue.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on February 28, 2015, 12:49:14 PM
I haven't tested noto's code so I don't have a clue what I'm talking about, but is it possible that the issue is with the working directory not being the same as the directory with the font image?
VS seems to have a habit of making the working directory different from the executable directory, and this has stung me before when using eg. libtcod.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on February 28, 2015, 05:25:50 PM
Yeah, I posted a working version to Github, the line I highlighted didn't have a codepage set. If you still have the project, change the only line that calls Terminal.Set (it's in Entry.cs, method Run) to:
Code: [Select]
Terminal.Set("window: title='Dungeon Rising', size=110x45; font: ./Zodiac-Narrow-6x12.png, size=6x12, codepage=./custom.txt;");I've set it to copy custom.txt (in each of the Runner projects) to the output directory, same as the png. cfyz, I'll try 0.11.4 now, could you maybe fiddle with the codepage settings in that line?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on February 28, 2015, 05:51:54 PM
I just posted an update to GitHub, using 0.11.4, and I have a screenshot, log, and debug build.
Log:
Code: [Select]
09:39:39.901 [Info] Trying to set "window: title='Dungeon Rising', size=110x45; font: ./Zodiac-Narrow-6x12.png, size=6x12, codepage=./custom.txt;"
09:39:39.904 [Debug] Group "window":
09:39:39.904 [Debug] * "size" = "110x45"
09:39:39.905 [Debug] * "title" = "Dungeon Rising"
09:39:39.905 [Debug] Group "font":
09:39:39.906 [Debug] * "codepage" = "./custom.txt"
09:39:39.906 [Debug] * "name" = "./Zodiac-Narrow-6x12.png"
09:39:39.907 [Debug] * "size" = "6x12"
09:39:39.907 [Debug] Tileset resource name "./Zodiac-Narrow-6x12.png" is recognized as a name of a bitmap resource
09:39:39.908 [Debug] Bitmap tileset: failed to parse guessed tile size, not an error
09:39:39.909 [Debug] Requested resource "./custom.txt" with possible prefix "codepage-"
09:39:39.909 [Debug] Requested resource "./Zodiac-Narrow-6x12.png" with possible prefix "tileset-"
09:39:39.911 [Trace] Loaded PNG image, 768x24
09:39:39.911 [Debug] Tileset has 128x2 tiles
09:39:39.912 [Debug] Successfully loaded a tileset for base code 0
09:39:39.912 [Debug] Reloaded the tileset with base code 0
09:39:39.913 [Trace] Scheduling texture #103078664 for removal
09:39:39.914 [Trace] Added tile texture #103078664
09:39:39.914 [Info] Added Unicode replacement character tile (6x12)
09:39:39.915 [Debug] SetOptions: new cell size is 6x12
09:39:39.915 [Debug] SetOptions: new window size is 110x45
Screenshot:
(https://dl.dropboxusercontent.com/u/11914692/DungeonRising_BoxProblem.PNG)
Debug Build: x86 https://dl.dropboxusercontent.com/u/11914692/DungeonRisingDebugBoxProblem_x86.zip (https://dl.dropboxusercontent.com/u/11914692/DungeonRisingDebugBoxProblem_x86.zip)
and x64 https://dl.dropboxusercontent.com/u/11914692/DungeonRisingDebugBoxProblem_x64.zip (https://dl.dropboxusercontent.com/u/11914692/DungeonRisingDebugBoxProblem_x64.zip)

Quendus, your answer seems likely, given the log; it mentions loading the png but not the codepage.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 28, 2015, 07:02:53 PM
Figured this out, after a bit of meditation over two identical .txt files, one working as a codepage and one not. I do not see UTF-8 files with BOMs (http://en.wikipedia.org/wiki/Byte_order_mark) often, so my own tests did not catch that. And the ad-hoc parser used for codepages turned out to be too simple to handle it.

For now you should just remove the BOM (File -> Advanced Save Options -> UTF-8 without signature). I'll release another bugfix shortly =_=.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on March 01, 2015, 02:19:09 AM
Yep, that was it. I committed the 2-character change and now it works. You're a master! Now I just need to make a game...
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on March 01, 2015, 02:41:08 AM
Here's a fairly simple and complete BOM detector I wrote awhile back in D, should be easy to port or at least give an idea.  https://gist.github.com/Brian61/298fba834f851bf95be2 (https://gist.github.com/Brian61/298fba834f851bf95be2).

Switched to C# in my latest project and spent yesterday creating the interface between my new project and BearLibTerminal :)

Quick questions:
In the string passed to set, is whitespace necessary between the separators (':',',',';')?   Also is extra whitespace permissible at end of string, and lastly are embedded line endings allowed?

And another :)
If you attempt to get a char value via: Terminal.State(Terminal.TK_CHAR) during a non printable char event (mouse for ex), do you just get 0?  (Update: went source diving and it looks to be the case.)

Finally, a suggestion: For some uses in C#, the list of const int TK_XXX symbols in BearLibTerminal.cs would be much better represented as a public enum outside the Terminal class, say as public enum TerminalKeys {...}.  Its not a huge deal since you can do as I've done and just cut-n-paste the list of symbol = value, pairs.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 02, 2015, 01:31:59 PM
Quote from: Omnivore
Here's a fairly simple and complete BOM detector I wrote awhile back in D, should be easy to port or at least give an idea.
That's a nice snippet, gonna save it. I'm not sure about such variety of encodings in this case though, I thought ANSI/UTF-8 would be enough for external text files. Do you think UTF-16/32 encoded files should also be supported? (since it will be a bit of a hassle).

Quote from: Omnivore
In the string passed to set, is whitespace necessary between the separators (':',',',';')?   Also is extra whitespace permissible at end of string, and lastly are embedded line endings allowed?
No, whitespaces are cosmetic there, extra ',' and ';' are also ignored and trailing ';' is optional. As for newlines, it is an oversight and it may or may not work depending on where you place that newline. I'll fix and document this in the next update.

Quote from: Omnivore
If you attempt to get a char value via: Terminal.State(Terminal.TK_CHAR) during a non printable char event (mouse for ex), do you just get 0?  (Update: went source diving and it looks to be the case.)
Yes, you figured it out correctly. The idea is that value of TK_CHAR may be used to determine whether last stroke was textual or not.

Quote from: Omnivore
For some uses in C#, the list of const int TK_XXX symbols in BearLibTerminal.cs would be much better represented as a public enum outside the Terminal class, say as public enum TerminalKeys {...}.
A lot of constants represent both an input event and a state, e. g. TK_A which may be returned by Read and also may be tested by State/Check. It's either using one single enum or duplicate a lot of constants in separate enums. And one huge list just does not look like enum since its values not equally meaningful within same context. C# is not my area of expertise, so I may miss some fundamental feature or strict community preferences here, but this list of constants does not seem that bad =_=.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on March 02, 2015, 02:38:40 PM
Do you think UTF-16/32 encoded files should also be supported? (since it will be a bit of a hassle).
No, but it may be worth detecting them and throwing/returning an error to the user.

As for newlines, it is an oversight and it may or may not work depending on where you place that newline. I'll fix and document this in the next update.
Cool :)  I'm loading the initial settings from an external file, while I can strip the line endings, it'd be nice I think for future users if it wasn't necessary.

The idea is that value of TK_CHAR may be used to determine whether last stroke was textual or not.
Good.  I'm processing the input and sometimes grabbing the value when I don't really need it just to simplify the code, was more worried about causing an internal error accidentally.

Quote from: Omnivore
For some uses in C#, the list of const int TK_XXX symbols in BearLibTerminal.cs would be much better represented as a public enum outside the Terminal class, say as public enum TerminalKeys {...}.
A lot of constants represent both an input event and a state, e. g. TK_A which may be returned by Read and also may be tested by State/Check. It's either using one single enum or duplicate a lot of constants in separate enums. And one huge list just does not look like enum since its values not equally meaningful within same context. C# is not my area of expertise, so I may miss some fundamental feature or strict community preferences here, but this list of constants does not seem that bad =_=.
While I wouldn't call it bad in this case, I believe it is considered 'C# best practice' to use enums instead of lists of constants.  In my particular use case, I'm making use of the ability to get a string name from the enum by its value.  I turn the input events into string descriptors (plus extra data for char value, mouse position, etc) which then is used in a user configurable command table.  It allows an easy to implement key map file with lines of the form: "T.CONTROL = JUMP_SIDEWAYS".

Being able to use the enum to turn the integer value into a string ("TK_T" in this case) and then strip the "TK_", add the ".CONTROL" if the control key state is true, etc.  Having the values of a long list in a C# enum saves a lot of typing which could potentially introduce errors.   Its not a major issue since you can do as I've done and simply cut and paste the list of integer constants into an enum, but that is a potential maintenance problem if the constants are expanded or changed - probably not much of a chance of that in this case.

Anyhow, thanks for doing this library :)  It fits in quite well with the data structures I'm using and since I had a 'layers' variable for the imaging already, its nice to be able to use it for something other than a sort order key!  Also the guy that's been doing artwork for me will be glad to hear that he can stack tiles and layers since that seems to be the common practice in the portion of the graphics industry he works in.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 02, 2015, 04:05:18 PM
Quote from: Omnivore
In my particular use case, I'm making use of the ability to get a string name from the enum by its value.
http://ideone.com/Ah494k (http://ideone.com/Ah494k)
I did it mostly for lulz but if your main concern is type conversion, it might actually help to get rid of some copy-paste.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: notostraca on March 23, 2015, 05:07:38 AM
OK, Terminal.PutExt is just awesome.  I have creatures vibrating wildly within their cell for a moment when damaged, and it was extremely easy to add with BearLibTerminal. Brief video preview: http://a.pomf.se/kmyrvl.webm (http://a.pomf.se/kmyrvl.webm).  I'm going to try to port BearLibTerminal to Mac OSX soon (a friend who looked into the code told me that the same X11 window API used on Linux should mostly work on OSX), but first I am having trouble building the lib on Windows -- I posted an issue on BitBucket.  I'm really hoping that the Mac port is feasible and can be incorporated into the main code, at least, if I ever get it to work. Cfyz, are you opposed to using a cross-platform library that handles windowing on the (perfectly reasonable) grounds of not wanting a sizable extra dependency, or is there some technical aspect of BearLibTerminal that makes SFML, GLFW, or similar libraries unusable with it?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 23, 2015, 11:56:43 AM
Quote from: notostraca
Cfyz, are you opposed to using a cross-platform library that handles windowing on the (perfectly reasonable) grounds of not wanting a sizable extra dependency, or is there some technical aspect of BearLibTerminal that makes SFML, GLFW, or similar libraries unusable with it?
No, I do not oppose this. Whatever the reasons for using homebrew window implementations once were, they do not stand now. Not only OS X, there are also Wayland and various EGL flavours and reimplementing the wheel becomes clearly counterproductive. Ability to change icon in runtime or to resize window in discrete steps just not worth it.

I do plan to delegate windowing to GLFW. In the very near future. This, however, will require some work: current BearLibTerminal uses two threads with rendering in background, which is ok under Windows (which gave me a false impression) and somehow works under most of Linux, but as it turns out it is not guaranteed to work reliably or work at all. Making BearLibTerminal single-threaded will not require any changes in its API (probably, no one will even notice) but this will be a big overhaul in the code. I really appreciate your willingness to contribute but it looks like I'll have to clean up this mess myself.

Quote from: notostraca
OK, Terminal.PutExt is just awesome.
I wonder if anyone using corner-coloring in put_ext. I hope no one is. It does not work uniformly (with final result depending strongly on particular hardware, ugh) and restricts some possible optimizations, so I plan to remove it.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 24, 2015, 04:01:08 PM
Here comes a new update of questionable nature. It fixes a few things like UTF-8 BOM handling in external text files and X11 window title modification, but the main addition is the configuration file.

The idea to add some alternate configuration mechanism came from inability to configure logging options before the library is initialized, which effectively prohibits useful verbose output during the initialization step. The most obvious way would be to allow library configuration before initialization. Using the same terminal_set mechanism, but before terminal_open, is hacky and still requires application modification to switch log verbosity. Meh. Therefore, I decided to add a configuration file in a simplest INI format, which somehow went out of control.

Not only logging, but all library options might be specified in the configuration file, even fonts/tilesets. Furthermore, only the "BearLibTerminal" section is used for initial library configuration and all other sections in the file are left for the application. By utilizing omnipotent terminal_set and newly added terminal_get it is possible to read, add, modify and remove properties in the file:
Code: [Select]
terminal_set("ini.settings.window-size=80x25"); // Save preferred interface size.
int tile_size = terminal_get<int>("ini.settings.tile-size", 16); // Read requested tileset size.

See API / configuration (http://foo.wyrd.name/en:bearlibterminal:reference:configuration) page for more detailed information.

Downloads are here (http://foo.wyrd.name/en:bearlibterminal#download).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on March 24, 2015, 04:15:50 PM
You sir, are awesome :)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zanetski on June 23, 2015, 01:26:28 AM
Just tried it out... this library is amazing! I really like how the API is less verbose than libtcod. Definitely my preferred choice now.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Tooth on July 12, 2015, 08:32:00 PM
I don't know if this is exactly the right place to post this, but there aren't any other BearLibTerminal forums as far as I can tell, so might as well. I seem to be having some issues with this library. I created a small main.cpp that just opens and closes the terminal to make sure the library works, but when I try to link it with the library, I keep getting "undefined reference to '_imp__terminal_open()' and '_imp__terminal_close()'". I think the prefix is just name mangling, so I'm not concerned with that, but whatever I do, I can't get the linker to find definitions for the functions. The command I used was "g++ main.cpp -L. -I. BearLibTerminal -lBearlibTerminal -o main" along with several variants of that which changed orders, added extra -l s or .lib s  or almost anything else. Everything gives the same error. Also of note, I am using Mingw64 with the MSYS2 shell, if that's at all relevant. Any help with this would be great, as I'm really excited about BearLibTerminal and want to use it if at all possible.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 12, 2015, 09:42:09 PM
Yes, this is the right place, the amount of discussion/issues does not justify a dedicated forum (hmm, yet?). On another thought, issues should go to issue tracker (https://bitbucket.org/cfyzium/bearlibterminal/issues?status=new&status=open) of the repository. Always forget there is one.

The problem with linking is that MinGW linker does not seem to understand Windows import libraries (the .lib accompanying .dll, usual for MSVC), but it considers such library first while searching. So it finds BearLibTerminal.lib, tries to link against it and complains there is still no implementation. MinGW, however, is fully capable to link against .dll, so you just need to remove the .lib file. The working command is pretty much what you've used:
Code: [Select]
g++ -I. main.cpp -L. -lBearLibTerminal -o main
Noted this down, such nuances really should be documented =_=.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Tooth on July 12, 2015, 10:29:12 PM
Hmm...
I tried that command. It now says "./BearLibTerminal.dll: file format not recognized." I also tried it on another MinGW(normal, not 64) shell and a Cygwin shell that I had lying around, and both did the same thing. I thought DLLs were pretty much the standard for windows external libraries, so I don't really understand how this could be the case. Are my toolchains set up incorrectly?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 12, 2015, 10:50:19 PM
This most likely means compiler and library do have different bitness. It sometimes not obvious: rare compiler build shows what its available/target bitnesses are. Requesting the mode manually usually helps identify the problem.

For example, using 32-bit TDM-GCC and 64-bit .dll:
Code: [Select]
g++ main.cpp -L. -lBearLibTerminal -o main
./BearLibTerminal.dll: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
Now explicitly specifying I want it to be 64-bit (to match the library):
Code: [Select]
g++ -m64 main.cpp -L. -lBearLibTerminal -o main
main.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
Now replacing the library with 32-bit version does help.

Btw, MSYS/Cygwin are unnecessary here as BearLibTerminal.dll is a regular Windows library.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Tooth on July 12, 2015, 11:18:29 PM
Ah! That's done it!
32bit version of the library works for me. It's weird though that MinGW64 didn't work with a 64bit library though...
In any case, thank you so much Cfyz! Now to make a game!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Xangi on July 29, 2015, 07:23:13 AM
So, trying to use this in VS2012 for C# I'm getting this http://puu.sh/jh89p/d6c2d8767b.png
When I looked up what to do I found that I had to run some kind of tool, which I tried and got this http://puu.sh/jh8bD/5518b8ff84.png

Not sure what's going on, but apparently it's because this wasn't compiled with .NET?

EDIT: I also tried just adding the DLL, same error I was getting before. It can't find the DLL to actually use it so it crashes at runtime.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 29, 2015, 08:18:58 AM
You do not need to reference the library binary in any way. The .dll piece is pure native code with plain C interface. However, you will obviously need to place it in 'working directory' of the application (usually just besides the application executable; this is true for VS2015 at least, not sure about other VSs and it may be overrided in project settings).

The .\Include\C#\BearLibTerminal.cs file is the one that needed to be included in the project (there is a bunch of DllImports in there). You will also need System.Drawing assembly referenced.

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Xangi on July 29, 2015, 08:28:23 AM
So I did all of that and it works now, but the 64bit dll still crashes. At least I've got functionality though, thanks man. Also the default C# console stays open even when the terminal is open, I'm assuming that's normal.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 29, 2015, 10:16:47 AM
Most likely 64-bit dll 'crashes' because the application is 32-bit. You cannot use 64-bit libraries from 32-bit application and vice versa. Even though your application is .NET, it all comes down to native code instructions at some point. Hence the 'Build' -> 'Platform Target' / 'Prefer 32-bit' options in project settings. I do not know of a way around this short of rewriting the whole Terminal in C#. And 32-bit works everywhere anyway.

Default console is there because of application type ('Application' -> 'Output Type' in project settings), switch it to 'Windows Application'. You could have created windows project instead but then MSVS would generate an unnecessary window form, switching one option is easier.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Untrustedlife on August 02, 2015, 03:38:50 AM
Looks interesting, Ill check it out.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on October 10, 2015, 07:04:07 PM
Hey! Your library looks great, and I'm trying to make a roguelike with it. However, as usual, I get stuck at the beginning. Namely, it seems that terminal_set() does absolutely nothing in my game. It doesn't change the window size, font, or anything. I am using Windows 8.1 64-bit Pro, with MinGW 4.8.

I compile it with
g++ map.cpp -L. -lBearLibTerminal -o map.exe -static-libgcc -static-libstdc++

Could you please help me out?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on October 10, 2015, 07:29:24 PM
Look if there is bearlibterminal.log being generated near your executable (or in the directory you run the program from); if there are issues with configuration string, the library will complain there. If the situation not becoming clearer, post the code sample with your terminal_set call, it will help diagnosing the problem.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on October 11, 2015, 09:00:02 AM
Here's a paste of my code.

http://pastebin.com/NaWYrqNk
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on October 11, 2015, 10:48:48 AM
Now, this one was easy. Somehow documentation was missing the fact that before terminal_open no other library call will do anything, my bad.
So just swap open and set around.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on October 11, 2015, 11:11:15 AM
Dead simple. Thanks! Also, on the topic of documentation, reading through the replies of this thread, 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on October 21, 2015, 09:49:36 AM
How well suited would BearLibTerminal be for developing a MUD?

EDIT: For example, the implementation of a scrollback buffer?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on October 21, 2015, 11:19:18 AM
Quote from: LisacPisac
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.

Quote from: LisacPisac
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 (http://foo.wyrd.name/en:bearlibterminal:reference#print) function). I agree that less obvious features and techniques should be pointed out and explained, though.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: NoahTheDuke on November 06, 2015, 03:35:07 PM
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:

(http://i.imgur.com/wyD8lkp.png)
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!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on November 06, 2015, 10:18:01 PM
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().
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Sceptre666 on November 20, 2015, 03:06:33 AM
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 (https://github.com/SceptreData/cLife)

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 06, 2015, 02:48:31 AM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 07, 2015, 10:54:15 AM
Quote from: Omnivore
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 (https://bitbucket.org/cfyzium/bearlibterminal) and I'll update binaries soon.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 09, 2015, 02:18:02 PM
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
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 09, 2015, 02:46:43 PM
Quote from: Omnivore
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: karlnp on December 10, 2015, 10:14:13 PM
Nice work. Does BLT support building with VS2015?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: karlnp on December 10, 2015, 11:49:15 PM
Also I can't for the life of me get it to work on CLion/Cygwin. I'm fairly inexperienced with CMake, though.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 11, 2015, 01:51:03 PM
Quote from: karinp
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 (http://tdm-gcc.tdragon.net/) or mingw-builds (http://mingw-w64.org/doku.php/download/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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Aukustus on December 12, 2015, 09:09:43 PM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 14, 2015, 12:25:32 PM
Quote from: Aukustus
<...> 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=2x1
And 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 =_=.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: NoahTheDuke on December 15, 2015, 05:00:16 AM
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
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 15, 2015, 11:00:07 PM
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.

Ah, this explains the delayed shutdown.  I'd been wondering why the process sticks around for half a minute after the window closes.

Frankly, it's over-engineering, in my opinion.   Most UI frameworks I've worked with in the past have required access through only the main thread for a variety of reasons.  I suspect that anyone considering the use of multi-threading would expect that and be aware of the workarounds. 

For a roguelike, I believe multithreading is overkill.  I've run tests on some of the heaviest algorithms in use for roguelikes and they really don't benefit from parallelization (via multithreading or otherwise) at the present time.  Context switch cost along with data exchange cost just destroys any performance gain.  If someone is multithreading for other reasons, most languages today have some form of lightweight thread-like mechanism available that mostly alleviates the need.

The only case that immediately springs to mind where multithreading might conceivably be worth the headache would be in procedural generation of maps.  Even then, it is quite possible to use lightweight mechanisms to emulate the desired behavior.  In any case, I can't see any reason why such a background task would need to communicate with the UI.

As the adage goes, if you think you have a problem that will be solved by multiple threads, you now have two problems.

Just my 2c worth,
Brian aka Omnivore
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 17, 2015, 03:56:07 PM
Quote from: Omnivore
Ah, this explains the delayed shutdown.  I'd been wondering why the process sticks around for half a minute after the window closes.
Wait, what? The window with all its resources (thread included) should be completely released after terminal_close. Do you have some scenario reproducing this behavior?

Quote from: Omnivore
Frankly, it's over-engineering, in my opinion.
Indeed it is, I just thought I would be able to cover a few more cases at some reasonable cost and it turned out the cost is big. As for parallelization, what I meant was more in the direction of rendering offload, when world processing (model) is done separately from drawing its state (view). There is even an example of it in this very thread (notostraca's test a few pages ago). It is fairly common approach in more complex games or visualization applications, not sure to which extent it applies to roguelikes. Probably some sandbox-style game with lots of actors (with their own task queues) would benefit from this.

Most of the tasks I can come up with to run in parallel do not interact with rendering/interface directly. As you mentioned, it's hard to parallelize efficiently usual algorithms so I'd offload something more high-level like chunked world generation for seamless travel or continuous processing of world objects while they are out of sight.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 17, 2015, 07:05:15 PM
Quote from: Omnivore
Ah, this explains the delayed shutdown.  I'd been wondering why the process sticks around for half a minute after the window closes.
Wait, what? The window with all its resources (thread included) should be completely released after terminal_close. Do you have some scenario reproducing this behavior?

Windows 8.1, 64bit OS, 32bit Python 2.7.9, BearLibTerminal_0121 32bit dll, simple script just loading fonts, displaying a screen, and the normal event loop that falls through to close() after receiving TK_CLOSE event from read().  Script ends, nothing special after calling close().  The terminal window closes promptly, but process hangs around for around 30 seconds before returning to the command prompt.

Hope that helps,
Brian aka Omnivore
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on December 19, 2015, 09:10:08 PM
I have a small, but I believe important request. When setting the window size, IE. to 120x60, could you make it so that it doesn't create a [60][120] arrangement, but a [120][60] one, since it's more natural because of arrays. That is to say, you don't address column, then row, but rather row and then column as is the case with arrays.

Thanks!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 21, 2015, 01:32:48 PM
LisacPisac, sorry but I don't understand what you're talking about. With simple put(x, y, c) and print(x, y, s) functions you can't even see if there is any underlying array, let alone how it is allocated. You can fill cells in any order you want.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on December 21, 2015, 02:12:02 PM
Right, but what if I am using a standard array to store data about the map? The array uses a [row][column] format, where as the terminal itself uses a [column][row] format. And so, if I am to translate data from the array into the terminal in the right order, using two for loops using counters 'i' and 'j', I address my array as array[j]. Which is counter intuitive.

Okay, granted, perhaps I am doing something TERRIBLY WRONG and don't realise :P
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 22, 2015, 12:13:18 AM
There's no fundamental reason, for a rogue-like, to use row, column format storage arrays.  Your data accesses will tend to be rectangular - changing in both x and y so there's no real speed or cache difference between x, y and y, x formats.   If it is causing you problems, switch your storage array to use a [column][row] format.

More and more these days, I don't even use arrays for map data storage.  I suspect I'm not alone.  Hash maps, sets, and simple lists using immutable coordinate keys and object ids are a solid alternative.  Particularly with layered output, the 'map' never exists as a singular entity until it hits the screen. 

Hope this helps,
Brian aka Omnivore - and Happy Holidays to all :)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on December 28, 2015, 03:47:31 PM
Quote from: notostraca
OK, Terminal.PutExt is just awesome.
I wonder if anyone using corner-coloring in put_ext. I hope no one is. It does not work uniformly (with final result depending strongly on particular hardware, ugh) and restricts some possible optimizations, so I plan to remove it.
Is this still going to happen? I wouldn't miss the corner-colouring feature at all, because its main effect is to make me use an array of four copies of a single colour whenever I use put_ext. A single colour argument would be much preferable.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 28, 2015, 08:16:58 PM
Quote from: Quendus
its main effect is to make me use an array of four copies of a single colour whenever I use put_ext. A single colour argument would be much preferable.
But you can pass NULL there to use the current foreground color...
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on December 28, 2015, 10:03:39 PM
When drawing tile maps, I prefer to specify each tile's colour in the call to put_ext. It just feels neater (even with the weird requirement to make an array of colours). I would do the same with layer if it was an optional parameter in put_ext.

Leaving the foreground colour alone also means I don't have to worry about accidentally drawing strings in the wrong colour (as old versions of DoomRL, NPPAngband(?), et al did). Colour as a global persistent state variable just feels like an unnecessary legacy from ncurses.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 29, 2015, 12:55:29 PM
When I said remove I meant for good. Output attributes as non-persistent parameters is understandable idea and helps performance (about 30% actually). But there are several attributes: foreground and background colors, layer index and replace/combine 'composition' flag. Adding everything to the function looks clunky, put_ext then will have nine arguments! But leaving one or two of them will look inconsistent. Why only foreground color? Why there is no such color argument in the regular put then? I don't see a clear solution for this.

Personally I'd just wrap it in the two-line function. This won't help with miscoloring but that itself is arguable as it's better to always set every relevant state before a logically separate action.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on December 29, 2015, 01:30:46 PM
Not sure the complexity it worth it as it can just as easily be done in user code, but...  you could define a state structure and, to avoid headaches in passing structures back and forth- add a set of state management functions.  create_state, select_state as a minimum.  Then the user would create a state for a given type of operation and select that state during the op.  Could have select_state return the current 'old' state, then the user could just swap contexts.  Its similar to how GDI in Windows is managed in some frameworks.  Each state would hold everything except the character/symbol information.

From my perspective, I'm just as happy to roll my own user side state management - if I need it. 

Hope this helps,
Brian aka Omnivore

PS: Could go as far as: put_ext(x, y, char, state_token); the create_state call could copy the current state so the user would only change what differs in the new state.  Sounds simple, I'm probably overlooking something!

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 26, 2016, 06:33:41 PM
Here we go, version number thirteen, codenamed "better late than never". OS X is supported now.

As it was mentioned before, OS X support necessitated some changes so library is now single-threaded and must be used from the main thread only. I do have a solution to make drawing possible to be used from another thread (nope, not a global lock :-)), but it will introduce slight overhead in library operation and I am not sure if this feature even needed. Most of the time the code can be easily pseudo-parallelized anyway. For now, attempt to call some key functions from a non-main thread will result in window closing (mostly correctly though abruptly) and a relevant message in the log.

Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0132.zip) and Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0132.tar.bz2) versions do not change much (aside from threading) and OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0132_osx.zip) version archive includes a dylib with library_name=@executable_path and an awkward SampleOmni.app bundle.

Next is full unicode codespace and a sane additional font management.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 27, 2016, 04:56:56 AM
It's great that BLT games can be run on OSX now. Thanks for all your hard work.
I've found a few issues while testing it on an OSX virtualbox:
* PyBearLibTerminal.py hasn't been updated to find the .dylib file.
* Keyboard input pages in SampleOmni is quite strange - it seems to read several keys (arrows, shift, w, a?) as being held down. This could be due to problems in virtualbox, though.
* In the previous version, I remember mouse events being passed to read() by default. Either this default has changed or mouse input doesn't work (but this could be virtualbox)
* While experimenting in the Python repl, I was able to read the correct value from state(TK_SHIFT). However, state(TK_CONTROL) was always 0, whether I held down the control key or the windows/apple key. Again, it might be due to problems in virtualbox. However, it does raise the issue of how BLT should respond to the apple key. I see that the windows and alt keys are ignored by design - on OSX, it might make more sense to ignore the control and alt keys.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 28, 2016, 12:29:55 AM
Quote from: Quendus
* PyBearLibTerminal.py hasn't been updated to find the .dylib file
Whoops. Fixed than for Python and Ruby wrappers.

I'm thinking about making a pip package for python, one that will include library binary as well. Did you know that not long ago they made it possible to include linux binaries in python wheels? What I'm not sure about is what package-module structure to use. Namespaced packages which would allow "from bearlib import terminal" (leaving a chance to add another BearLibSomething, particularly map generation) are cool but reported to be fragile (pip issue #3 (https://github.com/pypa/pip/issues/3) -- does this matter? I do not use Python enough to be sure). The other choice is 'from bearlibterminal import terminal' which is just a bit clunky.

Quote from: Quendus
* In the previous version, I remember mouse events being passed to read() by default. Either this default has changed or mouse input doesn't work (but this could be virtualbox)
Yeah, I went and changed the defaults which was a bit hasty and wasn't even mentioned, sorry; reverted, reuploaded, 0.13.1. I do think input filter should have a default value, though. A lot of the time you need keypresses only and filtering everything out makes input logic cleaner in simple cases (e. g. sketching or beginners' programs).

Quote from: Quendus
* Keyboard input pages in SampleOmni is quite strange - it seems to read several keys (arrows, shift, w, a?) as being held down. This could be due to problems in virtualbox, though.
* While experimenting in the Python repl, I was able to read the correct value from state(TK_SHIFT). However, state(TK_CONTROL) was always 0, whether I held down the control key or the windows/apple key.
Please check the fixed version; at the very least, SampleOmni might've looked like some keys have been stuck because it wasn't getting keyup events. I do not see any problems with keyboard input in my VMWare virtual machine though (even reading the state of Ctrl from Python), will try to run on a real Mac.

Quote from: Quendus
However, it does raise the issue of how BLT should respond to the apple key. I see that the windows and alt keys are ignored by design - on OSX, it might make more sense to ignore the control and alt keys.
It does look like the library should provide Cmd key access as it is seems to be what Ctrl is to Windows. I do not think ignoring Ctrl is correct though, it will  make porting apps harder.

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?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 28, 2016, 12:59:58 AM
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 (https://bitbucket.org/cfyzium/bearlibterminal/pull-requests/3/updated-python-bindings-to-match-other/diff) 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 28, 2016, 08:48:22 AM
One disadvantage to the new single-threaded architecture: I often develop interactively (using the Python REPL or IPython (https://ipython.org/)). 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?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 28, 2016, 10:20:16 PM
Quote from: Quendus
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 29, 2016, 01:52:02 AM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 29, 2016, 11:29:36 AM
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 (http://ipython.readthedocs.org/en/stable/config/eventloops.html?highlight=Integrating%20with%20GUI%20event%20loops) well.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 29, 2016, 12:27:38 PM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 29, 2016, 04:13:08 PM
There you go: PyBearLibTerminal.py (https://bitbucket.org/cfyzium/bearlibterminal/src/f14cd7e885c2aa21dc5f927b5b9c0d425c7b7300/Terminal/Include/Python/PyBearLibTerminal.py?at=default&fileviewer=file-view-default) (relevant diff (https://bitbucket.org/cfyzium/bearlibterminal/commits/695f481c777de9683b93df3a13fa323bbb96d89f?at=default)). 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 29, 2016, 05:13:30 PM
Perfect. Thanks so much!

Here's a BearLibTerminal sandwich for you:
(http://joesdining.com/wp-content/uploads/2012/05/BLT-Sandwich.jpg)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Jan on March 30, 2016, 09:28:32 PM
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 (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).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on March 31, 2016, 06:29:57 AM
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 (http://www.fileformat.info/info/unicode/char/2588/index.htm). 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: ffred60 on April 01, 2016, 12:47:16 PM
Hi,
just discovered BearLibTerminal. looks great !  :D
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()
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 03, 2016, 01:57:22 AM
Quote from: Quendus
Quote from: Jan
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 (http://pastebin.com/fVWfTicT)):
(http://foo.wyrd.name/_media/wiki:bearlib:advanced-window.png)

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 (https://bitbucket.org/cfyzium/bearlibterminal/src/2488e95f9ce3265d17d10b87240ccf92a9f95f3d/Terminal/Include/Python/PyBearLibTerminal.py?at=default&fileviewer=file-view-default) from repository.

Quote from: Quendus
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 (http://dwarffortresswiki.org/Tileset_repository) fonts) since handpicked bitmap tiles have priority over auto-generated ones.

Quote from: ffred60
is there Lua use documentation or a small example somewhere..?
Reference documentation (http://foo.wyrd.name/en:bearlibterminal:reference) 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 (https://bitbucket.org/cfyzium/bearlibterminal/src/f14cd7e885c2aa21dc5f927b5b9c0d425c7b7300/Samples/Omni/Source/?at=default)) should translate from one language to another fairly easily. Sadly there are no proper language-specific tutorials yet.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: ffred60 on April 04, 2016, 06:02:39 AM
ok, thanks..
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on April 11, 2016, 03:29:00 PM
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/ (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
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 11, 2016, 05:06:04 PM
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 (https://bitbucket.org/cfyzium/bearlibterminal/src/2488e95f9ce3265d17d10b87240ccf92a9f95f3d/Samples/Omni/Source/DynamicSprites.cpp?at=default&fileviewer=file-view-default#DynamicSprites.cpp-117)). 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on April 11, 2016, 07:14:20 PM
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 (https://bitbucket.org/cfyzium/bearlibterminal/src/2488e95f9ce3265d17d10b87240ccf92a9f95f3d/Samples/Omni/Source/DynamicSprites.cpp?at=default&fileviewer=file-view-default#DynamicSprites.cpp-117)). 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
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 12, 2016, 01:06:35 PM
Quote from: Omnivore
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.

Quote from: 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.

Quote from: Omnivore
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Omnivore on April 12, 2016, 01:39:10 PM
Quote from: 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.

Quote from: Omnivore
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

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 22, 2016, 09:37:00 PM
An update. Say, 0.14 (http://foo.wyrd.name/en:bearlibterminal#download) (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 (http://foo.wyrd.name/en:bearlibterminal:reference:configuration#font_and_tileset_management).

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].");
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on June 25, 2016, 11:39:26 AM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on June 25, 2016, 10:15:35 PM
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?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on June 30, 2016, 12:59:20 PM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 06, 2016, 11:57:36 AM
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
Quote from: LisacPisac
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:
(http://i.imgur.com/EyhGx2S.png)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on July 06, 2016, 09:52:22 PM
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.log
I 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 07, 2016, 09:42:32 AM
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())
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on July 07, 2016, 09:46:25 AM
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')]
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 07, 2016, 12:52:48 PM
Edited out.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on July 07, 2016, 01:08:19 PM
From the current pip code (here (https://github.com/pypa/pip/blob/master/pip/pep425tags.py#L330)) 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 (https://github.com/pypa/pip/issues/1850).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on July 07, 2016, 04:57:17 PM
Updating pip fixed the problem. Thanks!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Bretsky on August 08, 2016, 01:03:07 AM
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!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Quendus on August 08, 2016, 03:16:00 PM
self.on_move_events() is the only function in that code that draws on the terminal, it isn't called until brlb.has_input() returns True. To fix this you should call your screen update function before the first time brlb.refresh() is called.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 08, 2016, 05:34:18 PM
As Quendus has pointed out, it is a matter of instructions order.

You can probably simplify the logic a bit by inverting the process of reading and drawing, i. e. if some function would render current state first, then wait for input and process it:
Code: [Select]
def process_everything():
    self.on_draw()
    brlb.refresh()
    return self.on_input()

while not self.process_everything():
    pass

Note that if you do not have animations, you do not really need to redraw when there is no input. As long as library is waiting internally (e. g. read or delay), it will refresh the screen itself if necessary.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 29, 2016, 05:50:21 PM
A little bird told me on Reddit that BearLib has a Lua wrapper built in.

Is it true? Are there any tutorials on how to use it?

I'm looking to move my Lua game to some other display library (without changing the language) and I'm torn between this and libtcod. Which is easier to set up and get going?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 29, 2016, 06:14:08 PM
I really thought I've already written some instructions already, but cannot find it now =|. Using the library with Lua should be really simple: en:bearlibterminal:using:lua (http://foo.wyrd.name/en:bearlibterminal:using:lua). Essentialy, you just have to place the binary near the main script and load the module with 'require'.

Only I somehow missed Lua 5.3 which has a slightly different binary interface and therefore not compatible with the current BearLibTerminal binaries. I'll fix that shortly.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 30, 2016, 09:11:37 AM
Thanks for the speedy fix.

The documentation is top-notch and I already have figured out how to print tiles and text to screen.

I have a problem with an input loop, however. All the examples are in C and I am still bad at loops :(

Can anyone help?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: LisacPisac on August 30, 2016, 10:16:22 AM
I really thought I've already written some instructions already, but cannot find it now =|. Using the library with Lua should be really simple: en:bearlibterminal:using:lua (http://foo.wyrd.name/en:bearlibterminal:using:lua). Essentialy, you just have to place the binary near the main script and load the module with 'require'.

Only I somehow missed Lua 5.3 which has a slightly different binary interface and therefore not compatible with the current BearLibTerminal binaries. I'll fix that shortly.

If you've added that "using lua" section, maybe you should link it somewhere from the API reference, because it seems to me that, even if the articles exists somewhere, they are unreachable apat from guessing links. Parts of the documentation have been lying dormant for a while now.

@Zireael
make a while loop that takes input from the keyboard. Ala
Code: [Select]
while (key != terminal.TK_Q)
    key = terminal.read()
    if key == terminal.TK_KP_4
        // Something, etc
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 30, 2016, 10:44:54 AM
Quote from: Zireael
I have a problem with an input loop, however. All the examples are in C and I am still bad at loops :( Can anyone help?
I'll help of course. Though there is so many use-cases and so many ways to implement them that I do not think there is some universal example. Better if you share what input logic you're trying to use: simple read and execute, continuous redrawing or something else.

LisacPisac gave one example, though I would have probably wrote it in a do-while way:
Code: (lua) [Select]
repeat
    key = terminal.read()
    if key == terminal.TK_KP_4 then
        -- do smth
    end
until (key == terminal.TK_Q)

Quote from: LisacPisac
If you've added that "using lua" section, maybe you should link it somewhere from the API reference, because it seems to me that, even if the articles exists somewhere, they are unreachable apat from guessing links. Parts of the documentation have been lying dormant for a while now.
It is on of its kind, the first article in the 'using' series and the only unreachable one >_<. I'll make the necessary links.

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 30, 2016, 11:03:23 AM
I was looking at the source code for Omni or whatever the example is, and trying to figure out how you navigate between the screens, and how you move the viewport in the minimap example.
All I see is some sort of while proceed= true do stuff loop followed by terminal.close()
And from what I see, every screen is a separate function, and every one of those has some sort of a input handling function.

Once I have the input working, I could get the game going, but without input all I have is a static screen.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 30, 2016, 01:49:23 PM
Oh damn. Sample program had way more complex input loops than necessary. Try to look at the newly committed ones.

The reason for this is before introducing input filtering read() function was returning all input events: presses, releases, mouse movement. Especially mouse was a problem. The library uses vsync (by default, may be turned off) which is generally a good thing but limits refresh rate to something around 60 fps. With mouse movement it is rather easy to wave mouse around (and register corresponding events) faster than 60 text cells per second. This means that if you read input and redraw the screen after every read, then output will not keep up with input and there will be a noticeable lag. To work around that previous input loops were reading all available/buffered input every 'frame', hence the loop inside the loop.

You can see the same two-loop flow structure is still used in the mouse-specific samples ('mouse' and 'input filtering'). No real way around it, turning vsync off is not a decent solution because that would mean just meaninglessly redrawing/updating the screen.

Another case is animations. For example 'Extended ...' samples produce an animated output so they cannot hang on read() until some input available. They loop continuously, check for input availability via has_input() and call read() only when there is some.

You do not need all that in a simple case. As long as you have neither mouse nor animation, just a simple do-while loop should do. By default read() function returns only key presses so it pretty safe to update after every read.

I might take that even further. One of the possible future features is animated tiles. If those are implemented, even simple animations (like when monsters/torches/etc have a few frames of animation played continuously and synchronously) would not require any fancy input handling.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 30, 2016, 07:28:12 PM
Thanks for that simplifying update, Cfyz!

Mouse support is in the cards, but for now I will focus on getting the basics going. I spent most of today grappling with my Lua libraries and then trying to figure out how to implement classes in Lua - I was so used to them I never realized they aren't there out of the box!

Now that the hurdle is over, I will see how quickly I can implement all of the things I had in T-Engine. I guess it's going to be really quick, since T-Engine is open-source and I have long been hacking it's source (and I don't need to bring EVERYTHING over since I don't need the notion of modules, for instance, or the main menu being a completely separate module).

The only problem I can foresee right now is the ASCII/tiles switch, since it's gonna essentially double on the number of code points I'll need... unless I can

Code: [Select]
if mode = ASCII then
terminal.print([0x5E])
else
terminal.set("0x5E:tile.png")
terminal print([0x5E)

 ???
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 31, 2016, 07:57:53 AM
I seem to be having a tiny problem. I am specifying image paths in my Lua code, so I use the / kind of slash. However BearLib can't find the images because it seems to want a \ slash, which is an escape character in Lua.

I can load the pictures fine if they sit in the main folder, but this will quickly become unmanageable...
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 31, 2016, 10:09:50 AM
The library considers forward slash '/' universal and replace it with backslash '\' on Windows. I. e. forward slashes should work everywhere. Like this (https://bitbucket.org/cfyzium/bearlibterminal/src/0435b883c30adc5eba64364c5abdb779c4103a7e/Samples/Omni/Source/Sprites.cpp?at=default&fileviewer=file-view-default#Sprites.cpp-14).

The problem is probably related to current working directory, with interpreted applications there are more ways to end up with some unusual cwd. To check this, try to supply an absolute path. If absolute paths work, then we'll have to figure out some way to address resources relatively =|. The most reliable way would be to get the full path to the main script file and then derive resource paths from it.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Zireael on August 31, 2016, 10:49:44 AM
Quote
The library considers forward slash '/' universal and replace it with backslash '\' on Windows.

Isn't the case, at least in my Lua code.

I'm using lfs.currentdir() to determine the current directory and printing it to console - it's the correct one.

I'm getting the tile to be used via
 
Code: [Select]
player = Actor.new()
terminal.set("U+E000: "..player.image)


where image is a string stored in the Actor class. Printing it to console to verify I'm getting the correct thing.

This is the entirety of my Actor class so far:
Code: [Select]
lfs = require 'lfs'
local game_dir = lfs.currentdir()
print("Current dir is: "..game_dir)

package.path = game_dir.."/engine/class.lua"
require 'class'

module("Actor", package.seeall, class.make)

function _M:init()
    self.display = "@"
    --self.image = game_dir.."/gfx/player/racial_dolls/human_m.png"
    self.image = "human_m.png"
end

The class and module calls are there to allow me to call things via self:blah() but you could change it to
Code: [Select]
Actor:init() function Actor:init()
If I use game_dir, what I see in the console is:
Code: [Select]
F:\roguelike\test/gfx/player/racial_dolls/human_m.png
And the bt.log says:
Quote
12:46:10.124 [info] Trying to set "U+E000: F:\roguelike\test/gfx/player/racial_dolls/human_m.png"
12:46:10.125 [debug] Group "U+E000":
12:46:10.126 [debug] * "_" = "F:\roguelike\test/gfx/player/racial_dolls/human_m.png"
12:46:10.126 [debug] Requested resource "F:\roguelike\test/gfx/player/racial_dolls/human_m.png" with possible prefix "tileset-"
12:46:10.126 [debug] Loading resource from memory 'F:\roguelike\test/gfx/player/racial_dolls/human_m.png'
12:46:10.127 [error] Failed to set some options: Resource::Open: failed to parse memory address (F:\roguelike\test/gfx/player/racial_dolls/human_m.png)

So as you see, the slashes vary.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 31, 2016, 11:36:29 AM
This is a rather serious mistake on my part. I'll fix it right away, but I won't be able to recompile and upload binaries till the end of the day.
The problem lies with the path being mistaken for an 'addr:size' memory address because of the colon after the drive letter. Meaning, absolute paths on Windows were broken since 0.14.0 =(

[Edit]
Uploaded a new 0.14.7
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on August 31, 2016, 01:00:19 PM
Quote from: Zireael
The only problem I can foresee right now is the ASCII/tiles switch, since it's gonna essentially double on the number of code points I'll need... unless I can
[Personal opinion ahead] I think using tiles is a qualitative change from using purely ASCII output. While the 'A' tile for an ant monster may look like the 'A' letter, they are not the same. Letter tiles should use a normal font optimized for reading, while monster tiles may be from a more fancy font. Map/monsters/etc. tiles generally look better when they are square, while text is much more readable when it is something 1:2 like 8x16. With this I think it is justified to have a separate tile set even for an ASCII theme. And there is no shortage in code points, there is a whole Basic Multilingual Plane (https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane) worth of them in the terminal.

[Edit]
Quote from: Zireael
unless I can
Code: [Select]
terminal.set("0x5E:tile.png")
You can change tiles on individual basis, exactly as you've written. Though it may interfere with regular text as print() will use the same code points and same tiles.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: dividee on September 26, 2016, 08:44:43 PM
If anyone is interested, I ported the Omni samples to Python. I just updated them for 0.14.8. Most of the time, the translation from C++ is quite literal. It runs in both Python 2.7 and 3.5 (and probably others). And also on pypy 5.3, although it's very slow on pypy because of ctypes...

Here is the link: https://github.com/ibatugow/blt_samples (https://github.com/ibatugow/blt_samples)

You should be able to just download or clone the repository and run the samples in the Python directory. You can either run each sample individually or sample_omni.py for the whole thing.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: gyscos on October 12, 2016, 10:11:19 PM
For archlinux users, there is now an easy way to install the library (https://aur.archlinux.org/packages/bearlibterminal-hg/).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: infinity on October 15, 2016, 05:37:35 AM
Great program, but I seem to have trouble printing unicode characters (ex. β) in Python. Could anyone give me an example of how I would get the terminal to print unicode characters as well as ASCII? I am using DejaVu fonts so they support unicode.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on October 15, 2016, 02:10:22 PM
It should work as long as Python does not lose unicode along the way:
Code: [Select]
# -*- coding: utf-8 -*-
from bearlibterminal import terminal
terminal.open()
terminal.set('font: ./DejaVuSansMono.ttf, size=16')
terminal.printf(2, 1, 'β')  # would be u'β' if Python2
terminal.put(2, 2, 'β')
terminal.refresh()
terminal.read()
terminal.close()
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: NoahTheDuke on November 15, 2016, 05:03:56 AM
Hey all, it's been a little while.

I'm trying to build a small roguelike using the Python wrapper, and I can't seem to get key releases to register. Any ideas how I've messed this up?

Code: [Select]
import PyBearLibTerminal as terminal

terminal.open()
terminal.printf(2, 1, 'β')
terminal.put(2, 2, 'β')
terminal.refresh()
while True:
    if terminal.has_input():
        key = terminal.read()
        print(key)
        if key == terminal.TK_Q | terminal.TK_KEY_RELEASED:
            print('released')
            break
        elif key == terminal.TK_Q:
            break
terminal.close()
produces
Code: [Select]
.../Programming/Python/roguelike python3 test.py
4
22
7
44
20
.../Programming/Python/roguelike
Has anyone experienced this before? Have I done something wrong or set something up wrong? I haven't tried this on my Windows machine, but I'll be sad if I can only access key releases on Windows.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on November 15, 2016, 04:06:24 PM
Quote from: NoahTheDuke
I can't seem to get key releases to register.
This is intended. To mimic the most basic terminal input, by default the library reports key presses only. If you need some extra (key releases, mouse), you have to enable that via 'input.filter' option, e. g.
Code: [Select]
terminal.set('input.filter=[keyboard+]')It is documented at reference/input/input.filter (http://foo.wyrd.name/en:bearlibterminal:reference:input#inputfilter).

The "[keyboard+, mouse]" notation feels a bit clunky, but I just can't think up a better one.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: NoahTheDuke on November 16, 2016, 01:59:36 AM
A-ha! Finally, an answer. Thanks for pointing that out; shoulda read the spec closer!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Tilded on November 21, 2016, 04:23:38 AM
Hi, I'm starting a new project using bearlibterminal and python, and its going awesome so far! Thanks for this wonderful library
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on November 28, 2016, 08:09:36 PM
I'm converting a project from libtcod to bearlibterminal because of various features I liked. Everything seems to be going well except for keyboard inputs. It appears as though an extremely large buffer of input commands are being kept when a user holds down a key. Is there a way to avoid this behavior? or to delete the queue on demand?

Ive tried using the non-blocking terminal.has_input() prior to calling terminal.return. But i get the same input lag no matter how I do it.

Code: [Select]
def read_key_int():
    while terminal.has_input():
        return terminal.read()
    return None

Any help would be greatly appreciated.

Thanks!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on November 28, 2016, 10:57:37 PM
Hmm. BearLibTerminal does not do anything out of ordinary here. It accepts input at the same rate it comes from the OS and keeps it until it is read, pretty much just like any other app would. You shouldn't be able to enqueue a significant amount of keystrokes unless the application is particularily lazy with input. Even if you redraw a whole screen every read, it should not be noticeable until you are consistently generate more that 60-80 keypresses per second =).

Do you have a minimal working example illustrating your problem?

The non-blocking read code you posted will not help clearing the queue: it won't read more or faster than a regular read would (but it will exit faster and more frequently). If you want to flush the input, you need a proper cycle:
Code: [Select]
def clear_input():
    while terminal.has_input():
        terminal.read()
Obviously this will lose all those buffered keystrokes.

Most of the time you should not have to clear anything, though. Losing input is not good and it's more robust to shape the control flow so that a sudden bunch of keypresses do not surprise the program that much.

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on November 29, 2016, 02:21:38 PM
That clear function solved my issue. Its not the prettiest solution, but it works for now as there appears to be no noticeable input loss from the user.

It might have something to do with how time/turns are handled in my scheduler func.

Thanks for the quick reply!

Also:
Is there a way to write to the states?

For example if I want to move the mouse cursor to a cell with a line of code.
in libtcod there is:
Code: [Select]
libtcod.mouse_move(x, y)

that moves it to certain pixel coords.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Tzan on November 29, 2016, 06:18:40 PM
When I was doing a tile game in Java, I would get the input and put it in a que.
So multiple clicks might be in the que after a unit is done moving.
But then the next unit would use them, we dont want that.
So I always clear the que at the end of a units turn.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on November 30, 2016, 11:58:40 AM
Quote from: Tzan
But then the next unit would use them, we dont want that. So I always clear the que at the end of a units turn.
Yep, discarding input is okay when you're doing it deliberately. But by that time you already know what is what.
Nuance is, clearing input just to make the whole thing work may indicate a flaw in control flow. Or may not, but my experience says chances are high.
A simple (maybe too simple, but obvious) example would be accidentally doing things in draw-read-refresh order. It displays the scene one frame late and does introduce a visible lag.

Quote from: tapeworm711
Is there a way to write to the states?
No, those states are intended to be, well, just the current state of things. Modifying is done through terminal_set -- or a separate function if the action is frequent and important enough (e. g. terminal_layer).

Setting mouse position is a questionable action. For once, I'd never do that in my own program because as a user I'd really hate for mouse to jump on screen out of my control. I might add the functionality just for completeness sake but it has quite a low priority. Unless you provide a compelling use case =).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Aukustus on November 30, 2016, 01:17:19 PM
I've been fiddling with bitmap fonts in C# and there's a fairly interesting effect when using bitmap font without specifying size. It opens a white full screen sized window and nothing else.

Also, are http://roguecentral.org/doryen/data/libtcod/doc/1.5.1/html2/console_set_custom_font.html?c=false&cpp=true&cs=false&py=false&lua=false TCOD layouted fonts supported?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on November 30, 2016, 09:10:01 PM
The use case was for ranged combat:


User pressed "f" to enter Fire-Mode.
Program figures out closest targetable monster.
Reticle is placed over that monster.
If user presses "f" mode, targets will cycle between those available.
But use can "free-aim" by using the mouse, when user moves mouse reticle and firing line follows mouse in circle.
(NOTE: it felt more natural to move the cursor to the reticle than to have it just follow relatively. This was a minor thing, so I took it out)


NOTE: in the python bindings i'm using: TK_MOUSE_MOVE state is ALWAYS 0. (using check, its always False. Found that odd. all other mouse states appear to be working correctly.

Additionally i'm not sure how to get bearlib to read the "box drawing acsii" from my PNG file instead of the default. Even using your yoshi_island font the boxes draw standard when addressing them via unicode (ex: 0x2502 prints a |, regardless of the glyph in the .PNG)

Enjoy my barrage of ?'s!!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on November 30, 2016, 09:46:09 PM
Quote from: Aukustus
there's a fairly interesting effect when using bitmap font without specifying size. It opens a white full screen sized window and nothing else.
Oh >_<. When the 'size' of bitmap font/tileset is omitted, image is treated as a single sprite. And then library uses this sprite as a character tile and adjust the size of a cell and a window accordingly. Well, tries to. With 256x256 image library will try to resize the window to 80x25 * 256x256 = 20480x6400 pixels which is probably beyond reason and breaks a few things.

Since not specifying a size for a font makes no sense, I'll just make it fail (and roll back) in this case.

Quote from: Aukustus
Also, are TCOD layouted fonts supported?
About two thirds? ASCII_INROW is codepage '437', TCOD is, well, 'tcod' and ASCII_INCOL is just too weird.
Code: [Select]
Terminal.Set("font: consolas12x12_gs_tc.png, size=12x12, codepage=tcod");Nuances are:
1. Most of tcod font images are non-transparent (fully opaque background) and their tiles will not overlay nicely. Might not be a problem. I have an idea how to fix that on-the-fly.
2. I've just noticed that CP437 (https://en.wikipedia.org/wiki/Code_page_437) does actually contain various icons and arrows at 0x01-0x1F in contrast with other ANSI codepages. I'll fix that in the next release.
3. Looks like there is a bug in handling box drawing characters. Working on it.

Technically, BearLibTerminal supports any layout. Instead of a predefined built-in name, you can specify a filename in the 'codepage' parameter:
Code: [Select]
Terminal.Set("font: image.png, size=16x16, codepage=my_codepage.txt");With file containing a list of Unicode codepoints for each tile consecutively, left-to-right, top-to-bottom:
Code: [Select]
U+0020-U+003F, U+0040, U+005B-U+0060, U+007B-U+007E, U+2591-U+2593,
U+2502, U+2500, U+253C, U+2524, U+2534, U+251C, U+252C, U+2514, U+250C, U+2510, U+2518,
...

Quote from: tapeworm711
The use case was for ranged combat: <...>
Why do you need to move the mouse though? Not sure I understood your note, but placing/cycling the reticle over the targets via keyboard and then moving it under the mouse on the mouse movement looks more natural. Mouse does not move when you use keyboard to navigate the text in an editor or file icons in an explorer, yet you can always 'override' the cursor (selection) position by moving/clicking the mouse.

Quote from: tapeworm711
NOTE: in the python bindings i'm using: TK_MOUSE_MOVE state is ALWAYS 0.
TK_MOUSE_MOVE is an event, not a state (and listed so in the docs, so my conscience is clear here =)), so it will be read zero as any other invalid state code. There are no separate lists of constants because almost every other event is also a state.

Quote from: tapeworm711
Additionally i'm not sure how to get bearlib to read the "box drawing acsii" from my PNG file instead of the default. Even using your yoshi_island font the boxes draw standard when addressing them via unicode (ex: 0x2502 prints a |, regardless of the glyph in the .PNG)
Yup, that's looks like a bug. Bitmap fonts should override box drawing characters. Will look into it shortly. Not sure what yoshi_island is, though =/.

-----
Edit: well, most of issues are minor code-wise, expect an update in about a day.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on December 01, 2016, 04:07:37 PM
More mouse questions:

I'm having trouble with differentiating between mouse clicks.

Example:
1) User presses key to open a Pop-Up window with a 'close' button.
2) User clicks on 'close' button with mouse.
3) Game closes Pop-Up, but also attempts to Pathfind to X, Y location (also activated by clicking)

Since I don't see a "TK_MOUSE_LEFT_UP" or "TK_MOUSE_LEFT_RELEASED". I tried using TK_MOUSE_CLICKS but that still shows 'True' while its being held. which is being seen by my other event handlers.

In addition to this issue it appears there is no state difference between HOLDING down a button and CLICKING IT rapidly (well you would get an occasional False from MOUSE_LEFT, but not sure if thats useful in this case).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 01, 2016, 04:47:43 PM
Quote from: tapeworm711
I'm having trouble with differentiating between mouse clicks. Example: <...>
Erm, are you using terminal_read or terminal_state? Runtime state is not the right tool for this task. There should not be any problems with basic mouse handling when reading its events. The first TK_MOUSE_LEFT closes popup and the next TK_MOUSE_LEFT (which would trigger pathfinding) won't come until another actual mouse click.

To use mouse (read any mouse-related events from terminal_read) you need to explicitly enable it by setting input.filter option, see docs (http://foo.wyrd.name/en:bearlibterminal:reference:input#inputfilter).
Also, take a look at "Input 2: mouse" in SampleOmni (event counter, states and behavior) and it's source code (https://bitbucket.org/cfyzium/bearlibterminal/src/b115a1b3875d09139475cfb325c132cefef5a838/Samples/Omni/Source/Mouse.cpp?at=default&fileviewer=file-view-default).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on December 01, 2016, 06:38:06 PM
Figured it out.

I had two different functions polling for inputs. So each mouse event was registering in each one. Fixed that and VOILA!.

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 01, 2016, 10:22:45 PM
Okay, here is an update: 0.14.12 (Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.14.12.zip) / Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.14.12.tar.bz2) / OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.14.12_osx.zip) / PyPi (https://pypi.python.org/pypi/bearlibterminal))

* First ~32 symbols of CP437 (xxx_ro.png from tcod are this) are properly mapped onto the Unicode now (kind of missed that before).
* Grayscale fonts (.png w/o transparency) are properly supported.
* Box Drawing elements from bitmap fonts are not overrided by auto-generated tiles anymore.
This also means libtcod fonts (except ASCII_INCOL layout) are fully useable now.

* The library will not accept a font tileset without a 'size' parameter.
It's now a bit harder to break things accidentally.

* C# wrapper: added some Point/Rectangle function overloads.
* C# wrapper: Set() and Get() support formatting and parsing System.Drawing.Size type (I mean, in library-recognizable format):
Code: [Select]
Size custom_size = Terminal.Get<Size>("ini.settings.custom-size", new Size(80, 25));
Terminal.Set("window.size={0}", custom_size);

* Python wrapper: added atexit cleanup handler that closes the library if Python exits due to exception.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Aukustus on December 02, 2016, 08:45:41 PM
Is it possible to have a single font (ttf or bitmap) but print chars from it different sizes? I've been planning an ascii system that has double sized chars in the game screen but regular in the text.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 03, 2016, 12:33:09 AM
It is possible. But technically it is not the same font with different sizes, they are different tilesets loaded from the same source with different parameters. Which may be done in a few ways.

Let me provide an example of various font configurations:
(http://i.imgur.com/oexp1Wf.png)

There are two groups, blue is UbuntuMono-R.ttf, green is terminal10x18_gs_ro.png.
1. First line is the basic font loaded with a bare minimum of options.
2. Second line is the same font but spaced to make it fit [almost] square map cells. The 'spacing' parameter controls how a character is centered relative to its origin cell and how much cells Print() function should advance.
3. Third line illustrates what will happen if characters are resized to some arbitrary size irrelevant to the base cell size.
4. Fourth line is pretty much the same as the second one.
For truetype tilesets 'size' directly specifies the target size. For bitmap tilesets 'size' is a size of a tile in source image and target size is overriden by 'resize' parameter. Spacing is the same for both.

You may have several different fonts at once. In the example above there are eight different fonts loaded like this:
Code: [Select]
Terminal.Set("twice font: UbuntuMono-R.ttf, size=20x36, spacing=4x2");Such extra fonts are used like this:
Code: [Select]
Terminal.Print(2, 1, "[font=twice]Abc 123");But there is a limitation: you cannot address individual tiles from extra font with Put() since it does not have a font name argument. You have to use Print() with 'font' formatting tag.

Instead of loading alternative character configurations as fonts you can also load them as generic tilesets:
Code: [Select]
Terminal.Set("0xE000: terminal10x18_gs_ro.png, size=10x18, resize=20x36, resize-filter=nearest, spacing=4x2");This will place twice-size character tiles into codepoints 0xE000..0xE0FF. You won't be able to Print() with them since those are not character codes anymore but you'll be able to Put() them:
Code: [Select]
Terminal.Put(2, 1, 0xE040); // @But there is a gotcha, 'codepage' has a very different meaning when loading tilesets vs. loading fonts. Most of the time you do not need one though because usually you want a whole tileset loaded straight consecutively.

I probably need to write a nice long article about how all of this works. The system is flexible enough to become confusing.

P. S. And I've immediately found a new thing to fix. When a truetype font is loaded with size that is not the same aspect ratio as the base cell size (e. g. 18x18 vs 10x18), its characters are not aligned correctly within tiles. Aargh!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on December 25, 2016, 11:27:53 PM
Would anyone be interested in D bindings?  I'm learning D right now, and had been going to write an RL in it with bearlib.  If anyone wanted, I could probably formalize it all into a library.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on December 25, 2016, 11:45:55 PM
It seems that bearlibterm leaks memory?  Just running the example C program, valgrind reports:

definitely lost: 520 bytes in 2 blocks
indirectly lost: 1,661 bytes in 14 blocks

Full valgrind log: http://lpaste.net/350473 (http://lpaste.net/350473)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 26, 2016, 10:43:55 AM
Quote from: Elrond
It seems that bearlibterm leaks memory?
Oh, thanks for pointing that out. There is also a small leak in TrueType tileset. Overall it is just a few bytes once a process, so I will not re-upload right away and incorporate the fixes into the next update.

Incidentally, how do you name a size structure (usual width, height) using lowercase when the 'size_t' name is underhandedly taken by the standard library?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on December 26, 2016, 09:11:57 PM
Some unicode doesn't seem to be supported.  The ╱ character, for example, which is supported by the font I'm using (I've verified this with SDL-TTF) just shows up as a black box in bearlibterminal.  Any fix?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on December 26, 2016, 10:28:30 PM
Actually, no symbol out of Box Drawing (0x2500-0x257F) (https://en.wikipedia.org/wiki/Box_Drawing) range is being taken from any TrueType font, these characters are automatically generated by the library. This is how it happened:

* Most TrueType fonts provide only a small subset of Box Drawing character range. Using half native, half auto-generated produces a shabby image.
* Those characters that actually provided are often do not align well even within the font itself.
* Even if the font is good, it is hard to align there characters when rasterized which produce unseemly patterns of various visibility (e. g. a pixel missing every tile in a wall).
* More so if the cell size is not native to the font, e. g. manually set to be 10x20 for design purposes when the font is more like 10x18.5 at that specific size.

So in the end I just went with auto generating these instead of using ones from the font. Also, same goes for Block Elements (0x2580-0x259F) (https://en.wikipedia.org/wiki/Block_Elements) range. Note that bitmap fonts is a very different case and theirs version of characters are used normally.

But seven characters (0x256D-0x2573, and ╱ is there) turned out to be not so easy to generate nicely and ended up as no-characters to this day.

Looking at this again, I probably should just allow the user to use font's characters if he wants to, e. g. by an additional 'use-box-drawing=true' font parameter. I'll include that into the next update. And I need to support those seven characters, but this is not as easy.

Meanwhile there is a rather ugly hack to still use these font's characters right now by loading a subset of a font to some other unused code points, e. g. 0xE000-0xE07F, so that 0x2571 (╱) would be availables as 0xE071. Tell me if you really want to see this =/.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on January 03, 2017, 02:25:34 PM
When terminal.read_str() accepting input from the keyboard, is there a way to allow the use of the NUMPAD numbers? Cannot seem to enable this.

Thanks, as always.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Serin Delaunay on January 08, 2017, 04:13:08 AM
Thanks for continuing to develop this library :)

More than once when working with bearlibterminal I've needed to implement maps that scroll smoothly. The included demo application also has a smooth-scrolling sample. The problem with implementing this in BLT is that when the display is offset by a fraction of a tile, there are more tiles to be drawn than there are slots in the terminal. There are two ways around this:
Both methods "work" and don't seem to have any performance implications, but from the perspective of code readability I would prefer to be able to put each tile in its own slot. That's not currently possible because characters can only be put inside the terminal's boundaries.

Would it be possible to extend the terminal storage, writing, and drawing outside the bounds imposed by TK_WIDTH and TK_HEIGHT? Just one row and one column would be enough for this purpose, but another option would be to have a configurable number of extra rows and columns on each side. This could be helpful when drawing 2.5D terrain where tiles could be N rows off the bottom of the terminal but still be high enough that they should appear on the display.

Here's a discrete dimetric heightmap drawn with BLT. It probably would have been easier with a configurable number of extra rows on the top and bottom.
(http://i.imgur.com/aBbXAZ8.png)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 09, 2017, 12:32:24 AM
Update time: 0.15.0 (Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0.zip) / Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0.tar.bz2) / OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0_osx.zip) / PyPi (https://pypi.python.org/pypi/bearlibterminal))

The main (but still minor) version bump comes from a slight change in printing function. Not sure what had I been under while first implementing that, but until now text wrapping/aligning was done via in-text formatting tags:
Code: [Select]
terminal_printf(2, 1, "[bbox=%dx%d][align=center]%s", w, h, str);To make things even messier, print() was returning either width or height of a string depending on the presence of bbox. While there is some logic, the overall it is just... ugh.

Now print() (or a variant of it if no overloading available for the language) accepts width, height and alignment parameters explicitly and always returns both dimensions:
Code: [Select]
y += terminal_print_ext(x, y, width, 0, TK_ALIGN_DEFAULT, message).height;And same goes for measure().

By the way, it was quite a quest to update all seven (sic!) wrappers for various languages. I've initially tried a naive approach with simply returning a struct, but quickly discovered that doesn't work across multiple languages -- apparently there is no standard to how cdecl handles return values larger than a scalar.

Another change I need to illustrate is 'dead-center' alignment mode for tiles. It essentially ignores any typographic values for the tileset:
(http://i.imgur.com/sPMKB57.png)
This might be useful for map/level elements since that will align the good old ASCII in the map cells rather neatly.

Other than that, changes include:
* New 'use-box-drawing=true' and 'use-block-elements=true' truetype font parameters to force the library to use in-font glyphs if you really want. It still will auto-generate the missing ones.
* Keypad keys update TK_CHAR/WCHAR states now so they can be used for text input (e. g. read_str() function).
* Querying library version via terminal_get("version"), it will return a string like "0.15.0".
* A few fixes here and there.

Also, I've changed the Python wrapper structure a tiny bit. Instead of a lone .py file there is a Python package/module skeleton now. See the README.md (https://bitbucket.org/cfyzium/bearlibterminal/src/8dcc701a7d28853dab965c9f38a4cdc3aed9b978/Terminal/Include/Python/README.md?at=default&fileviewer=file-view-default) in the corresponding directory for some notes about it. Having a 'bearlibterminal' module directory instead of a single PyBearLibTerminal.py in the project allows easier switching between an installed package and a local copy (import statement is identical, no changes to source needed).

Quote from: tapeworm711
When terminal.read_str() accepting input from the keyboard, is there a way to allow the use of the NUMPAD numbers? Cannot seem to enable this.
That should be fixed in this update, see above.

Quote from: Serin Delaunay
Would it be possible to extend the terminal storage, writing, and drawing outside the bounds imposed by TK_WIDTH and TK_HEIGHT?
Well, I'll probably implement that one way or another. This would help tiles which are bigger than a cell like square map tiles, it is currently hard to place them above or to the left of the viewport even if you do not need any pixel offsets.

That said, personally I do not think that putting tiles into (0, 0) makes things messier. It could be easily wrapped into something like
Code: [Select]
def put_freely(x, y, dx, dy, c):
    terminal.put(0, 0, x*cell_width + dx, y*cell_height + dy, c)
to make intent clear in the source code.

The most messy part is that offsets themselves are a hack to the pseudo-terminal ideology. It is fine for a tile or two but for the whole scene there is almost no support, you have to recalculate and readd every tile. It would be nice to have scrolling viewport and cells with different geometry but devising a sane API for that seems close to impossible.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KM on January 09, 2017, 11:21:48 PM
Hi; perhaps this is the wrong place for this, but..

I'm done the roguelike tutorial, and I've ported it all into the bearlibterminal for the graphical aspect.  I am simply wondering how to make my window resizeable?

I read the documentation, but it's not working and I don't know why.  Example code plz?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 10, 2017, 12:35:33 AM
Quote from: KM
I am simply wondering how to make my window resizeable?
Resizing a window may mean a few things.

1. Resizing a window so that there will be more (or less) cells available: you need to set 'window.resizeable' option and then handle TK_RESIZED input event from read(), e. g. assuming Python:
Code: [Select]
terminal.set('window.resizeable=true')
...
while True:
    key = terminal.read()
    if key == terminal.TK_RESIZED:
        new_columns = terminal.state(terminal.TK_WIDTH)
        new_rows = terminal.state(terminal.TK_HEIGHT)
        ...
    elif key == terminal.TK_CLOSE:
        break
    ...
TK_RESIZED is just a notification, though. The scene is already a new size by the time it was read.

2. User scaling the window (and its contents): it is done in some discrete steps by pressing Alt+Plus/Minus. There is no arbitrary scaling like in Caves of Qud, yet.

3. Program scaling the window (and its contents): there is no direct way for this, yet. You can achieve this by setting/resizing a different font size.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: quejebo on January 10, 2017, 05:31:22 AM
Hi, I've been checking out bearlibterminal, and I seem to be having trouble with ttf rendering.  Check the attached image, and note the exclamation mark on the left.  Is there something I might be doing wrong?

Thanks!

(http://i.imgur.com/WCexwE2.png)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KM on January 11, 2017, 01:07:08 AM
Thanks a lot, Cfyz!

So I have it working as per your first example with variable cell sizes; however the whole screen goes black while it's being resized, and only upon movement does it render the screen again.  Is this normal?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 11, 2017, 09:44:32 PM
Quote from: quejebo
I seem to be having trouble with ttf rendering.  Check the attached image, and note the exclamation mark on the left.  Is there something I might be doing wrong?
Looks like auto-hinter in freetype library produces subpar results for some fonts. I'll look into it and probably release a fix shortly.

Quote from: KM
however the whole screen goes black while it's being resized, and only upon movement does it render the screen again.  Is this normal?
Does it go black while resizing or after you release the mouse button and until some other input? The latter is normal since scene contents are cleared when it is resized, you need to recalculate the layout and redraw the scene for a new size.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on January 12, 2017, 09:06:52 PM
Found an odd issue with   [wrap] / [align] tags.

If you install BearLibTerminal via pip. The tags do NOT function properly. As in they do not no aligning or wrapping at all.

BUT

If you use PyBearLibTerminal and BearLibTerminal.dll from the "blt-samples" master, they work just fine.

Is there an issue with the PIP package? or am I doing something wrong?

P.S. Really close to finishing a python class called "bltColor" that brings all the libtcod color functions to blt and more! (testing this is how I discovered the wrap issue)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 12, 2017, 10:01:29 PM
Quote from: tapeworm711
If you install BearLibTerminal via pip. The tags do NOT function properly. As in they do not no aligning or wrapping at all.
As I mentioned a few posts above, in the latest update 'wrap' and 'align' tags were removed in favor of proper function arguments. E. g.
Code: [Select]
terminal.print(2, 1, some_str, width=10, height=5, align=terminal.TK_ALIGN_RIGHT);
This actually shuffled things a bit for python print function =|. Originally there was printf because you can't use print identifier in Python 2 and print_ looks weird. So I went with printf as a workaround and obviously had to make it support formatting to match the name. But when I tried to add optional keyword arguments for area and alignment, it did not work with formatting part. Turns out, you can't have a signature like
Code: [Select]
def printf(x, y, s, *args, width=0, height=0, alignment=0):Only **kwargs may come after *args. And making optional arguments nameless hurts the usability.

Since formatting was never an objective (unlike C++, Python has good string formatting out of the box), I changed string output function name to puts. Like put for putting characters/tiles and puts for putting stirngs, with print_ and print (in Python3) aliases. The printf was left for some compatibility (I would mark it as deprecated if I knew how) but for reasons stated above it does not have wrapping and alignment support anymore.

Quote from: tapeworm711
BUT If you use PyBearLibTerminal and BearLibTerminal.dll from the "blt-samples" master, they work just fine.
That's because it is a separate repository and probably has a previous library version. Should do something about it.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on January 12, 2017, 10:17:37 PM
Not sure how I missed that. Thanks.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KM on January 16, 2017, 07:10:42 PM
Quote from: KM
however the whole screen goes black while it's being resized, and only upon movement does it render the screen again.  Is this normal?
Does it go black while resizing or after you release the mouse button and until some other input? The latter is normal since scene contents are cleared when it is resized, you need to recalculate the layout and redraw the scene for a new size.
[/quote]

Before another input is entered.  Would I be able to make it recalculate and redraw the layout based on releasing the mouse button or somesuch?

Is there a general command to redraw the screen, as I'm also having the same issues after exiting any other screen such as inventory, character class, and etc, that only the objects and items are drawn before I move, not the background tiles at all.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KittyTristy on January 18, 2017, 11:34:04 AM
I've been using BearLibTerminal and I love it (I've extensively used libtcod in the past and BLT is just so much simpler).

Well, I was wondering Cfyz.. do you plan to add support for animated tiles?  I have a game I'm working on with drawn tiles and I'd really love to have them be animated.  I couldn't see any way to do this currently, so do point out if I'm wrong here. :)

Anyways, thanks for the awesome library!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 18, 2017, 02:37:03 PM
Another small update: 0.15.1 (Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.1.zip) / Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.1.tar.bz2) / OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.1_osx.zip) / PyPi (https://pypi.python.org/pypi/bearlibterminal))
* TrueType fonts/tilesets use font's native hinting now instead of TrueType's automatic. It is also possible now to choose the hinter manually via 'hinting' tileset attribute.
* Python wrapper searches both module directory and application directory for library binary.

Quote from: quejebo
I seem to be having trouble with ttf rendering.  Check the attached image, and note the exclamation mark on the left.  Is there something I might be doing wrong?
That's what hinting changes are about, should be working correctly now.

Quote from: KM
Before another input is entered.  Would I be able to make it recalculate and redraw the layout based on releasing the mouse button or somesuch?
Is there a general command to redraw the screen, as I'm also having the same issues after exiting any other screen such as inventory, character class, and etc, that only the objects and items are drawn before I move, not the background tiles at all.
This looks like it heavily depends on your code logic. It is hard to say what and when you should call without looking at the code.

The only command to redraw the screen is terminal_refresh() but the problem is after resizing dimensions are different and library cannot just redraw by itself anymore since it has no idea about your application's layout. Once you've received TK_RESIZED, you need to recalculate new positions and sizes of map, objects, UI, etc. accounting for the new viewport size. This may be done in various ways depending on the input and rendering logic. Some applications calculate and redraw everything every frame and then it's enough to make it run a one more cycle. Some applications separate scene in layers/modal dialogs and then you need a method to invalidate and reconstruct everything at any given time. Not every logic incorporates scene resize easily. Usually it is best to design the loops and logic with resizing in mind right from the start.

Quote from: KittyTristy
Well, I was wondering Cfyz.. do you plan to add support for animated tiles?  I have a game I'm working on with drawn tiles and I'd really love to have them be animated.  I couldn't see any way to do this currently, so do point out if I'm wrong here. :)
Yep, there is no support for that right now. If you need animations you have to loop and redraw manually =/.

I've thought (still thinking?) about animated tiles and the biggest obstacle is that library does not know anything about the objects in a scene. It might be okay for something nailed to a screen but if you try to move/scroll things, the mapping is lost. The animation is either twitching (if cell changes restart it) or continuing in the wrong place (if some cells move simultaneously and the new content is indistinguishable from the previous one at the same coordinates). The only one that looked fine in my mockups is a very simple several-frames simultaneous animation like in DawnLike (http://opengameart.org/sites/default/files/Mine.gif) tileset.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KittyTristy on January 18, 2017, 10:22:21 PM
Quote from: KittyTristy
Well, I was wondering Cfyz.. do you plan to add support for animated tiles?  I have a game I'm working on with drawn tiles and I'd really love to have them be animated.  I couldn't see any way to do this currently, so do point out if I'm wrong here. :)
Yep, there is no support for that right now. If you need animations you have to loop and redraw manually =/.

I've thought (still thinking?) about animated tiles and the biggest obstacle is that library does not know anything about the objects in a scene. It might be okay for something nailed to a screen but if you try to move/scroll things, the mapping is lost. The animation is either twitching (if cell changes restart it) or continuing in the wrong place (if some cells move simultaneously and the new content is indistinguishable from the previous one at the same coordinates). The only one that looked fine in my mockups is a very simple several-frames simultaneous animation like in DawnLike (http://opengameart.org/sites/default/files/Mine.gif) tileset.

Thanks for your response!

After reading your reply, much to my own surprise I managed to get animation working with a very minor change to my code.  Basically in the code each object in a scene keeps track of the character that represents itself.  For some of my objects, this is now a list with multiple characters, and in the draw code, if it sees that it's a list instead of a single character, it chooses a random entry in that list and uses that to draw with on the current redraw call.  It allows for only simple two or three frame animation (something like Ultima 5 for example) but that's precisely what I was going for!

I'm going to need to make some tweaks for animations that need to be consistent (such as water tiles) but I definitely wasn't expecting to be able to get animations working so soon, so I'm quite pleased.

Thanks again for your reply because it inspired me to poke at my code and get animation working. :)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: tapeworm711 on January 19, 2017, 02:29:08 PM
https://github.com/joekane/bltColor (https://github.com/joekane/bltColor)
(http://bit.ly/2iWtsYE)

bltColor

A color Class for BearLibTerminal that adds libtcod-like color functions.

Features:

This class is fully compatible with any function that BLT wants a color parameter, including [color] formatting tags.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: quejebo on January 20, 2017, 06:06:10 AM
Quote from: Cfyz
Quote from: quejebo
I seem to be having trouble with ttf rendering.  Check the attached image, and note the exclamation mark on the left.  Is there something I might be doing wrong?
That's what hinting changes are about, should be working correctly now.

Yeah, looks better now.  Thanks!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KM on January 22, 2017, 09:33:17 PM
So I downloaded the new bearlibterminal after seeing your comment in my thread, and now when I import it, I'm getting strange errors. 
Now when I try to run my program I get;

Code: [Select]
Traceback (most recent call last):
  File "gritandsteel.py", line 6, in <module>
    import PyBearLibTerminal as bear
  File "C:\Python27\Grit\PyBearLibTerminal.py", line 70, in <module>
    _wprint = _library.terminal_print16
  File "C:\Python27\lib\ctypes\__init__.py", line 375, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python27\lib\ctypes\__init__.py", line 380, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'terminal_print16' not found

I have no idea what this means, or why your code looks like this.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 22, 2017, 11:14:53 PM
Quote from: KM
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 (https://bitbucket.org/cfyzium/bearlibterminal/src/7c6713fee9a875c8cac232e80516ac338d716862/Terminal/Include/Python/?at=default)), 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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: KM on January 28, 2017, 10:24:01 PM
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. 
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Saafris on January 31, 2017, 03:19:49 PM
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on January 31, 2017, 05:35:04 PM
Quote from: 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" (https://bitbucket.org/cfyzium/bearlibterminal/src/7c6713fee9a875c8cac232e80516ac338d716862/Samples/Omni/Source/ExtendedBasics.cpp?at=default&fileviewer=file-view-default) (lines 42-49) entry in SampleOmni, those circling characters are flying around one spot.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Avagart on February 01, 2017, 11:40:50 AM
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 :)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on February 14, 2017, 01:58:49 AM
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?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on February 14, 2017, 03:47:48 AM
I made a set of D bindings!  Now guaranteed not to segfault: http://code.dlang.org/packages/bearlibterminal (http://code.dlang.org/packages/bearlibterminal)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 14, 2017, 12:23:42 PM
Quote from: Elronnd
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 =).

Quote from: 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!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on February 14, 2017, 04:36:11 PM
Quote from: 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!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Junkyardfreak on February 16, 2017, 03:56:02 PM
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!
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 16, 2017, 10:37:53 PM
The 'official' python binding (https://pypi.python.org/pypi/bearlibterminal) follows the library API (http://foo.wyrd.name/en:bearlibterminal:reference) 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
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Saafris on February 20, 2017, 07:56:59 PM
Quote from: 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" (https://bitbucket.org/cfyzium/bearlibterminal/src/7c6713fee9a875c8cac232e80516ac338d716862/Samples/Omni/Source/ExtendedBasics.cpp?at=default&fileviewer=file-view-default) (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)?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 21, 2017, 11:44:49 AM
Quote from: Saafris
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 (https://bitbucket.org/cfyzium/bearlibterminal/src/f1e876f8824cc67b3fbce57986a3ec9722f77e3f/Terminal/Source/Terminal.cpp?at=default&fileviewer=file-view-default#Terminal.cpp-2394) 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.

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Saafris on February 21, 2017, 03:29:06 PM
...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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 21, 2017, 04:45:46 PM
Quote from: Saafris
It sounds like interacting with BearLib's layers would be more difficult and involved?
A bit. The Terminal.cpp, line 2054 (https://bitbucket.org/cfyzium/bearlibterminal/src/f1e876f8824cc67b3fbce57986a3ec9722f77e3f/Terminal/Source/Terminal.cpp?at=default&fileviewer=file-view-default#Terminal.cpp-2054) is where layers are drawn and same file, around line 2102 (https://bitbucket.org/cfyzium/bearlibterminal/src/f1e876f8824cc67b3fbce57986a3ec9722f77e3f/Terminal/Source/Terminal.cpp?at=default&fileviewer=file-view-default#Terminal.cpp-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.

Quote from: Saafris
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.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 21, 2017, 05:42:38 PM
Quote from: Saafris
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.
While I've mentioned OpenGL 1.2 above, the real cutoff point is OpenGL 3.1 which drops fixed pipeline support (https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline) (means it need a separate rendering code). Most of the time you'll get at least OpenGL 1.4 context with a lot of relevant extensions (e. g. shaders) available, usually 2.x or even 3.0. You can use something like GLEW (http://glew.sourceforge.net/basic.html) to manage available extensions. Your code just have to be ready for features not being there, like any other graphics application.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Junkyardfreak on February 22, 2017, 05:00:30 PM
So, this function doesn't seems to work in bearlib, I can't move the '@' this way. Any tips?

Code: [Select]
def addchar():
char = '@'
x,y = 0,0
terminal.refresh()
terminal.put(x, y, char)
keymove = terminal.read()
if keymove == terminal.TK_UP:
x -= 1
elif keymove == terminal.TK_DOWN:
x += 1
elif keymove == terminal.TK_LEFT:
y -= 1
elif keymove == terminal.TK_RIGHT:
y += 1


return;
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 24, 2017, 01:37:37 AM
Quote from: Junkyardfreak
So, this function doesn't seems to work in bearlib, I can't move the '@' this way. Any tips?
Is it supposed to move the '@' according to arrow keys every time it is called?
1. The 'x' and 'y' are re-assigned to (0, 0) every time. The '@' will always be in the same place. Move those variables out of the function and do not forget to use global statement (http://stackoverflow.com/questions/13881395/in-python-what-is-a-global-statement).
2. Output is done before input, so even if 'x' and 'y' are correctly global, output would still be one step late. Read and update first, then draw and refresh. Since input won't work without a window on screen (my guess at why refresh got before read), you may need to call refresh once during initialization (before starting updating/moving anything) just to bring the window on screen.
3. X axis is usually horizontal, Y is vertical. The keys and variables are mixed up.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Junkyardfreak on February 24, 2017, 02:29:31 AM
Dangit, I'm so bad at this haha  :-\ And all I want is a simple roguelike base so I can work around it...
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Junkyardfreak on February 26, 2017, 01:16:46 AM
If someone could hand me their roguelike code I would be happy! (Using only bearlib)
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Rakaneth on February 28, 2017, 03:49:29 PM
Two questions:

1) When using a codepage to map Unicode code points, is it possible to skip rows?

I have the Dawnlike tileset, and it has a ton of images I won't use, so I would like to map small codepages to the 0xE000-0xF8FF Unicode space tightly. For example, the GUI tileset has things like hearts in the first few rows that I won't be using in my game, but I like the GUI windows. I only need the nine tiles that make up the borders, edges, and fill.

2) I'm unsure of how to use differently sized fonts. Each letter takes up a whole tile regardless, and I'd like for my UI text to look more natural and be smaller than the 20x20 image tiles I am using. I looked at the source of the OmniSample, but that did not seem to have the desired effect for me.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on February 28, 2017, 05:06:08 PM
Quote from: Rakaneth
When using a codepage to map Unicode code points, is it possible to skip rows?
It should have been possible, but damn. At least it will not be hard to fix.

Quote from: Rakaneth
Each letter takes up a whole tile regardless, and I'd like for my UI text to look more natural and be smaller than the 20x20 image tiles I am using.
Isn't DawnLike 16x16? Well, you can't have truly arbitrary font sizes. Since we are talking about pseudoterminal output, everything should be aligned to cells. How would you address those tiles otherwise? Therefore characters should be 1x1, 1x2, 2x2, etc. cells in size. Indeed, this limits the range of fonts that may be used simultaneously.

There is a hacky workaround: it is possible to force cell size (window.cellsize) to some common denominator, e. g. 4x4, and use a bit more fine-grained font sizes, e. g. 8x16 (2x4 cells), 12x24 (3x6 cells), etc. Or the other way around, adjust cell size to the font for easier text output and place image tiles by their pixel coordinates like this (https://bitbucket.org/cfyzium/bearlibterminal/src/f1e876f8824cc67b3fbce57986a3ec9722f77e3f/Samples/Omni/Source/ExtendedSmoothScroll.cpp?at=default&fileviewer=file-view-default#ExtendedSmoothScroll.cpp-72).
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Rakaneth on February 28, 2017, 06:55:44 PM
Dawnlike is 16x16 that I resize to 20x20 in the config options because my vision is poor.

Also, I think the cellsize trick might work for my purposes. I'll experiment with this - thanks.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on March 05, 2017, 10:02:50 PM
Is there a way to make blt interpret keyups as their own events?  The C header suggests that this is already the case by default, that when you press 'a', you get two events: 'a' and 'a'|TK_KEY_RELEASED:


/*
 * If key was released instead of pressed, it's code will be OR'ed with TK_KEY_RELEASED:
 * a) pressed 'A': 0x04
 * b) released 'A': 0x04|VK_KEY_RELEASED = 0x104
 */
#define TK_KEY_RELEASED     0x100


However, pressing and releasing 'a' seems to just be one event, and I can't find anything about it on the configuration page.  I ask specifically because I'm writing key-reading code, and basically I want to get the keypress into a struct like struct KeyPress { bool ctrl, alt; char ch; }.  Here's my current code http://vpaste.net/U2ZeG (http://vpaste.net/U2ZeG), but it doesn't work well, obviously.  I think I need to read keyup and keydown events separately, unless there's a better way.  How do?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 05, 2017, 10:25:32 PM
Whoa, the 'input.filter' option is was completely missing from the table at the configuration page >_<. The relevant option is mentioned on the separate page: reference:input#input.filter (http://foo.wyrd.name/en:bearlibterminal:reference:input#inputfilter). Essentially, you need to add a plus sign to the list of events to enable their key-releases, e. g. input.filter='keyboard+'. The overall rationale is to behave similar to 'getch()' by default.

Honestly, the notation is quite meh. I would be glad if anyone came up with a better one.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Serin Delaunay on March 07, 2017, 02:22:27 AM
Update time: 0.15.0 (Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0.zip) / Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0.tar.bz2) / OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.0_osx.zip) / PyPi (https://pypi.python.org/pypi/bearlibterminal))

The main (but still minor) version bump comes from a slight change in printing function. Not sure what had I been under while first implementing that, but until now text wrapping/aligning was done via in-text formatting tags:
Code: [Select]
terminal_printf(2, 1, "[bbox=%dx%d][align=center]%s", w, h, str);To make things even messier, print() was returning either width or height of a string depending on the presence of bbox. While there is some logic, the overall it is just... ugh.

Now print() (or a variant of it if no overloading available for the language) accepts width, height and alignment parameters explicitly and always returns both dimensions:
Code: [Select]
y += terminal_print_ext(x, y, width, 0, TK_ALIGN_DEFAULT, message).height;And same goes for measure().
Could you update http://foo.wyrd.name/en:bearlibterminal:reference#print with the new print() signature? It still talks about the "[bbox=*]" syntax, without giving any examples, so it's quite misleading.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on March 13, 2017, 06:35:28 AM
I'm experiencing a couple of problems.  First is that setting terminal_set("window.fullscreen = true"); doesn't do anything.  The second is that although if you set the window to be resizeable, you can resize it, if you try to get the terminal size you just get the original size.  Any workaround?  Are these known problems?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 13, 2017, 10:01:25 AM
Quote from: Elronnd
setting terminal_set("window.fullscreen = true"); doesn't do anything. <...> you can resize it, if you try to get the terminal size you just get the original size
Besides fullscreen not being implemented for macOS yet (>_<), everything else seems to work fine. I've checked setting fullscreen in Ubuntu and Windows, and you can also check resize yourself by running second-to-last entry in SampleOmni which illustrates reading new dimensions after a resize.

If the problem persists, please share the environment info, code snipped being used and a log file with 'log.level=trace'.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on March 13, 2017, 05:35:52 PM
Setting log.level = trace still didn't produce any output.  I'm on linux, btw.  Here's my snippet:


#include "Include/C/BearLibTerminal.h"

int main(void) {
        terminal_open();
        terminal_set("window.fullscreen = true");
        terminal_set("log.level = trace");
        terminal_refresh();
        terminal_read();
        terminal_close();
}


Here's my env:


FVWM_DATADIR=/usr/share/fvwm
_=/usr/bin/env
LANG=en_US.UTF-8
DISPLAY=:0
OLDPWD=/home/elronnd
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=1
HG=/usr/bin/hg
XDG_SESSION_ID=c1
USER=elronnd
PWD=/home/elronnd/BearLibTerminal_0.15.1
MANPAGER=less
HOME=/home/elronnd
GTK_MODULES=canberra-gtk-module
MAIL=/var/spool/mail/elronnd
WINDOWPATH=1
TERM=xterm-256color
SHELL=/usr/bin/zsh
HOSTDISPLAY=localhost:0
SHLVL=4
XDG_SEAT=seat0
MAVEN_OPTS=-Xmx512m
LOGNAME=elronnd
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
FVWM_USERDIR=/home/elronnd/.fvwm
PATH=/home/elronnd/.cargo/bin:/home/elronnd/bin:/home/elronnd/.cargo/bin:/home/elronnd/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
FVWM_MODULEDIR=/usr/lib/fvwm/2.6.7
LD_LIBRARY_PATH=Linux64
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on March 13, 2017, 05:59:21 PM
What i meant by "environment" was general info like OS and distro, bitness, how it is run, etc. I got most of it, but exact distro name may prove to be useful. My intuition is saying it is related to FVWM (though it shouldn't be happening either way, I am using fairly standard X11 mechanisms), I will look into it. Does the "window resizing" from SampleOmni not working properly either?

As for the log level, the point was to enable it before everything else to see the process of switching to fullscreen.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on March 13, 2017, 09:47:06 PM
Alright, I set the log level right after terminal_open() and got this:


14:16:50.451 [info] Trying to set "window.fullscreen = true"
14:16:50.451 [debug] Group "window":
14:16:50.451 [debug] * "fullscreen" = "true"


Interestingly enough, if I alt+enter while within the window, it fullscreens fine.  Even more interestingly, if I set window.fullscreen = true, while the window doesn't get fullscreened, I can then resize it even though I haven't set window.resizeable to true.  I'm on 64-bit arch linux, fvwm, I get the same output on both gcc and clang.  If it's relevant, my command line is gcc -std=c11 -LLinux64/ -lBearLibTerminal -o test test.c.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: The Saber Cat on April 10, 2017, 09:05:21 AM
Hello!
I am experienced programmer, but complete newbie in C++. I'm trying to learn C++ by building a simple game using BearLibTerminal, but I'm completely lost with CMake.
My folder structure is:
Code: [Select]
learn
  bin
    libBearLibTerminal.so
  lib
    BearLibTerminal.h
  src
    main.cpp
  CMakeLists.txt
My CMakeLists file is:
Code: [Select]
cmake_minimum_required(VERSION 3.7)
project(learn)

set(CMAKE_CXX_STANDARD 14)

set(CMAKE_BINARY_DIR ${CMAKE_SOURCE_DIR}/bin)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR})
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR})

set(SOURCE_FILES src/main.cpp)
include_directories(${CMAKE_SOURCE_DIR}/lib)
add_executable(learn ${SOURCE_FILES})
target_link_libraries(${PROJECT_NAME} ${CMAKE_BINARY_DIR}/libBearLibTerminal.so)

I'm trying to make my executable depend on libBearLibTerminal.so in the same directory, so I can zip them together, unzip on other Linux machine and run executable. But it sems that my executable depends on .../learn/bin/libBearLibTerminal.so, and not on the file in the current executable directory!

Being a complete newbie, I broke my head trying to make my executable be portable. So, I beg you to help - please, explain to me, how I can make libBearLibTerminal.so be shippable with main game file!..
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 11, 2017, 04:03:13 PM
Quote from: The Saber Cat
I'm trying to make my executable depend on libBearLibTerminal.so in the same directory, so I can zip them together, unzip on other Linux machine and run executable. But it sems that my executable depends on .../learn/bin/libBearLibTerminal.so, and not on the file in the current executable directory!
In Linux application dependencies (shared .so libraries) are not searched for in the same directory with application executable. By default only a few select system directories (e. g. /usr/lib64) are considered. It is possible to add extra paths to this list while linking the executable, this is what 'rpath' is (https://en.wikipedia.org/wiki/Rpath). CMake automatically adds paths to the libraries from nonstandard locations to the application's rpath, which is why your executable looks for the libBearLibTerminal in the ../learn/bin. It does not depends on that exact file, it depends simply on 'libBearLibTerminal.so', but that path is the only path from the search list where such file is present.

Therefore if you want to mimic Windows behavior of loading libraries from the same folder, you need to manually add the '.' path to rpath of your executable. In CMake it is something along the lines of
Code: [Select]
cmake_minimum_required(VERSION 3.7)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH ".")
project(learn)
...
Though I'm writing mostly from memory.

Another common approach on the Linux is to wrap the application binary in the script which sets LD_LIBRARY_PATH environment variable before launching executable. This environment variable also provides extra search paths for dependencies.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 11, 2017, 04:19:52 PM
Quote from: Elronnd
First is that setting terminal_set("window.fullscreen = true"); doesn't do anything.  The second is that although if you set the window to be resizeable, you can resize it, if you try to get the terminal size you just get the original size. <...> Interestingly enough, if I alt+enter while within the window, it fullscreens fine.  Even more interestingly, if I set window.fullscreen = true, while the window doesn't get fullscreened, I can then resize it even though I haven't set window.resizeable to true.
I've tested a few combinations of distros, desktop managers and windowing libraries (SDL, GLFW, SFML and my own implementation) and can only conclude that it is a complete and utter mess =(. On the same OS but different DM and vice versa the same X11 app may or may not resize and fullscreen properly. Sometimes it is clear who is wrong, sometimes not. Out of the libraries, SDL is the winner though sometimes even it is powerless.

I've honestly thought I would be able to provide a window implementation which, while not being as feature-rich as others, would be more compact (e. g. SDL is many megabytes in size) and more tuned to the exact situation (e. g. resizing in steps to match cell size). Yep, nope.

I've taken a deeper look at the SDL code and I can downsize it to something reasonable. Believe me, it is not as simple as --disable-everything in ./configure, you can disable almost nothing this way in the current SDL codebase. I've even tried to discuss this on their mailing lists but couldn't get through moderation (wtf?). I probably should file a bug.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: The Saber Cat on April 12, 2017, 02:01:40 AM
Understood, thank you!

Another question.

learn.ini:
Code: [Select]
[Game]
speed = 1

main.cpp:
Code: [Select]
std::cout << terminal_get("ini.Game.speed", "10"); // prints 10
Other values, like terminal window name, are loading perfectly. How can I make it fetch custom values?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 12, 2017, 10:18:45 AM
Quote from: The Saber Cat
Other values, like terminal window name, are loading perfectly. How can I make it fetch custom values?
Hmm, should have worked. Do you call terminal_get after terminal_open? Try to run the app from a console with BEARLIB_LOGLEVEL environment variable, e. g.
Code: [Select]
~/test$ BEARLIB_LOGLEVEL=trace ./SampleOmniThis will force the library to pring debug info about what configuration file it is using and what properties it has found.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on April 22, 2017, 11:15:25 PM
Is there a way to underline text or make it blink?  I can sort of make stuff underline by switching to another layer and printing ___, but there's a small gap in between them, and sometimes they overlap with the text in a way that's less than pleasing.  Also, is there a way to get bold or italic text other than loading an alternate font?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 24, 2017, 11:39:15 AM
Quote from: Elronnd
Is there a way to underline text or make it blink?  I can sort of make stuff underline by switching to another layer and printing ___, but there's a small gap in between them, and sometimes they overlap with the text in a way that's less than pleasing.
No, currently there is no such functionality. Underlining is theoretically possible (truetype fonts have some information and for bitmap fonts the library might try to do an educated guess).

Quote from: Elronnd
Also, is there a way to get bold or italic text other than loading an alternate font?
Again, currently no. If you are talking about automatically producing bold/italic variations from a single font, it is technically possible to implement (thickening or shearing the tile) but I think it would look pretty ugly. Ultimately the library would need to operate on relatively small bitmap tiles and geometric transformations of small bitmap images had never produced anything pretty.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Elronnd on April 25, 2017, 02:25:06 AM
Quote from: Elronnd
Is there a way to underline text or make it blink?  I can sort of make stuff underline by switching to another layer and printing ___, but there's a small gap in between them, and sometimes they overlap with the text in a way that's less than pleasing.
No, currently there is no such functionality. Underlining is theoretically possible (truetype fonts have some information and for bitmap fonts the library might try to do an educated guess).

Awww.  In that case, how does the cursor blink work?
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on April 25, 2017, 04:04:13 PM
Quote from: Elronnd
In that case, how does the cursor blink work?
The library cheats by using an internal read with timeout, flipping the cursor visibility every time it, ugh, times out. I've been thinking about blinking and it feels like blinking is just a case of simple animation. It would be nice to solve both at once.

Btw, just a bit better pseudo-underline might be produced by overlaying 0x2581 (Lower One Eighth Block) instead of underscores.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on May 14, 2017, 01:38:31 PM
Update 0.15.3 with various fixes: Windows (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.3.zip) / Linux (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.3.tar.bz2) / OS X (http://foo.wyrd.name/_media/en:bearlibterminal:bearlibterminal_0.15.3_osx.zip) / PyPi (https://pypi.python.org/pypi/bearlibterminal)
And TODO list is like a few miles long >_<.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: quejebo on May 23, 2017, 05:44:18 AM
Hey, I've been enjoying the library but I have a quick question:

I have a square grid, say 12x12, and I'd like to overlay a thinner font for text on it, say 8x12.  I've found that I can do this with put_ext, incrementing my dx by 8 for every character:
Code: [Select]
for (i,char) in enumerate(text):
    terminal.put_ext(x,y,i*8, 0, ord(char))
But this is rather less than ideal: it means lots of slow looping in python, and prevents me from using the nice annotation syntax (e.g., for color) that exists for print.  Is there a way to accomplish this same purpose with the print function?

Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Serin Delaunay on May 23, 2017, 09:14:32 PM
You could use a grid with 4x12 cells, and configure the font with "size=16x16, spacing=2x1". Then square symbols would need 3x1 spacing.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: quejebo on May 24, 2017, 06:46:46 AM
Thanks for the response.  That approach works in this example because they have a nice common denominator, but this isn't always the case for how I'm scaling things.  I suppose the more precise use case here is to easily use separate font scales for the UI from the game's grid -- without the requirement for nice integer ratios between them.
Title: Re: BearLibTerminal: a pseudo-terminal window library for roguelike
Post by: Cfyz on May 24, 2017, 06:52:17 PM
Quote from: quejebo
I suppose the more precise use case here is to easily use separate font scales for the UI from the game's grid -- without the requirement for nice integer ratios between them.
Well, this comes up from time to time... The main obstacle is that text in pseudo-terminal output is not a separate entity, it is the same as other tiles (and vice-versa) and must abide the same rules. When you try to detach text from the grid, different nuances arise. How to remove that text from screen when you can't address it by x, y cell anymore? What z-order does it take, always above the grid? And between each other text piece?