User talk:Zzo38

Hi

I responded to your RELOAD comments including the textual format at Talk:RELOAD.

To run game.exe faster/slower, use Ctrl+Plus/Minus. That changes number of milliseconds per frame (shown in corner). You can also use the --runfast arg if you want no waiting at all for something like testcases.

You can give negative experience with the giveexperience command. I guess that there's no reason not to allow negative experience from enemies as well.

All of the suggestions are excellent and I'll add any that aren't already there to my TODO list. Several of them will be pretty easy to add. --TMC (talk) 05:56, 29 November 2014 (PST)

Unicode and UTF8

Hi, good to hear from you again! I very recently changed and cleaned up how ohrrpgce_config.ini works (I simplified it a lot as there were too many problematic edgecases) so am likely to start adding many more settings. You have a long list of requests here I could pick through for ones worth the time. In the current wip version you can now put game.gfx.fullscreen = no in ohrrpgce_config.ini to override the default fullscreen setting in all games.

BTW, I've just started on moving to UTF8. I've also designed my own space-efficient 8-bit-extended-ASCII-compatible character encoding to be used in existing fixed-length string fields, to allow more than 256 charcters in the font without switching those fields to UTF8. (Previously we discussed at Talk:RELOAD#Comments_about_file_format.) Have you ever used characters 1-31 in a game, aside from \n and \t? I want to repurpose those for codes such as "switch codepage". Also, I agree that it's better not to move icons in existing fonts out of the C1 control area, but need to think about what to do about characters 161-255 used for icons. --TMC (talk) 19:40, 14 October 2021 (PDT)

I have used them (with PC fonts imported into OHRRPGCE), although the games have not been released yet. However, hopefully it shouldn't be too difficult to be a global definition (perhaps by the format of the font lump) to disable the new feature if it is necessary to do so; if not, the game can be changed easily enough to support the new format I suppose. ASCII codes 14 ("shift out") and 15 ("shift in") are standard codes for switching code pages, so it may be a good idea to use those (if they are enough; they might not be). Escapes could also be used (including to display characters in the 0-31 positions of fonts, possibly). For existing fonts that do not use 0-31, there is probably nothing to change and it should just work (at least for display). --Zzo38 (talk) 23:27, 14 October 2021 (PDT)

I forgot that those two ASCII codes exist; I've never seen them used. But my encoding so far uses 12 control codes (it's not finalised) in order to be more compact, plus more for compressed text markup codes such as to change font or colour. Shift In/Shift Out don't match how my encoding works. Aside from \n and \t I'll also avoid \r since some OHR file formats use it, and the first few characters since there are fixed icons there in all OHR fonts, used by Custom - I think I've used those in a game at least once.

Disabling the new encoding if the game's font is in the old .fnt format seems simple enough that I can do that. I didn't really want to add an explicit setting for it, because it would be useless for almost everyone, dangerous to change, adds more code, etc. --TMC (talk) 05:11, 15 October 2021 (PDT)

OK, then do that; use twelve codes if that is how many you need. What is your encoding so far? If we can see, then it can be discussed. About disabling the new encoding when the old .fnt format is used, that seems reasonable, and is what I meant. --Zzo38 (talk) 09:51, 15 October 2021 (PDT)

Here is a draft decoder in FB. I'm not happy with the scheme yet. I'll create an article for it soon and write more. (I realised I should implemented the decoder/encoder in C instead so other projects can reuse it.) I found two unicode encoding/compressing schemes that are very similar to mine, SCSU and UTF-C. Neither are popular. Despite being published on unicode.org, it seems almost no implementations of SCSU exist. Plus, SCSU is pretty complex and even UTF-C is more complex than I want, so I think I will use my own. Here is FB code for a decoder.
I tested the scheme out on the FF6 Advance Japanese script (version with kanji). After removing the line prefixes, the characters are 21% ASCII, 39% Hiragana, 16% Katakana, 25% other (Kanji). Without using the "non-jump" codes, the text encodes to 1.706 bytes per character on average (with the additional codes compression will be slightly better). But 10-bit relative characters provide almost no additional benefit over 9-bit (1.707 Bpc) or even 8-bit ones (1.715 Bpc), so I should probably switch to 9-bit ones. --TMC (talk) 06:35, 18 October 2021 (PDT)

