Messages

46

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

« on: November 30, 2016, 11:58:40 AM »

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.

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

47

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

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

48

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

« on: November 15, 2016, 04:06:24 PM »

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.

The "[keyboard+, mouse]" notation feels a bit clunky, but I just can't think up a better one.

49

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

« on: October 15, 2016, 02:10:22 PM »

It should work as long as Python does not lose unicode along the way:

• make sure the source code is saved in suitable encoding, e. g. utf-8
• make sure that encoding is conveyed to Python with 'coding' comment
• in Python2 use unicode strings

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


50

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

« on: August 31, 2016, 01:00:19 PM »

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 worth of them in the terminal.

[Edit]

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.

51

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

« 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

52

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

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

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.

53

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

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

54

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

« on: August 30, 2016, 10:44:54 AM »

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)


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.

55

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

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

56

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

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

57

Programming / Re: DIY programming language

« on: July 22, 2016, 10:36:36 PM »

I am pretty sure languages being created by programmers and engineers is the sole reason humans can write programs at all. Let non-engineer write an algorithm and only a trained neural network of another human will have any chance to reliably execute that.

And I doubt any programming language inconveniences can actually bury a really good and interesting idea. It is just a tool after all. Actually, in my experience, most of the better results (be that programming, DIY, photos, etc.) were produced with subpar tools and equipment, whatever was at hand at the moment of inspiration.

58

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

« on: July 07, 2016, 01:08:19 PM »

From the current pip code (here) 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.

59

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

« on: July 07, 2016, 12:52:48 PM »

Edited out.

60

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

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