Messages

31

Programming / Re: How to handle targets?

« on: January 29, 2017, 06:36:09 PM »

How do you know the object you are reaching for has fallen off the table disappeared? The object does not call you back, you see that yourself and update your aim accordingly. I think it is worth to think from this perspective.

As for the purely technical side of your rather specific situation, smart pointers to the rescue? If you keep a weak pointer then it becomes easy to tell if the object is still alive.

32

Programming / Re: Screen Not Refreshing upon Menu Close

« on: January 29, 2017, 03:22:55 AM »

It would be much, much easier (to look at and point things out) if you could publish the code in some repository, even if a temporary one. The forum is not really suited for big chunks of code and this problem will probably require the whole source.

Unfortunately, the code posted is not enough to see the source of the problem: when and how new_columns/new_rows are used is not shown, neither is menu() implementation. Also, it was probably mangled while copying, there is a suspicious unreachable part in the inventory_menu() function.

33

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

« on: January 22, 2017, 11:14:53 PM »

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

34

Programming / Re: Packaging a python script as an executable

« on: January 18, 2017, 02:37:13 PM »

As for BearLibTerminal the problem was in the wrapper. It looked for a binary in the module directory (if it exists) or the application directory (otherwise). Turns out, a packed module still has its __file__, though a wrong one like "C:\dist\app.exe\terminal.py" which looks like there is an app.exe directory.

I've made a small update (0.15.1), changing the behaviour to look in both directories. I've tested it with PyInstaller and py2exe and it seems to work as long as you copy a library .dll near the .exe.
I do not know how to correctly pack the .dll into the executable yet.

35

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

« on: January 18, 2017, 02:37:03 PM »

Another small update: 0.15.1 (Windows / Linux / OS X / PyPi)
* 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.

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.

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.

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

36

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

« on: January 12, 2017, 10:01:29 PM »

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.

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.

37

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

« on: January 11, 2017, 09:44:32 PM »

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.

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.

38

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

« on: January 10, 2017, 12:35:33 AM »

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.

39

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

« on: January 09, 2017, 12:32:24 AM »

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

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:

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

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.

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.

40

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

« on: December 26, 2016, 10:28:30 PM »

Actually, no symbol out of Box Drawing (0x2500-0x257F) 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) 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 =/.

41

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

« on: December 26, 2016, 10:43:55 AM »

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?

42

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

« 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:


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!

43

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

« on: December 01, 2016, 10:22:45 PM »

Okay, here is an update: 0.14.12 (Windows / Linux / OS X / PyPi)

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

44

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

« on: December 01, 2016, 04:47:43 PM »

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.
Also, take a look at "Input 2: mouse" in SampleOmni (event counter, states and behavior) and it's source code.

45

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

« on: November 30, 2016, 09:46:09 PM »

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.

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

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.

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.

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.