Messages

1

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: October 06, 2018, 10:24:17 PM »

Contrary to how it may look, I am not dead, yet =|.

What is the best way to start printing where the last print left off?

If you want to print phrase by phrase (actually more like paragraph by paragraph), then it is easy to do with measuring. Just remember that dimensions_t returned from print/measure is a size, not coordinates, so you have to add it to the last printing position. Note that print function also returns dimensions_t, you do not need a separate measure call if you've already printed the text.

However, if you want to literally continue printing, i. e. from the place of the last output symbol, there is no exact way. But I think there is no need. You can just concatenate the strings and print them in one go.

Say I wanted to change the color of one of the words in awesomeText to a custom color (activeTheme->crazyColor). What would be the best way to do it?

You can use some formatting tags in the string, e. g.

Code: [Select]

terminal_printf(x, y, "Some text with a [color=%d]word[/color] in another color", crazyColor); // choose %d or %s depending on the way you store the color (color_t or char*)

See terminal_print reference.

2

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: November 20, 2017, 12:55:58 AM »

Is this a constraint that can be relaxed?

It is a simple protection from accidental inadequate values like few millions by few millions. I agree that 256x256 is a bit small, so I've just replaced one hard-coded value 256 with another, 1024. This should be enough for now >_< (btw, lifting this further and playing with a FullHD worth of 1x1 pixel cells may be a good stress test for data structures involved).

TrueTypeTileset: can't parse 'size-reference' attribute

The correct format should have been

Code: [Select]

size-reference='@'
i. e. with quotes -- but nope, settings parser eats those quotes somewhere along the way. You can trick it by

Code: [Select]

size-reference=['@']
but the bug is definitely there. I assume it is not a big deal so I'll fix that sometime later.

3

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: November 09, 2017, 05:26:18 PM »

when attempting to set background color, only the upperleft-most grid square is given the background color information.

Looks like a bug =/. Expect it to be fixed soon in a few days.

Another question. I have some problems that were reported earlier by Elronnd in this thread <...> I'm using Arch too.
Is there a way to somehow fix this problem?..

Sorry, missed the message. As I've mentioned before, I'm switching to SDL in attempt to fix these bugs. I've tested several things and if SDL won't help, probably nothing will. However, the process gradually turning into total refactoring and starting to take some time. Probably I'll take the current code and make a version that just uses SDL for windowing to test this approach.

4

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: October 22, 2017, 07:30:06 PM »

Is there a way to use fonts of two different pixel sizes as ttf imports, without converting one of them in .png? If yes, how codepoints are shared between them?

Well it is indeed hard to guess what exactly do you have trouble with, but probably you're trying to put both fonts in a single codespace, i. e. make the them all have different code points similar to font + tiles. BearLibTerminal support multiple codespaces for this purpose exactly, to have two (or more) separate fonts, with each one using the same (yet their own) code points for the same characters/tiles:

Code: [Select]

terminal.set('font: one.ttf, size=8x16')
terminal.set('another font: two.ttf, size=10x20')

Where 'another' is an arbitrary name to your liking. And then there are two ways to use it:

Code: [Select]

# Inline string formatting
terminal.puts(2, 1, 'Hello, [font=another]World')

# Global state
terminal.puts(2, 2, 'Hello, ')
terminal.font('another')
terminal.puts(2+7, 2, 'World')


5

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: August 03, 2017, 05:18:15 PM »

Also, is there a way to empty the queue of input keys or does the library support preventing the following thing?

Yes, you can drain the input queue quite easily:

Code: [Select]

while (Terminal.HasInput())
    Terminal.Read();

Personally, I don't like the idea of just skipping the events. Simply dropping them may lose input randomly. Imagine the user pressing a movement key and then some key combination. If you happen to drain the queue at a wrong time, you may be left with only a part of a combination which can drastically change the meaning (though it is hard to lose a simple state like Shift/Ctrl modifiers since BearLibTerminal keeps them available through Terminal.State).

Maybe a bit more robust solution would be to filter out only the repeats? Something like this:

Code: [Select]

int previous_key = Terminal.State(Terminal.TK_EVENT);
while (Terminal.Peek() == previous_key)
    Terminal.Read();


6

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: August 02, 2017, 03:25:37 PM »

I've got a png bitmap font that's not even transparent as there's a black layer behind the font file. In addition I've specified the font to be not transparent:

Code: [Select]

font: Cheepicus.png, transparent=black, ...


Actually, it is exactly how you make it transparent, you specify a color which is to be treated as transparent. I probably need to formulate it more clearly in docs. Indeed, specifying some random color like red will force the entire tileset to remain opaque.

Though while there may be different cases, usually you want the font to be transparent. It is more flexible, e. g. printing over various backgrounds, compositing over tiles, etc. The library tries to make font transparent and I've made it quite automatic over time, so the question how to switch it off instead actually made me lost for a few moments =).

To not display them above the UI, I've got a empty tile in my tileset that I've rendered above the buffer row. However, when I print text to the message log area, the buffer map row is shown only under the text. In general, it seems that words printed displays everything under it.

Do you put those empty tiles and then print text in the same layer? By default, the library operates in 'replacement' mode in which tiles/characters replace previous ones (in that place within the same layer). If my guess is correct, the log is simply replaces empty tiles you've used to cover the map tiles making them visible again.