I think that treating the text fundamentally as Unicode is a mistake. Although many programs do this, I think that it is a bad idea (and my own projects aren't using Unicode, even when I do want to allow Japanese and other languages). Better would be just to use the font with multiple pages; they would be aligned as appropriate for the kinds of characters being used. A single shifting scheme can be used for the purpose of OHRRPGCE, although what each page means may vary depending on the font in use. (If translation between character sets/encodings is needed, another lump could be added to translate, although most of the program will probably not need such a thing.) (I believe that no one character set can ever be suitable for all uses, neither Unicode nor TRON nor anything else.) So, you probably won't need as much code space as Unicode (although I don't know if some uses might need as much or more, but probably OHRRPGCE needs less), and may wish to distinguish single-byte and double-byte pages (you can use double-byte pages for kanji, perhaps). --Zzo38 (talk) 11:04, 18 October 2021 (PDT)

Using unicode does have some disadvantages: it has a large space of codepoints which leads to less efficient encoding schemes (such as utf8), it has modifier/combining codepoints and other control codes, which we wouldn't try to support aside from simply drawing accents over the previous character, and it has multiple forms for the same character using different combining forms (I already have partially_normalise_unicode() in unicode.c to clean these up. But ultimately, the engine receives unicode input (as the user types, or when importing files) and aside from normalising composite characters it seems like extra complication to invent our own character set, which is ultimately just going to be based on unicode codepoints anyway, so it would be more correct to call it a subset of unicode. Fonts will still be organised into pages though. So you can add a Hiragana codepage, which provides characters for the unicode Hiragana block, initialised to defaults from an external font file (e.g. ttf), and customise them. As for the inefficiency of utf8, I don't like it, but it matters extremely little, and it's the standard and therefore the sensible thing to use for variable length strings. --TMC (talk) 17:13, 18 October 2021 (PDT)

OK, but what I am saying is to internally not use Unicode for text handling and use only the encoding of the fonts, and for translation to be performed separately when receiving input (and when exporting if needed). One option can be used to enable or disable character code translation when reading/writing external files (in case you do not want to use Unicode; I will not want to use Unicode). I am not trying to say that OHRRPGCE should define its own character set; it specifically should not, and also should not care (although it would have its own encoding scheme to select pages, similar to what you wrote). Perhaps, when editing fonts, you can specify the number that the game encoding uses, and optionally specify the corresponding Unicode code point (or pair of Unicode code points, which may sometimes be necessary); the Unicode numbers would then be used only for input and not for internal handling. I think that your idea of shift coding is mostly good (although with perhaps a few differences like I mentioned); your scheme is better than SCSU and UTF-C. (I try to write my suggestion/arguments but if you dislike it then you can do it your own way, I suppose. My ideas is merely just that--the idea, only. Note also that I have not worked with OHRRPGCE recently (and don't know when or if I will in future, although one thing I have done recently is to add OHRRPGCE and some related file formats into Just Solve the File Format Problem wiki)) --Zzo38 (talk) 18:07, 18 October 2021 (PDT)

Suggestions are welcome. Internal (in-memory) encoding of text and on-disk encoding are two separate issues. Given that we want fonts with more than 256 characters, only variable-length encodings are feasible; UTF-16 (or UCS2) is not an option for internal usage because it would be too much work to update all existing code, and not for on-disk usage in existing non-RELOAD file formats either because it's not compatible. UTF8 has various nice properties such as being stateless that make it good among variable-length encodings as an in-memory encoding (while my scheme is not), except that it is more complex to iterate over characters. Your shifted codepage idea makes iteration a little easier but is stateful (Edit: wait, being stateful makes iteration more complex), so I'm not sure it or anything else is a better alternative. (However we should use only normalised Unicode and avoid or even completely disallow combining characters; they are indeed a nightmare. I haven't thought enough about this.) Also, using the same on-disk encoding for all games instead of each game defining its own makes it easier to process game data files -- however admittedly the font editor already has a toggle between ASCII and Latin-1, so perhaps that boat has sailed.
Also, thanks for adding those pages to JSTFFP! It's a great project.

> I think that your idea of shift coding is mostly good (although with perhaps a few differences like I mentioned)

I'm confused about what differences you mean.

I agree that UTF-16 is a bad idea. I agree UTF-8 does have nice properties (even though I think Unicode isn't very good, UTF-8 is not a bad design). I agree also that each game can use the same on disk encoding, although the character sets of different games will not necessarily match even if the encoding does (this is already the case; this is simply extending it to work with large character sets); it is only guaranteed to be a superset of ASCII (and not necessarily a subset of Unicode; the characters that aren't in Unicode (if any) then just can't be input directly). You could use temporary shifts only if permanent shifts make it difficult (with only tempotary shifts, it will be stateless); the font used in the game would encode the languages more commonly used with smaller internal numbers in order to have shorter encoding sequences, I suppose. About combining characters, yes it is one of many messy things in Unicode. It is one reason why I suggested doing translation independently from internal handling (which might simplify some things at the cost of making others more complicated), and allowing a character in the game's font to optionally correspond to a sequence of up to two Unicode code points (or maybe more, but more than two would likely overcomplicate it too much), in case the game uses a character that is not available precomposed in Unicode, it would still allow that character to be translated correctly (if possible). (Other possibilities are to use private characters (which is possible in Unicode), or to abandon Unicode compatibility with characters not available in Unicode.) --Zzo38 (talk) 22:20, 18 October 2021 (PDT)

You've been using "encoding" and "character set" more carefully than me; I've been sloppy. I haven't totally made up my mind about any of this, because I don't entirely like any of the options. I agree that UTF8 is not so bad an encoding, and that a custom 1-2 byte encoding (e.g. one byte for 7-bit ASCII or two bytes a, b with 128<=a<b for up to 8256 characters) is possible if we use custom character sets, which could have nearly all the advantages of UTF8. But assuming that everyone already has easy access to utf8 encoding/decoding routines I don't think it's worth the extra work. Also, not having as large a range of codepoints as Unicode is a problem, because I wanted to allow people to use characters that aren't in their font (which would display as '?'), and use the same character set (assignment of codepoints) for all games, for various reasons: you can have multiple fonts and the plan is to fallback from one to another (e.g. the editor font fallsback to the game default font); so fonts from different games are compatible with each other and people can share them (this is the most important consideration of all); and also to make it easier to export data such as slices and textboxes, from one game to another without conversions. And I agree that we need to use a character set which differs more or less from Unicode, but I wanted to use the same codepoints as Unicode when possible to avoid needing to convert. I wanted to let people add pages of glyphs in their font for whatever (Unicode) codepoints they want. I also thought about adding extra precomposed characters to avoid combining characters (there are unofficial assignments of some precomposed characters to Private Use Areas) but it seems like the sort of feature noone will ever use. We already have icons that exist outside Unicode, I was going to put these in the C1 block and 0xE000 PUA, plus allow people to keep using 0xA1-0xFF for icons if they want. I am planning to translate from Unicode codepoints to the actual character pages+char indices that exist in the font at the point that a string is drawn to the screen, rather than storing them in-memory in that way. --TMC (talk) 18:15, 20 October 2021 (PDT)

(reset indent below)

You mention some things, and this will take a while for me to figure out all of my replies. So, I will write some now, and may write some more later once I think of it. (I am also writing in paragraphs this time.)

I fail to see why you would want to use characters that aren't in the font. However, about sharing fonts and exporting slices/textboxes, it does seem like good points to have a universal character set (although there will still need a private area for characters not in the set).

Maybe 8256 characters might be enough; it is more than JIS X 0208, but less than JIS X 0213, so I don't know; but I would think that 65536 characters is probably more than enough. There will be both characters in Unicode undesirable for OHRRPGCE (such as combining characters, and probably complex scripts) and characters wanted to be added (including some icons and some precomposed characters not present in Unicode). Some characters may be needed encoding as multiple Unicode code points, or a character might be ambiguous in some cases. There are also characters in Unicode that are the same as each other but semantically different and shouldn't need to be different (e.g. Greek uppercase Alpha), etc. (I really believe that no one character set or encoding can ever be suitable for all uses, no matter how much you try.) Because of this, using the same code point numbers as Unicode might be unnecessary (except ASCII, which is the same as Unicode and should use the same code point numbers).

Perhaps the characters to encode might include:

• ASCII (with the same ASCII numbers; it already is)
• Characters in PC character set and ISO-8859-1 character set (many of these overlap each other and below things; they should not be duplicated)
• Latin (including the non-Latin letters used in some Germanic languages, such as "þ")
• Cyrillic
• Greek
• Runes
• Japanese (including hiragana, katakana, kanji, and punctuation)
• Common icons used in OHRRPGCE
• Some lowercase letters with apostrophe before (some of these are used in Pokemon)
• Accented letters (some are present in Unicode; some aren't)
• Other precomposed characters (some of which might be present in Unicode; others might not be)
• Private area
• Unassigned area

(I suppose, the above (or a variant of this) is then the "RPG game character set") However, I am unsure. Maybe Unicode does help, but maybe not. (There are advantages and disadvantages either way.)

There is also the question of what font sizes will be supported, and if they will be fixed, variable, or narrow/wide. In the case of variable, letters preceded by apostrophes might not need their own code points. In the case of narrow/wide, Unicode is especially bad; some widths may be ambiguous (especially private characters), and they may change with newer versions of Unicode, meaning the program won't work properly unless you use a character set and encoding meant to support this use (one thing I had partially designed some time ago is such a character set and encoding specifically for narrow/wide fix pitch text without complex rendering). Fixed is probably simplest, though.

Now that I think more about it, I think that I may very well be wrong about many of the things in this message (but am still very unsure).

--Zzo38 (talk) 21:49, 20 October 2021 (PDT)

I thought of a few more things:

• Using unicode everywhere might be easier to use since the existing Unicode numbers can be used in fonts, although it would also make some things more difficult and not working the way that they do in Unicode (with all of the text directions, complex scripts, combining characters, compatibility characters, and other mess of Unicode) which would make things wrongly. (Different applications would have different needing and so different character sets.) (One alternative would be to display both in the font editor; when one is updated, so is the other one. This way, conversion will be applied automatically, while the disadvantages of Unicode are mostly avoided; however, the Unicode number may nevertheless be unexpectedly changed due to normalization, which is just something that you will have to deal with I suppose. Whichever way it is done, you must ensure that it is properly documented.)
• For icons in "RPG game character set", it may be helpful to have some icons labeled by intention (e.g. Attack, Defense, Poison, Regen, Light, Dark) instead of by representation (e.g. a sword). (However, by representation might also be useful in some cases (although by intention seems to be more useful to me), so I really don't know.)

--Zzo38 (talk) 12:22, 21 October 2021 (PDT)

Let's not use indentation for replies.

Thanks for the level of detail.

Variable width characters and arbitrary glyph sizes and much more are already implemented in the text renderer, mainly I just need to create a new font file format. So yes, I would not have "letters preceded by apostrophes" but that's the sort of thing people can add themselves. Many people already have messy things in their font, like alternative italic characters (which will be obsolete). The renderer could also support zero-width characters and characters which overlap the previous one (I probably need to modify text wrapping a little for them), however it's undesirable to have combining characters . Right-to-left text could be implemented in future but I have no plans to do so. I probably would implement right-to-left text differently from Unicode anyway and certainly not support bidirectional text at all.

You could probably spend all day looking through Unicode for codepoints to disallow or remap. I think the two approaches we're discussing are whether to "whitelist" or default-prohibit (come up with lists of scripts to support) rather than "blacklist" or default-allow by having a list of transformations for cleaning up Unicode and allow everything else. But either way it's simplest to still use the Unicode codepoints, so that forward-compatible expansion is free, and unrecognised characters can simply be added by the users that need them.

Unicode contains lots of alternative versions of characters (such as full-width Latin or half-width Hirigana) which aren't useful when you can instead change the font in the middle of a string (as the OHR can). If someone actually imports a string with such characters then we could attempt to convert to normal characters (assuming we use Unicode internally). Maybe it would be convenient if we did, if such text is common online, but it's not necessary: the user can (and maybe should) be left to fix the problem themselves, e.g. rewriting it or drawing characters for that Unicode page if they really have a use for them.

For complex scripts like Arabic, while I have no desire to add any special support for them and such users should use a different game engine if they need it, someone once pointed out to me Arabic can be rendered readably using fixed-width characters with no composing - that's done in many computer systems historically, like Teletext.

Regarding duplicate characters, maybe as a convenience the font editor could let you mark one glyph as being a copy of another. However that's extra complexity, while people can just copy-paste.

Cleanup steps when importing Unicode:

• Attempt to precompose composite characters as far as is supported
• Remove all special purpose Unicode characters such as Right-To-Left mark (RTL) and variant forms (which didn't compose into another character)
• Remove 0xF700 to 0xF746 (possibly more) which are generated on Macs by arrow keys, pgup, pgdown, etc
• Remap common compatibility characters like full-width ASCII to simpler versions ?
• Leave Private Use characters alone, they might have come from another OHR game
• Whether to remove C1 control characters may depend on where the text came from; they might be icons from an OHR game

As for combining characters that can't be composed, what I'm unsure whether to:

1. Leave them and attempt to support them in the text renderer by simple overlapping. If this looks bad users have to replace it themselves
2. Leave them and not try to support them in the renderer, so people will see them and replace them with their own custom characters
3. Strip them. Bad because it might be hard to notice what accents disappeared
4. Let users define custom pre-composed characters in their font which get used during import. If there's no such character, go with 1. or 2.
5. Let users define custom pre-composed characters, but don't remap to them during import, so that games don't have font-specific character-sets. Instead, search for them at render time when a combining character is encountered
6. Convert them to new custom pre-composed characters automatically, as in 4.

1. would be easiest for users, though I'm warm to the idea of just not having combining characters in our character set at all, and going with 2-4.

> I fail to see why you would want to use characters that aren't in the font.

Because a game can be in an unfinished state. You might want to import text first and then update the font, or try out a different font that's incomplete. Plus as I said, to use multiple fonts, none of which is complete.

I really don't think we should assign fixed icon meaning/numbering, because everyone's font is already different (although they are usually modified from the default) and everyone has different needs. It's not much trouble for people to copy-paste individual glyphs to where they want them on their font. I've recently realised it's better to give people a simple system they can customise rather than complexity which adds more things they need to learn.

--TMC (talk) 17:27, 22 October 2021 (PDT)

OK, those are good points. I think that will work; you could use Unicode or what is effectively a variant of Unicode (since some things will be changed; for example the C1 controls are now private characters instead of C1 controls). But as you mention, remapping will still be necessary anyways. This way you could have that you only need internal tables for the remapped characters and then Unicode characters that don't need to be remapped can just be passed through without being included in the remapping table, which can both save memory and simplify needing to handle all of the characters since they already are (so you will ensure not to miss some), I suppose. Some parts of the Unicode space might now be free, too (such as combining characters, and some compatibility areas, which will be remapped anyways).

However, not using Unicode might allow more compact encoding (but this might not be worth the risk). In my own projects (such as Free Hero Mesh, which currently supports only IBM code pages of 8-bit characters compatible with ASCII and only 8x8 fonts, but this might be changed in future to allow more) I deliberately don't use Unicode since I think it is unsuitable (and Unicode is also really messy) (I actually think it is impossible to design a character set or encoding suitable for all purposes), although there are both advantages and disadvantages of using Unicode (there are different advantages and disadvantages to TRON character codes (including that not much information is available (that is not written in Japanese) (and some that is available is too unclear), making it difficult to evaulate properly, but I am sure there are some problems with it anyways), but they are probably not useful outside of TRON, so need not be considered for OHRRPGCE).

For combining characters, I suggested something like 6; assign new code points and remap to those ones.

You could have an option to configure if you want to enable/disable remapping on import/export (remapping will always be enabled on keyboard input, but not necessarily on pasting from clipboard), in case you already have text in OHRRPGCE character set and if you want to keep it that way.

If you are using Unicode internally (or the variant of Unicode), there is also consideration: Will you keep or discard astral characters? Astral characters are not used much anyways and some will be difficult to implement like combining characters are or are controls (including variation selectors) or other things not meaningful here (some might also be variants that may be better handled by font switching, too). However, there are some things such as rare kanji (although it is unlikely that you will use more than a few in your game, if you use them at all).

However, just copying directly without remapping could also work; in that case, users must fix up the text by themself when trying to do things other than the simplest things. While this is simpler to implement, some languages may be more difficult to write in this way (although hopefully they are the ones that are not commonly going to be used in OHRRPGCE; I think the languages I mentioned above are some of the simple ones). If this way is chosen, it doesn't care if C1 controls are present; they are just passed through as is.

One idea I do have though is that the font could define which characters it may break a line for wrapping; mostly it will break lines at a space, but sometimes is wanted for others too, e.g. some languages they will not commonly write a space between words but will still need to line break. Alternatively, line breaking will be only manually, but that won't work very well when it contains dynamic text, when changing font metrics so that the text no longer fits, or if text can be displayed in window of different sizes (if it does this; I am unsure that it will); so, automatic line breaking can help to avoid this problem.

Finally, the conclusion is that it is still unclear what is best way to do. There are advantages and disadvantages whichever way it is done. I am unsure that I can be of any further help about this really, but if you have a question that you think I know the answer of, you can ask me. (Better you might make a separate page for this plan/discussion so that others may discuss it too.)

--Zzo38 (talk) 20:35, 22 October 2021 (PDT)

Sorry, been busy.

The more I read about Unicode, the more I'm inclined to try to deviate from it. I think I should stop talking about "unicode support" and instead just say "non-Latin scripts support," or something like that, to not give people the wrong expectation. But I still think we should use the same codepoints when we can, to avoid extra work.

It occurs to me that we can start restrictive with what codepoints are allowed, but plan to extend it. I would still be much better than the limitation of 8-bit text, but avoid ending up with nasty things in text fields.

For example, regarding astral characters, we could possibly initially disallow them, and then enable support later. It would be nice if we didn't need to support them, then UCS2 (UTF16 without surrogates) is an option for internal use (e.g. in a script interpreter), which is a nice one to have. Probably the most common astral characters would be emojis? Possibly we could remap the ones actually used below 0x10000 (like the proposal to precompose characters).

I don't really want to add precomposed characters to the font automatically. It seems like a lot of extra complication and work, the characters would be disorganised, and you could end up with a lot of characters you might not need anymore. And besides, you can input text while playing a game too, and it just doesn't work there. And all the most common combinations characters likely already precomposed forms in Unicode, while those that don't probably won't be feasible to support.

I already have implemented text wrapping with variable-width fonts (which is a feature that is definitely needed, although people can usually break lines manually if they need to), except it only breaks lines at spaces, because of course currently it supports ASCII only. I hadn't thought much about it. I wonder just how many common characters are there at which lines can be broken, aside from the zero width space (zwsp)? There's a list here. Are zwsp characters actually common in Japanese text? There's also the soft-hyphen, but I don't want to actually draw a hyphen when breaking there (it would be instead the same as nbsp). At first I thought the characters at which a line break can occur should be hardcoded, but if there are many of them then maybe being able to define them in the font is a sensible way to avoid having to hardcode all of them. I suppose there probably are thousands: many character that are graphical (e.g. emojis) rather than for writing words. But I assume for the majority it's completely unimportant to know that the line can be broken there, because they won't be used immediately adjacent to words.

Then there are also places when lines shouldn't be broken, such as on non-breaking spaces (nbsp) or before combining characeters (if we have them). However, I think that's unimportant enough that it doesn't need to be implemented, because lines will only break in the middle of a word if the word is very long or the line is very short. E.g. a nbsp will just be like any ordinary character (not treated as whitespace), but with a blank glyph.

Also, here's a list of unicode codepoints marked "Default ignorable", some of which I'd strip out, but not all of them: https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B:Default_Ignorable_Code_Point=Yes:%5D --TMC (talk) 08:24, 26 October 2021 (PDT)

(I fixed the link of the list of "Default ignorable")

I agree with most of that.

I dislike Unicode and think it is messy, so I agree with "The more I read about Unicode, the more I'm inclined to try to deviate from it"; it is why one of my ideas was to just avoid Unicode.

I had also been busy. Recently what I have been working on is my own "Free Hero Mesh" project. (I wanted to get others to help with my project too, and tried telling some people and writing elsewhere, but so far I have failed, so I don't know what to do about this now.)

Free Hero Mesh also currently is limited to 8-bit text with 8x8 fonts, although there is possibility in future to add support for multi-byte characters and other font sizes too. The considerations seem to be similar to that of OHRRPGCE: much of the internal code assumes 8x8 fonts with single byte characters, so the considerations for improving it are also similar.

--Zzo38 (talk) 15:44, 26 October 2021 (PDT)

You might have seen https://news.ycombinator.com/item?id=29022906 a couple days ago (I link to HN instead of directly to the page because the discussion is interesting too). It's really quite depressing; I had not realised that Han unification was a problem. So we can't supply a single font that's suitable for all CJK languages. Also, the things I read about rendering Japanese are also fairly burdensome. I think more OHR users have requested Japanese support than any other script, so if I'm going to put in special effort for just one language it would probably be that one.

Ooooh, I didn't understand at all what Free Hero Mesh is until I looked up Hero's Hearts. I had forgotten the name, but I remember playing the shareware DOS version of this game when I was very young! But I wasn't very good and I didn't get much into it unlike some similar games, which is too bad; I realised even then that it was a very deep puzzle game. Recreating it as free software seems like a worthwhile project. If would be very helpful if you could put more information and in particular screenshots on the Fossil main page, or at the very least link to screenshots, or create a non-Fossil webpage to show the project. They say a picture is worth a thousand words, but in this case I think no number of words will ever substitute for an image. Unfortunately I assume you don't want to display images or puzzles from the copyrighted original games, so that is a problem.

FHM didn't compile using the script. I had to bash xrmsmall.c and edit main.c to replace sqlite3.o with -lsqlite3. (There are also various compile warnings.)

After that I did manage to translate a MB file from shareware MESH: Hero's Hearts to FHM and play it. Very nice. Especially so because the original game couldn't be played using wine when I tried! There is almost no mouse support? I wouldn't use it anyway, but apparently in the original you can right click on objects to read descriptions?

I think for Free Hero Mesh the desiderata for fonts and internationalisation are far less than for the OHRRPGCE, though of course it's always better not to inherently limit software to particular languages.

What's the X resource manager code for? Clipboard access?

--TMC (talk) 06:37, 31 October 2021 (PDT)

I have read that discussion on HN and the article it links to, and I had known about the Han unification even before reading that. There are other things I also dislike about Unicode. (I am of the belief that a single character set can never be suitable for all purposes.)

One possibility might be a JIS-based format (e.g. EUC-JP), if you need only Japanese and the other languages supported in JIS. (There may be other possibilities too.)

Questions and comments about Free Hero Mesh are better discussed in the NNTP and/or IRC for this purpose, although I will also answer them here:

• If would be very helpful if you could put more information and in particular screenshots on the Fossil main page, or at the very least link to screenshots, or create a non-Fossil webpage to show the project. They say a picture is worth a thousand words, but in this case I think no number of words will ever substitute for an image. Unfortunately I assume you don't want to display images or puzzles from the copyrighted original games, so that is a problem.
  • You are probably correct. Once suitable screenshots are available, I can do this, and also add other information if needed.
• FHM didn't compile using the script. I had to bash xrmsmall.c and edit main.c to replace sqlite3.o with -lsqlite3. (There are also various compile warnings.)
  • If the warnings and other issues with compilation are posted on the NNTP, then it can be properly discussed, and then a better compilation code can be written. Proper packaging for different distributions can also be discussed.
  • One issue is that the version of SQLite in the system package manager might (depending on the system) not be updated as often as it should be. There is no guarantee that newer versions of Free Hero Mesh will not use features of newer versions of SQLite (or depend on bug fixes), although it also might not. (However, I think it is unlikely that newer versions of SQLite will break it.)
• There is almost no mouse support? I wouldn't use it anyway, but apparently in the original you can right click on objects to read descriptions?
  • In Free Hero Mesh, this function is mapped to the middle instead of right button by default, but the mapping can be redefined. (By default in Free Hero Mesh, the right button accesses the inspection menu, allowing inspecting the variables of objects at that location.)
• I think for Free Hero Mesh the desiderata for fonts and internationalisation are far less than for the OHRRPGCE, though of course it's always better not to inherently limit software to particular languages.
  • I believe you; it is probably far less important in Free Hero Mesh than it is in OHRRPGCE.
• What's the X resource manager code for? Clipboard access?
  • The setting file is in X resource manager format. Clipboard access is handled using the external "xclip" program, and must be mentioned in the setting file in order to be used. Free Hero Mesh should be able to work even without X (it use SDL, so should be compatible with any system with SDL); since X is not required, it has its own X resource manager implementation, and you can change the configuration easily to use whatever commands are appropriate for clipboard access on your system, instead of "xclip".

I may enter some of these questions and answers into the FAQ section of Free Hero Mesh later today, too.

--Zzo38 (talk) 13:53, 31 October 2021 (PDT)