Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Cfyz

Pages: [1] 2 3 ... 13
Quote from: quejebo
I suppose the more precise use case here is to easily use separate font scales for the UI from the game's grid -- without the requirement for nice integer ratios between them.
Well, this comes up from time to time... The main obstacle is that text in pseudo-terminal output is not a separate entity, it is the same as other tiles (and vice-versa) and must abide the same rules. When you try to detach text from the grid, different nuances arise. How to remove that text from screen when you can't address it by x, y cell anymore? What z-order does it take, always above the grid? And between each other text piece?

Update 0.15.3 with various fixes: Windows / Linux / OS X / PyPi
  • Add font() function (select the current font by name, closes issue #33).
  • Fix adding sprite tiles to an atlas (closes issue #30).
  • Fix excess generation of 'character replacement' tiles.
  • Fix dynamic tile generation (individual to a font, closes issue #32).
  • Fix configuring several fonts in one set() call (closes issue #34).
  • Retrieve clipboard contents via terminal_get("clipboard").
  • Fix bitmap tileset reverse codepage (sparse tileset) handling.
  • input.cursor-blink-rate=0 disables cursor blinking in terminal_read_str().
  • Fix printing tab characters (configured by option).
  • Fix app hanging on reopening terminal in macOS (see issue #23).
And TODO list is like a few miles long >_<.

Quote from: Elronnd
In that case, how does the cursor blink work?
The library cheats by using an internal read with timeout, flipping the cursor visibility every time it, ugh, times out. I've been thinking about blinking and it feels like blinking is just a case of simple animation. It would be nice to solve both at once.

Btw, just a bit better pseudo-underline might be produced by overlaying 0x2581 (Lower One Eighth Block) instead of underscores.

Quote from: Elronnd
Is there a way to underline text or make it blink?  I can sort of make stuff underline by switching to another layer and printing ___, but there's a small gap in between them, and sometimes they overlap with the text in a way that's less than pleasing.
No, currently there is no such functionality. Underlining is theoretically possible (truetype fonts have some information and for bitmap fonts the library might try to do an educated guess).

Quote from: Elronnd
Also, is there a way to get bold or italic text other than loading an alternate font?
Again, currently no. If you are talking about automatically producing bold/italic variations from a single font, it is technically possible to implement (thickening or shearing the tile) but I think it would look pretty ugly. Ultimately the library would need to operate on relatively small bitmap tiles and geometric transformations of small bitmap images had never produced anything pretty.

Quote from: The Saber Cat
Other values, like terminal window name, are loading perfectly. How can I make it fetch custom values?
Hmm, should have worked. Do you call terminal_get after terminal_open? Try to run the app from a console with BEARLIB_LOGLEVEL environment variable, e. g.
Code: [Select]
~/test$ BEARLIB_LOGLEVEL=trace ./SampleOmniThis will force the library to pring debug info about what configuration file it is using and what properties it has found.

Quote from: Elronnd
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. <...> Interestingly enough, if I alt+enter while within the window, it fullscreens fine.  Even more interestingly, if I set window.fullscreen = true, while the window doesn't get fullscreened, I can then resize it even though I haven't set window.resizeable to true.
I've tested a few combinations of distros, desktop managers and windowing libraries (SDL, GLFW, SFML and my own implementation) and can only conclude that it is a complete and utter mess =(. On the same OS but different DM and vice versa the same X11 app may or may not resize and fullscreen properly. Sometimes it is clear who is wrong, sometimes not. Out of the libraries, SDL is the winner though sometimes even it is powerless.

I've honestly thought I would be able to provide a window implementation which, while not being as feature-rich as others, would be more compact (e. g. SDL is many megabytes in size) and more tuned to the exact situation (e. g. resizing in steps to match cell size). Yep, nope.

I've taken a deeper look at the SDL code and I can downsize it to something reasonable. Believe me, it is not as simple as --disable-everything in ./configure, you can disable almost nothing this way in the current SDL codebase. I've even tried to discuss this on their mailing lists but couldn't get through moderation (wtf?). I probably should file a bug.

Quote from: The Saber Cat
I'm trying to make my executable depend on in the same directory, so I can zip them together, unzip on other Linux machine and run executable. But it sems that my executable depends on .../learn/bin/, and not on the file in the current executable directory!
In Linux application dependencies (shared .so libraries) are not searched for in the same directory with application executable. By default only a few select system directories (e. g. /usr/lib64) are considered. It is possible to add extra paths to this list while linking the executable, this is what 'rpath' is. CMake automatically adds paths to the libraries from nonstandard locations to the application's rpath, which is why your executable looks for the libBearLibTerminal in the ../learn/bin. It does not depends on that exact file, it depends simply on '', but that path is the only path from the search list where such file is present.

Therefore if you want to mimic Windows behavior of loading libraries from the same folder, you need to manually add the '.' path to rpath of your executable. In CMake it is something along the lines of
Code: [Select]
cmake_minimum_required(VERSION 3.7)
Though I'm writing mostly from memory.

Another common approach on the Linux is to wrap the application binary in the script which sets LD_LIBRARY_PATH environment variable before launching executable. This environment variable also provides extra search paths for dependencies.

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.

Quote from: Elronnd
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'.

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.

Quote from: Rakaneth
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.

Quote from: Rakaneth
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.

Quote from: Junkyardfreak
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.

Quote from: Saafris
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.

Quote from: Saafris
It sounds like interacting with BearLib's layers would be more difficult and involved?
A bit. The Terminal.cpp, line 2054 is where layers are drawn and same file, around line 2102 is a probable place to insert custom inter-layer rendering. The nuance is that textures are not switched/restored between layers unless necessary so you need to be careful here and restore texture state if changes were made.

Quote from: Saafris
I'm curious as to why you chose such an older version to work with
The answer is simple: to cover as much hardware and platforms as possible. For example, low-end hardware like EEE PC or virtual machines with severely limited graphics support. OpenGL 1.2 is enough for core functionality. This is what I meant by extra library support necessary to provide full-featured custom rendering -- the library would need to provide means to select/assert OpenGL versions and fallbacks across multiple platforms.

I plan to use some of the newer functionality, e. g. framebuffers and shaders for better scaling/filtering or cleartype-like glyph rendering, but this will be strictly optional.

Quote from: Saafris
Any suggestions on where to start with that (or if it's even feasible)?
If you're doing this for your own project, it is actually very easy. After all, the overall scope is limited and you do not have to care about future compatibility that much.

At the very bottom of Terminal.cpp there is a small Terminal::Render function. Which invokes a full redraw+flush. The point between Redraw() and SwapBuffers() is probably the best place to insert any custom on-top rendering (or a callback to it). Currently there is little caching is done and no fancy features are used, so it is fairly safe, just do not mess with any global state like viewport or matrices. The projection matrix is configured to pixel coordinates suitable for using glVertex2i to draw 2D figures. Resources (textures, buffers) may be initialized pretty much anytime after terminal_open() since everything is already set up after that call.

The OpenGL version is not enforced in any way meaning you may end up with as little as OpenGL 1.2 but no higher that 2.x (the old fixed pipeline is used). This will break somewhat when I add support for OpenGL ES (which does not have fixed pipeline). Everything remotely complex (from mere NPOTD textures to shaders) must be tested for availability and loaded manually  before using.

Pages: [1] 2 3 ... 13