Besides more or less obvious solutions (making font opaque or switching to composition to not replace tiles), there is also one less known feature that may be particularly useful here: layer crop region. It instructs the library to show only a portion of a layer, kind of cutting away the rest. It was introduced precisely for such situations where it may be hard to hide extra portions of some complex scene with offset and overlayed tiles.

Btw, the Set method supports string formatting:

Code: [Select]

Terminal.Set("window: size=" + Constants.ScreenWidth.ToString() + "x" + Constants.ScreenHeight.ToString() + "; ...");may be

Code: [Select]

Terminal.Set("window: size={0}x{1}; ...", Constants.ScreenWidth, Constants.ScreenHeight);

7

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: July 18, 2017, 04:13:39 PM »

And I am back. Mostly. Okay, in chronological order:

I'm trying to figure out if there is a way to call terminal_read_str and obfuscate the input, for creating something like a password input field. <...> I know I don't have to use terminal_read_str but I do like the cursor functionality that it exposes.

No, the terminal_read_str function is a fairly simple wrapper over standard library input/output and its functionality is very limited. The only thing that is not directly available in API is a timed read which it uses to animate the cursor. I'll consider input obfuscation, but in the meantime it should be quite easy to write a custom read_str. Here is a simple outline for a custom read_str but without a cursor. For that you'll need to wrap the call to terminal_read, something along the lines of

Code: [Select]

int terminal_read_timeout(int timeout)
{
    for (int i = 0; i < timeout; i++)
    {
        if (terminal_has_input())
            return terminal_read();
        else
            terminal_delay(1);
    }
    return -1;
}
And flip the cursor every read that timed out.

Idly wondering if it'd be possible to combine bearlibterminal with PyQt?

It is hard to integrate any fairly complex custom input/output into a GUI framework, be it Qt or another one. Usually it is easier to completely rewrite one side to match the other =/.

I am registerd just to ask: is mouse supported by BearLib terminal in Linux? <...> Maybe mouse events should be enabled before it can be catched?

Yes, you have to enable it explicitly. Specifically:

Code: [Select]

terminal_set("input.filter={keyboard, mouse}");
Yep, not the most intuitive part =/.

I remember that you are planning to switch to use SDL for bearlibterminal. Does it mean that you are going to drop support for true/open type fonts?

Nothing of the sort. The only thing I need from SDL is its cross-platform window and context management (I'll try to cut everything else away). From the user perspective transition to SDL should not even be noticeable at first. It is more about portability/stability and management costs.

8

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: July 01, 2017, 08:53:45 PM »

However, the function returns False regardless of whether or not the shift key is held down. <...> the function works when I set number lock off, but doesn't work when number lock is on.

I've looked into it a bit and was quite surprised by what they call Shift overriding NumLock. When you press Shift+4 you get the same scancode as when you press 4 without Shift, and what character is produced depends on the keystroke as a whole. However Shift+Numpad4 with NumLock on does not produce the scancode of the numpad key. Instead it imitates pressing the single left-arrow key by un-pressing the Shift key, sending an arrow keypress and restoring the Shift back to its original pressed state. And the system events that simulate this temporary Shift release are indistinguishable from the real key release and key press =|.

The only hint about the nature of Shift events is the inhuman speed they happen at: the Shift is released 0-2 ms before the corresponding arrow key event. Maybe I'll be able to filter  the events based on that.

P.S. I am away for about two weeks, so unfortunately I won't be able to test or fix anything in the meantime.

9

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: June 19, 2017, 07:21:14 PM »

Is there a way to get FPS when using Bearlib?

Well, since BearLibTerminal uses explicit refresh (does not draw continuosly by itself, only redraws if necessary) I did not thought much about displaying FPS. Values like 0.1 would look weird =). Essentially, how frequent you call terminal.refresh() would be the FPS.
Though I do calculate it in the 'speed' entry of the SampleOmni and so does the Python port of the sample. Note that vsync is enabled by default and you need to disable it (the 'output.vsync' option) if you want more than 60-80 FPS.

10

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: May 24, 2017, 06:52:17 PM »

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?

11

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: May 14, 2017, 01:38:31 PM »

Update 0.15.3 with various fixes: Windows / Linux / OS X / PyPi

• Add font() function (select the current font by name, closes issue #33).
• Fix adding sprite tiles to an atlas (closes issue #30).
• Fix excess generation of 'character replacement' tiles.
• Fix dynamic tile generation (individual to a font, closes issue #32).
• Fix configuring several fonts in one set() call (closes issue #34).
• Retrieve clipboard contents via terminal_get("clipboard").
• Fix bitmap tileset reverse codepage (sparse tileset) handling.
• input.cursor-blink-rate=0 disables cursor blinking in terminal_read_str().
• Fix printing tab characters (configured by output.tab-width option).
• Fix app hanging on reopening terminal in macOS (see issue #23).

And TODO list is like a few miles long >_<.

12

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: April 25, 2017, 04:04:13 PM »

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.

13

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: April 24, 2017, 11:39:15 AM »

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).

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.

14

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: April 12, 2017, 10:18:45 AM »

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.

15

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: April 11, 2017, 04:19:52 PM »

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.