Messages

1

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

« on: August 01, 2019, 11:04:03 PM »

Has anyone done a CFFI wrapper for BearLibTerminal with PyPy? 

The ctypes interface is rather slow with the PyPy JIT.  I'm doing a variant on the Python Roguelike Tutorial and at equivalent of step 3 in the libtcod tutorial, repeat key can outrun the game loop and fill the input to where you get a bunch of moves after you release the movement key. 

Haven't profiled it yet, nor taken steps to remove unnecessary calls to (for example) terminal.color or buffered rows as text with color markers, etc - all of which would help if ctypes is indeed the culprit and a CFFI wrapper isn't commonly available. 

Of course all this assumes I finish writing the tutorial- for personal use an existing CFFI wrapper would save me some time and most likely a bit of head scratching.

Thanks,
Omnivore

2

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

« on: July 26, 2019, 12:41:04 AM »

Back after 3 years! 

Just a note if you are using BearLibTerminal in Python and the PyCharm IDE:

If you add BearLibTerminal to your Python 3.x installation via 'python -m pip install BearLibTerminal'
you'll find some oddball behavior in importing it especially in a PyCharm project.  The easiest fix
I've found is simply to use the following import statement:

Code: [Select]

from bearlibterminal import terminal as bltand then if/when PyCharm shows an error on terminal, just right click and tell it to ignore it.

I believe the problem is with PyCharm's overly strict interpretation of Python syntax and import behavior.

Hope this helps,
Brian aka Omnivore

PS: I was being an idiot - had multiple possible imports from old install and used Pascal casing *gah*

3

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

« on: April 12, 2016, 01:39:10 PM »

Would there be any harm in allowing ALT key as key press/key modifier even when input.alt-functions=true ?

Can't think of anything 'harmful' but that will leave things a bit fragile. A simple example would be zooming which is commonly bound to plus(in)/minus(out)/zero(reset) so default shortcut will overlap with hypothetical Alt+0 'teleport to position' command.

Wouldn't any custom CTRL-[0=-] bindings also make CTRL fragile in this case?   
[EDIT] Assuming the zoom functions were bound to unmodified [+-0], obviously CTRL bindings are non-fragile if zoom is ALT-[+-0].[/EDIT]

I know its popular these days to protect programmers from themselves, but given good documentation, overlapping a non-disabled default binding with a custom binding would, to me, be programmer error on the part of the library user.

Does that call result in the lib making an internal copy of the passed data, or does the application need to hold that data in memory after the call?

Yes, a copy is made. Memory is not precious enough to make user juggle with buffers lifetimes =).

