BearLibTerminal: a pseudo-terminal window library for roguelike

[Cfyz]

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 (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 to manage available extensions. Your code just have to be ready for features not being there, like any other graphics application.

[Junkyardfreak]

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;


[Cfyz]

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

[Junkyardfreak]

Dangit, I'm so bad at this haha  And all I want is a simple roguelike base so I can work around it...

[Junkyardfreak]

If someone could hand me their roguelike code I would be happy! (Using only bearlib)

[Rakaneth]

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.

[Cfyz]

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.

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.

[Rakaneth]

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.

[Elronnd]

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, 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?

[Cfyz]

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

[Serin Delaunay]

Update time: 0.15.0 (Windows / Linux / OS X / PyPi)

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.

[Elronnd]

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?

[Cfyz]

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

[Elronnd]

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

[Cfyz]

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.