Remapping ASCII values on an extended font, in need of some guidance

[gebe]

Hi there!

I am quite new to libtcod and have a question about remapping the ASCII codes using an extended font. As I have understood it it is possible to use a font that is bigger than 256 characters by remapping the original ASCII codes to another part of the bitmap font by using the "console_map_ascii_codes_to_font" function. I just can't seem to get it to work though and I am starting to believe that it might be that I have misunderstood something.

I can successfully remap ASCII values within the first 256 characters of the font but when I try to remap any ASCII value to a character that lies beyond those (for example position 0, 16 and beyond in an INROW layout) it just starts over from the top (that is 0,16 equals 0,0 and so on). I have tried different layouts and extending them both vertically and horizontally, but nothing seem to work.

This is approximately how I been trying to use it for a 512 character font without success (and like I said, I have tried different layouts, extending it vertically/horizontally, tried just remapping single values/characters and so on, I am basically at my wits' end ) :
libtcod.console_set_custom_font("a_font.png", libtcod.FONT_TYPE_GREYSCALE | libtcod.FONT_LAYOUT_ASCII_INROW, 16, 32)
libtcod.console_map_ascii_codes_to_font(0, 255, 0, 16)

I am using the python bindings and the latest release candidate. Any help is appreciated, the main goal for me is just extending the number of characters I have at my disposal so if there is any other way in accomplishing that as well I am all ear!

Thanks in advance!

[jice]

Does your font bitmap actually contain 512 characters ? Can you post the font bitmap ?

[gebe]

Hi! I have attached a 256x512 pixels test font.  

The interesting part is that I just downloaded 1.5.0 and made a little test program, and there it worked I tried the same in 1.5.1 with the same results as before. Here is the code I used:

edit: I might also add that with 1.5.0 it mapped the whole font automatically and I could use ASCII values over 255 "out of the box" which I didn't think was possible.

Code:

import libtcodpy as lt

lt.console_set_custom_font("testfont.png", lt.FONT_TYPE_GREYSCALE | lt.FONT_LAYOUT_ASCII_INROW, 16, 32)
lt.console_map_ascii_codes_to_font(0, 255, 0, 16)
lt.console_init_root(80, 50, "test", False)

#1.5.0
lt.console_set_foreground_color(0, lt.white)
#1.5.1
#lt.console_set_default_foreground(0, lt.white)

while not lt.console_is_window_closed():

#1.5.0
#lt.console_print_left(0, 1, 1, lt.BKGND_NONE, 'a')

#Both
lt.console_put_char(0, 5,  5, 15)

lt.console_flush()

key = lt.console_wait_for_keypress(True)
if key.vk == lt.KEY_ESCAPE:
break

[researcho]

  cool, hard-coded noise!  very interesting approach

i didn't get to those characters, so i've put my own character set inside the 256 ascii set (losing a lot of standard chars  )

maybe jotaf have the issue clear, but i think it is related to the incapacity of python wrapper of libtcod to reach non-ascii codes, any solution here will be useful for me also 

[gebe]

cool, hard-coded noise!   very interesting approach

i didn't get to those characters, so i've put my own character set inside the 256 ascii set (losing a lot of standard chars   )

maybe jotaf have the issue clear, but i think it is related to the incapacity of python wrapper of libtcod to reach non-ascii codes, any solution here will be useful for me also  

   Just for testing purposes   I thought so as well (I believe I read it somewhere here on the forums, might be outdated) and that's why I wanted to try to get the remapping to work. But like I wrote in my previous post it worked perfectly with the earlier version, 1.5.0, to the point that it automatically assigned values above the unsigned byte value range to the extended part of the font. I assume it ought to work in later releases as well.

It's not that critical for me but as usual when I can't get something to work I throw a disproportionate amount of time away looking for workarounds  

[Ogre]

This looks like a problem with the OpenGL renderer to me.  If you can use SDL, try that.  Though I think that might also be wrong, it has an ascii_to_tcod mapping that only gets initialized for the first 256 values.  It doesn't always use that, it may have the correct value at render time despite that mapping.  I started out changing that thinking it was going to fix it, but it was still broke.  Following it further down revealed that on my Mac, it's actually routing everything through the OpenGL renderer.

Although the main SDL buffer stores ints for each location, the OpenGL renderer is storing them as chars, making it impossible to select characters >= 256.  I'm working on fixing it, but it's not as simple as just changing a "char" to an "int", and this is my first time in this code.

[Ogre]

After digging a little more and gaining an understanding of how things are supposed to work, the OpenGL and SDL renderers are both fine, it's the GLSL renderer that's broken.  GLSL just happens to be the default.  Change your lt.console_init_root call to this and your test program should work:

Code:

lt.console_init_root(80, 50, "test", False, renderer = lt.RENDERER_OPENGL)

I used this to test rendering the whole font:

Code:

import libtcodpy as lt

lt.console_set_custom_font("testfont.png", lt.FONT_TYPE_GREYSCALE | lt.FONT_LAYOUT_ASCII_INROW, 16, 32)
lt.console_init_root(80, 50, "test", False, renderer=lt.RENDERER_OPENGL)
lt.console_set_default_foreground(0, lt.white)

while not lt.console_is_window_closed():
    for y in xrange(32):
        for x in xrange(16):
            lt.console_put_char(0, x, y, y * 16 + x)

    lt.console_flush()

    key = lt.console_wait_for_keypress(True)
    if key.vk == lt.KEY_ESCAPE:
        break

It also works with your remapping in place: it renders the extended characters twice, except for 0, which I think is getting treated specially somewhere.  And also 255, but that's because your remapping call should have 256 in it, not 255, to get the whole set.  It's number of characters, not the maximum character.  Both behaviors are consistent across all three renderers.

I also submitted a pull request for the GLSL renderer, it wasn't too hard to fix once I understood it all.  (Scratch that, it didn't work at all, it was just falling back to SDL and making me think it did, back to the drawing board on that one )

[gebe]

Ah, great news and a great find! Can't believe I didn't even try different renderers while troubleshooting (especially since it worked "magically" in 1.5.0)  

Many thanks for figuring this mystery out! 

[Ogre]

Alright, I submitted another pull request that actually works this time. It may negatively impact performance of the GLSL renderer slightly, I'm not sure what the consequences of changing it from one byte per character to 4 bytes per character are.  I couldn't make it work right with 2 bytes per character, though someone smarter probably could .  I wonder if anyone using libtcod needs to squeeze enough performance out of it that it matters?