[coding] TomeNET needs your help to find a bug! :D

[tangar]

Hi ho!

Just a few months ago I've presented my free-to-use 1-bit tileset for TomeNET (http://tomenet.eu) and not only: https://www.reddit.com/r/roguelikede...graphics_font/ ... Also wanna remind, that I'll be very happy if someone would use this tileset in YAGR (yet another great roguelike)

This tileset works great in TomeNET and makes gameplay much more enjoyable!

But we got a trouble...

There is a bug - currently it's not possible to map characters at certain glyphs of this graphical font:
0, 2, 16-31, 129, 141, 143, 144, 157, 195

If this bug would be fixed, it would be possible to add extra _24_ symbol in this tileset (I'll update my tileset, of course!). 24 symbols would make huge difference!

Devs don't know how to fix this bug It's even totally unknown where to find this mistake... That's why I beg every living person who knows something about coding to help in solving this issue!

Source files for TomeNET could be found there: https://tomenet.eu/downloads.php

Topic about this problem at TomeNET forum:

https://tomenet.eu/phpBB3/viewtopic.php?f=9&t=1737

Please don't hesitate to post any assumptions and hypothesis considering this bug, lets discuss it. Any hints could be useful!

[PowerWyrm]

Hmm... that's too random to be anything in the code. I guess it comes from your font. Are these symbols in your font mapped to non-ASCII characters? Did you start from the original font file? A modified file?

[tangar]

thanks for feedback! I'll add it to our headquarters ( https://tomenet.eu/phpBB3/viewtopic.php?f=9&t=1737 )

Previously dev's already fixed similar bug, when it was possible to map only 128 or so symbols... and now there is problem only with other symbols, like 16-31 symbols, so it still could be a bug in code.

I've modified original file (resized it).

[takkaria]

If this is in particular on the Windows port, it's I think a quirk that Windows Vista introduced. The way round it is to use different font handling libraries in the frontend.

[PowerWyrm]

Previously dev's already fixed similar bug, when it was possible to map only 128 or so symbols... and now there is problem only with other symbols, like 16-31 symbols, so it still could be a bug in code.

Well being able to map 255 chars instead of 127 = bug with char/byte, that's obvious. But not being able to map #157? Why not #158 instead? That's too random to be a bug in the code, unless there's a hardcoded table somewhere... I've looked at ASCII tables and those unmappable chars (except the ones below 32 which are system chars and shouldn't be remapped anyway) are not different from their neighbors (for example: you have one accented "i" that cannot be remapped while all other accented "i"s can). That's why I was suggesting looking at the font file and see what character was at position #157 to be sure it's not a special one. An easy way to tell is to use different font files from different countries and see if the unmappable chars are at same position.

[tangar]

Investigation into the problem (video):

https://www.youtube.com/watch?v=MDYDr2Ey5nY

List of problem glyphs:

0 linked to 35 (#)
2 WORKS!

16 ┼ 253C 197
17 â—„ 25C4 17
18 ↕ 2195 18
19 ‼ 203C 19
20 ¶ 00B6 20
21 â”´ 2534 193
22 ┬ 252C 194
23 ┤ 2524 180
24 ↑ 2191 24
25 ├ 251C 195
26 → 2192 26
27 � 2190 27
28 NULL
29 NULL
30 NULL
31 linked to 35 (#)

129 NULL
141 NULL
143 NULL
144 NULL
157 NULL
195 WORKS!

IT DOESN'T SHOW CORRECT VALUES AT OOOK.CZ FORUM, please visit https://tomenet.eu/phpBB3/viewtopic....9&t=1737#p5023 to see correct ones!

List of code page 437 table:

https://en.wikipedia.org/wiki/Code_page_437

TomeNET source could be found:

https://www.tomenet.eu/downloads.php

===
takkaria, I'm not sure about Vista.. So maybe we have to try another .fon file without glitch, as PowerWyrm suggested? I wasn't able to find good ones for it (see below)

PowerWyrm, it's good idea to try other fonts. But where to find another, 100% legit monospaced .fon file with ANSI/Latin1/CP1252 charset? I googled, but wasn't able to find such file. The closest thing I found is https://int10h.org/oldschool-pc-fonts/readme/ - but it's no in correnct charset... If I'll change it - it won't be 'template' anymore.. We need 100% native .fon file, exceptional model

[PowerWyrm]

I tried to test the feature but it simply doesn't work for me. So I won't be able to help here...

[tangar]

PowerWyrm, thank you very much for participation in this project! I've recorded video to show how to rearrange symbols in font:

https://youtu.be/mv7bxDMKYLo

(this isn't public video, access only by link)

[PowerWyrm]

PowerWyrm, thank you very much for participation in this project! I've recorded video to show how to rearrange symbols in font:

https://youtu.be/mv7bxDMKYLo

(this isn't public video, access only by link)

Found the problem, thanks. It was because the prf files are copied in a Windows local user directory and I had to modify the copied file, not the original one, so the changes would be applied.

As of the font issue, I've also found the problem. See post in tomenet forums.

[tangar]

Maybe I misunderstood something, but it seems that stuff which you pointed there - isn't the case. Replied @ TomeNET forum details

[tangar]

Guys, lets continue brainstorm!

For now we need to understand how to fix 0, 16-31 glyphs! As 1-15 works for remapping (but actually they are 'system' commands), it has to be possible to make 16-31 work too!

Currently they got this values:

0 linked to 35 (#)

16 ┼ 253C 197
17 â—„ 25C4 17
18 ↕ 2195 18
19 ‼ 203C 19
20 ¶ 00B6 20
21 â”´ 2534 193
22 ┬ 252C 194
23 ┤ 2524 180
24 ↑ 2191 24
25 ├ 251C 195
26 → 2192 26
27 � 2190 27
28 NULL
29 NULL
30 NULL
31 linked to 35 (#)

Symbols took from https://en.wikipedia.org/wiki/Code_page_437 (but they are in wrong places)

GOGOGO! We can do it!

===
!!! We got an important update:

'Fony' (http://hukka.ncn.fi/?fony) developer Hukka noted that:

Anyway, this seems to be a bug in the game and not Fony. I've seen at least two people say that it's because "Fony relies on Unicode", but that makes no sense when it comes to bitmap fonts, and Fony only really uses Unicode to display various language translations in the user interface. Previous versions of Fony didn't even support Unicode in any way at all! Bitmap fonts have no concept of Unicode, nor does Fony when it's handling them. It's just 256 glyphs, one after another, bitmaps in a file.

Does it looks like it's not the problem of the font, but actually the problem in the TomeNET code? TomeNET source could be found: https://www.tomenet.eu/downloads.php

p.s.
Also Hukka said that soon he would create crossplatform opensource version of Fony! Great news

[PowerWyrm]

As I said, there's nothing special in TomeNET code that handles symbols differently, except the fact it doesn't use Unicode standard. To be able to use all symbols, the char -> wchar change is mandatory. This means rewritting a huge portion of the code, like it was done in Angband a couple years ago.

[tangar]

PowerWyrm, thanks for a suggestion, but please could you explain then - why 1-15 glyphs works and 16-31 are not working? It's all system symbols but some of them work and some - not.

Also recent TomeNET test client had a funny bug which 'turned off' second symbol and it become not a monster, but a door: https://youtu.be/cDLueostm_Q?t=1h26m56s It's another proof that actually TomeNET code could interfere with font and maybe we could find the way to fix 16-31 glyphs (cause they actually SHOW something!)

[PowerWyrm]

Also recent TomeNET test client had a funny bug which 'turned off' second symbol and it become not a monster, but a door: https://youtu.be/cDLueostm_Q?t=1h26m56s

ROFL... the Witch-Door of Angmar

Is that door symbol actually part of your tileset? This means the code would remap character "2" to something else, like it does for 16-31.

But as the developer of Fony says, "Bitmap fonts have no concept of Unicode". So clearly I cannot see how you can fix anything without porting the code to Unicode.

[tangar]

PowerWyrm, yep, it's part of my font:


But it's not the case. I just showed you an example, that it's actually could be _code_ problem, not font. Again:

1) in current (stable) version of TomeNET client glyph #2 works perfectly

2) in test version of client - it become a 'door' (test client could be found at the bottom of this page: https://tomenet.eu/downloads.php ).
Detailed video explanation of the bug: https://www.youtube.com/watch?v=5AH61dV3JtQ
// it's temporary hidden video, accessible only by link, would be deleted soon

3) in the past (like ~6 months ago) #2 glyph didn't work either (that's why initially I marked it with 'X', when I just created 1st version of my font). So devs managed to fix #2 in current version, but then they did something wrong in test version of client (which I use right now while playing because of new music features).

This logic gives us an understanding that actually it's very like to be _possible_ fix 16-31 glyphs - cause #2 was recently fixed (and then broken again in test client).

This means the code would remap character "2" to something else, like it does for 16-31Unicode.

It does not! If you would check my tileset, you would note that 1-15 symbols works perfectly although they has to be _dead_ (it's system symbols, the same as 16-31). But they works. They show not a system symbols, but glyphs which _works_. I've wrote symbols which are showed at the place of 16-31 there - https://tomenet.eu/phpBB3/viewtopic....start=10#p5176 (at oook forum they couldn't be pasted). The are not remapped! It's just a symbols.

It leaves the main quesion very actual:

Why 1-15 glyphs works and 16-31 are not working? I believe that if we would be able to find an answer at this question, we would be able to fix the bug.