As you can see, not much of in-memory loading is supported right now, only raw BGRA bitmaps. It was more like a proof-of-concept for low-level library API (you can pass a System.Drawing.Bitmap object into Terminal.Set function in C#, a table of pixels in Lua, etc. =_=). Looks like I'll have to expand this functionality soon.

Personally, for purposes of loading bitmap data, raw BGRA format is fine.  If necessary can always do format conversions either pre-build or inline in the source language of the app.  For TTF, most languages should provide some method of loading a binary file as a byte array which could then be passed with no format changes.  I'm unsure of what would be required for CP files.

Since you already have the capability for raw bitmap data loading, I don't know if I'd consider the addition of the TTF/CP/other bitmap format handling to be a high priority.  It is always possible to use the kludge of copying to temp file as an interim workaround in the app language source.  Of course, that depends upon the usage patterns, where for my needs seem to be perhaps a half dozen to a dozen bitmap files, one TTF file, and at most one CP file.  Not sure if that is typical.

In any case, thanks
Brian aka Omnivore

4

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

« on: April 11, 2016, 07:14:20 PM »

With all due respect, sir, I accuse you in being silent.

Guilty through pessimism, my apologies.

That said, wouldn't everything be OK if BearLibTerminal had these UI shortcuts simply enabled by default with an option to disable them? Like "input.alt-functions=false" and then you are on your own with that key? All these shortcuts are just conveniences, not a core feature. My previous questions (what are you doing and why) were to find out if there is something that might be better accounted for or integrated into these library tricks. If what you need is some 'raw access', then why not?

Yes that would work.  Best would be if the default mapped functions could be accessed individually when the "input.alt-functions=false".  In other words, rather than alt-enter (assumed default) switching full-screen, the same switch could be accessed via a menu in the application's UI. 

An example of a custom mapping might be: CTRL-(1-9) sets a 'recall' position, ALT-(1-9) teleports to that position.  Another might be a plugin that enables some plugin-defined behavior with a multiple SHIFT-ALT-(some key) sequence, or a user remapping of keybindings.  Also, in a left-hand on keyboard, right-hand on mouse setup, the ALT-key is, at least on some keyboards, adjacent to the spacebar and easily thumb-accessible while other fingers are on 'main' keys (qwer-asdf-zxcv).  In games (example ASCII-Sector) which combine both turn-based and real-time play (depending on mode), the difference between easy to reach ALT and (relatively) hard to reach CTRL may be significant.

If some mode allows ALT key both as key press and key modifier to be accessed then such custom mappings can easily be accomplished.  ALT key as modifier being the most important for general use I believe.  Would there be any harm in allowing ALT key as key press/key modifier even when input.alt-functions=true ?

Support for streamed/archived resources is something I lazily thought of (mostly because no one voiced it before) but there is some support already as BearLibTerminal can load images from in-memory buffers (look at relevant line in the sample). This is not complete: you cannot load TrueType fonts or text files (codepages) from memory =/. It would be nice to make possible to load resources from streams but I just cannot figure out how API for that should look like.

Oops, I missed that usage of terminal_setf.  If I'm reading that sample correctly, then loading from stream to memory and then making the terminal_setf call would handle most reasonably sized bitmap files assuming the pixels are in the correct color format.  Does that call result in the lib making an internal copy of the passed data, or does the application need to hold that data in memory after the call?

For TTF, there is a version of the FT_New_Memory_Face call that accepts a memory buffer address, so that may give an alternative entry point.  Not sure about the code page text files although, given that they are likely to be a small file, a kludge fix might be to copy to a temp file and load that.  Of course the same kludge could be done with TTF fonts. 

For streams, yeah the interface would be a problem, especially given the multiple language mappings.  Frankly I'd be happy with just using memory buffers as long as the expected format of the byte buffer and call are well defined.  It would also be preferable I think if the lib made a copy of the passed buffers so that the caller could discard the buffer after the call to terminal_setf.

I'll try to be less silent in the future, maybe a bit more optimistic

Thanks,
Brian aka Omnivore

5

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

« on: April 11, 2016, 03:29:00 PM »

Also, Omnivore, are you here? I've meant my response on bitbucket as an invitation to discussion. Can you provide some examples of what are trying to do? Maybe there are even some conventions about keys and shortcuts in cross-platform applications on Mac?

Oops, I seem to have missed this earlier.   

I simply do not believe an I/O library should be making UI decisions for me.  How any particular OS or GUI implementation handles ALT keys is really not the point.  Fact is, no other I/O library that I have used or can remember examining discards ALT key presses and ALT key state.  Also, IIRC, your response on bitbucket indicated you were going to embed certain alt-key presses in the lib for uses such as full-screen switch.  I am totally opposed to hard-wired UI behaviors in an I/O library.

It is, of course, your library, however given your response to the bitbucket issue I raised and my disagreement with your stated intentions, I've moved on to other solutions.  There was one other issue I was going to raise that I consider equal in importance to the ALT key handling, but have not raised it previously since I've moved on.  I'll raise it below just in case other users may find it of interest.

The other issue is that I desire a solution that is compatible with either or both resource streams and PhysicsFS https://icculus.org/physfs/ type file systems.  Both of these solutions allow single file binary distributions of both DLLs and media as part of an executable or plugin.  The major change to BearLibTerminal would be to allow loading of media as byte buffers as an alternative to files.  A minor change might be required for some wrappers in order to allow dynamic loading of the BearLibTerminal DLL itself. 

I would still recommend BearLibTerminal to anyone who doesn't desire ALT-key handling and/or no install, single file, distributions.

Hope this helps,
Brian aka Omnivore

6

Programming / Re: Heterogeneous saving and loading objects in C++

« on: April 06, 2016, 08:09:03 AM »

Hope this helps,

It didn't help, because I didn't check it out. If it's too difficult to express your opinions about this problem in this thread using words then do not participate.

I simply don't care enough to write an explanation only to be accused of whatever you're blathering about in regards to Skullcoder's reply.
 
Omnivore

   

7

Programming / Re: Heterogeneous saving and loading objects in C++

« on: April 05, 2016, 08:22:59 PM »

Here's a complete library of C++ serialization/deserialization as part of an object oriented database tookit I wrote in 2001: https://sourceforge.net/projects/cpolib/files/cpolib/initial_alpha/.

It should have everything you need.

Hope this helps,
Brian aka Omnivore

PS: some of the dependencies are no longer available and the source at that link for the multithreaded version is crap.  Still it has everything you need to do serialization in a number of ways, along with options to work with DLLs and it handles circular references, is STL compatible, etc.

8

Programming / Re: Digital rights when commissioning a project to a developer

« on: March 06, 2016, 04:31:31 PM »

Hire a lawyer.  Now.  If there's not enough money involved to hire a lawyer, then its not worth worrying about because you couldn't afford to enforce the contract in court anyhow.  Seriously, hire a lawyer.

Hope this helps,
Brian aka Omnivore

9

Programming / Re: Simple, stable, energy system

« on: March 01, 2016, 01:10:11 PM »

That looks like a sensible approach to the problem. If I adapted it for use in my own projects I'd probably use 1 rather than 0.001 as the smallest unit of time (or make it a parameter when initialising the object), and make the modifier in modify_time() additive (or overwriting) rather than multiplicative.

Thanks.  I used 0.001 as an 'epsilon' value to avoid problems with floating point equality.  In a static typed language I'd probably just use integers for abstract time values.   

It is a bit hard to see in the code but the list elements returned by current_actors() are tuples of three parts: the time of the action, the id of the actor, and a reference to the actor data.  Normal actions apply an additive value calculated by the time of the action + a suitably modified action cost of the next action directly to the actor data action_time field as the actor is processed.  I didn't add a method for this because there are too many external factors involved and it doesn't require accessing the actor mapping.

The modify_time is multiplicative because it is for use when one actor applies a 'slow' or 'fast' effect to another actor.  Really this could be done externally in a similar manner to the primary route detailed above for normal actions, the modify_time method is just a helper.

In actual code, since I use a 'pure data component/virtual entity/all game logic in systems' ECS model, I'm extracting the current_actors method out as a stand-alone method (or perhaps as a member of a model class) renamed to schedule.  It just seemed to be more widely applicable to demonstrate it as a class.

Thanks again,
Brian aka Omnivore

10

Programming / Re: Can someone explain "Dijkstra maps" to me, please? Are they even a thing?

« on: March 01, 2016, 12:33:16 PM »

Huh, interesting, I don't know why Google couldn't find those Roguebasin articles! Thanks!

Since these mostly aren't called "Dijkstra maps" outside the roguelike development community, google tends to read the query as "dijkstra on a map".

To the game programming world at large, these are mostly called influence maps.  Try googling: game programming influence maps.  Other good search terms for the same concept are Heat Maps, Terrain Reasoning, and Using Potential Fields, and the general field of Map Analysis.

Hope this helps,
Brian aka Omnivore

PS: ah I see Tilded already gave the influence map reference as well as one I haven't heard (flow maps).

11

Programming / Re: Simple, stable, energy system

« on: March 01, 2016, 12:18:29 AM »

@ Zireael: Kodiologist uses Hy which is... Lisp on Python.

@ Quendus: Good points!  I prefer to implement DoT and similar effects as independent entities.

After some thought and review, I realized that the major difference between an energy system and an abstract time system is that conceptually the 'traditional' energy system is just an inverted abstract time system with a fixed 'current time' of zero.  I revisited my earlier ideas and implementations, and came up with a very simple new system in Python which, I believe, addresses all of the concerns and has a low overhead should processing time be a concern.  It also is, I believe, more compatible with ECS (all code in systems) approaches.

See https://gist.github.com/Brian61/2702669ba9f42802815d#file-scheduler-py for Python source.

If N is the number of Actors, and M is the number of Actors ready for processing, then the scheduler.py algorithm is of O(N + M*log(M))*.  For comparison, a priority queue based approach is O(M*log(N)).   However, for rescheduling, the algorithm in scheduler.py is O(1) while a priority queue based approach is O(N*log(N))**. 

Hope this helps,
Brian aka Omnivore

*depends on the ratio of N and M, for low M:N the N term predominates, for high M:N the M*log(M) term.
**the textbook figure here seems too high, it should really be O(log(N)) in most use cases.

12

Programming / Re: Simple, stable, energy system

« on: February 28, 2016, 09:26:34 PM »

Found an alternative, and in many cases much improved, solution: https://www.reddit.com/r/roguelikedev/comments/484gb2/turnkeeping_issues_with_energy_and_fatigue_systems/d0h3qmb

There are some other solutions discussed in that thread but Kodiologist's approach as used in Rogue TV seems to be the best.  If anyone is interested in a Python adaption of the idea or wants an explanation of how to adapt an energy system to an abstract timed system, post a reply and I'll do my best to help.

Hope this helps,
Brian aka Omnivore

13

Design / Re: OOP, ECS, Roguelike, and definitions

« on: February 26, 2016, 02:48:11 PM »

You can lead a horse to water, but you can't make it drink.

For anyone who actually wants to take a drink, at the bottom of the page: http://entity-systems.wikidot.com/games-using-an-entity-system  there are six open source games using various ECS implementations. 

In particular, look at Escape From the Pit, as it seems to be the closest to the data model that I've been speaking of in earlier posts in this thread. 


The above aside, this thread is not about one particular data model or style of programming.  It began simply as an observation that there exist many, often conflicting, definitions for commonly used terms when it comes to game design and programming.   My conclusion is simply, "It is all about the data."  There is no 'one right way'; given the tools in your toolbox, use what best fits the data model you have.   If none of your tools fit, it might be worthwhile expanding your toolbox. 

Hope this helps,
Brian aka Omnivore

14

Design / Re: OOP, ECS, Roguelike, and definitions

« on: February 25, 2016, 05:52:30 AM »

Can someone explain what the fuck am I reading?

Dude, it is simple, it is just modeling your data as a tessellation of n-dimensional Euclidean space by congruent parallelotopes

Hope this helps,
Brian aka Omnivore

15

Programming / Re: beyond python and curses

« on: February 24, 2016, 10:27:39 PM »

I have started reading a bit of pygame documentation, but could anyone give me a few suggestions about the functions/modules that are most useful for roguelikes? I guess the text renderer, for instance.

I've been using pygcurses lately, it sits atop pygame and gives you a curses-like text oriented interface