BearLibTerminal: a pseudo-terminal window library for roguelike

[Aukustus]

I'm not sure if this has been talked earlier, but it seems that there's some "bleeding" through layers with fonts.

Image of the problem: https://www.dropbox.com/s/3qemusoa3khsipt/BLTBleeding.png?dl=0

So what I've done: For a smooth movement there's a "buffer" of one extra row of tiles each direction that are rendered under the UI so that when I move, I use the gradually increasing offset to display them appearing smoothly from behind the UI.

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

Terminal.Set("window: size=" + Constants.ScreenWidth.ToString() + "x" + Constants.ScreenHeight.ToString() + "; font: Cheepicus.png, transparent=black, size=16x16; input.filter={keyboard, mouse}");
The same effect comes with my mouse hover that displays the name of the object below it. The font is clearly transparent still: https://www.dropbox.com/s/j1vuzpshzni4ue3/BLTBleeding2.png?dl=0

Any idea how to fix this, or is this a bug? I don't want my font to be transparent at all when it is printed in the message log.

[Aukustus]

Okay, a slight update: I changed transparent=red and it works, it's not even red at all anywhere, but now the black layer in the font file is deemed as non-transparent.

[Cfyz]

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

[Aukustus]

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.

Ah, this was it . I did print the tiles and the messages in the same layer. I didn't think print would be in replacement mode, but I guess it's only logical because "print" works like "put" behind the scenes, if I recall correctly. Now the messages are on a layer above the empty tiles and it works!

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.

I need to look into this cropping definitely.

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

Awesome .

I must say, your library is pretty much *the* graphical library when making roguelikes .

EDIT: Also, is there a way to empty the queue of input keys or does the library support preventing the following thing? I've noticed that if I've got a long lasting for loop, it registers and queues all the key inputs during the loops execution time. When I press a long time a movement key, it begins the movement but if I don't take my finger off the key, it puts the movement key into the queue like a hundred times, and it keeps unloading the queue so it is stuck until all the key presses are removed from the queue. This is because I've got my smooth movement implemented by a for loop and it renders the character at different offsets, so while it is moving one tile, all the keys are registered that are pressed during the movement.

[Cfyz]

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();


[Aukustus]

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();


Code: [Select]

            int key = Terminal.Read();

            if (Terminal.Peek() != key)
            {
Seemed to the trick. I've got no idea how it works, but it works .

[The Saber Cat]

Hello!
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?

[Avagart]

In general, using several different fonts at one is rather straightforward and mostly trouble-free, but I don't get what *exactly* are you asking for.

[Cfyz]

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


[The Saber Cat]

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:

Got it, thanks! From reading documentation I got strange idea that two fonts share the same codepoints.

Another question. I have some problems that were reported earlier by Elronnd in this thread - namely, "window.fullscreen = true" not working and strange behaviour of "window: resizeable=true" (with this enabled, window can be resized by clicking the square button in the title, but not by dragging corners). I'm using Arch too.
Is there a way to somehow fix this problem?..

[quejebo]

I'm attempting to use a font with a spacing greater than 1x1.  While setting the character works as expected, when attempting to set background color, only the upperleft-most grid square is given the background color information.  See the example image below.

I realize that, in the worst case, I can brute force this by decomposing each print call into two separate print calls (a 1x1 spaced font in layer 1, which only contains background information and my 3x3 spaced font in layer 2, with only the character information),  but it seems like this might be a feature worth baking into the font configuration.

Thanks for the help, and the great library.

https://imgur.com/a/6HF5g

[Cfyz]

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.

[quejebo]

I've tested out the new build and it fixes the background color issue; thanks!  This allowed me to move my cell size from 12x12 to 4x4, but then I encountered another issue -- there's a hard-coded check that window.size < 256, which, with a 4x4 grid, only gives you 1024 pixels to work with.  Is this a constraint that can be relaxed?

Another (I think) bug.  I was messing around with font settings and found that:
size-reference=0x40 works fine but
size-reference=@
gives me:
[error] Failed to set some options: TrueTypeTileset: can't parse 'size-reference' attribute

[Cfyz]

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.

[Nekoninja]

Has anyone use Code::Blocks with BearLibTerminal successful? I am working on how to make it work.