There's also one thing that would be really cool to implement but I'm not sure how to do it. I want to add unifont font, which is the font used in the game. I have a .ttf file but I'm not sure what to do next.Indeed it would be best to be able to see the actual results using the target font! REXPaint uses bitmap fonts so you'd have to take the ttf font and use it to create a PNG file* with the necessary characters in the CP437 layout. You can look at the other included fonts to see how they're done. Creating a bitmap font can be a fair amount of work, though.
"picture": [
"",
"",
"",
" <white>╔═══════════════════╗",
" <white>║ ║",
" <white>║</color> <yellow>╔═ ╔═╔═╗╔═║ ║</color> <white>║",
" <white>║</color> <yellow>║═ ┼ ║ ║═║╚╗║═║</color> <white>║",
" <white>║</color> <yellow>╚═ ╚═║ ║═╝║ ║</color> <white>║",
" <white>║ ║",
" <white>║ RIVTECH TRUST ║",
" <white>║ ║",
" <white>║ ║",
" <white>║ 555 993 55221 066 ║",
" <white>╚═══════════════════╝"
]
"",
"",
"",
" <color_white>╔═══════════════════╗",
" ║ ║",
" ║</color> <color_yellow>╔═ ╔═╔═╗╔═║ ║</color> <color_white>║",
" ║</color> <color_yellow>║═ ┼ ║ ║═║╚╗║═║</color> <color_white>║",
" ║</color> <color_yellow>╚═ ╚═║ ║═╝║ ║</color> <color_white>║",
" ║ ║",
" ║ RIVTECH TRUST ║",
" ║ ║",
" ║ ║",
" ║ 555 993 55221 066 ║",
" ╚═══════════════════╝"
Also while we're discussing reducing the file size reduction, BBcode export sets a color for spaces (black), which is unnecessary because spaces look the same no matter the color.
The " at the beginning can be applied in a few seconds using "column mode" or whatever it's called in a text editor, but adiing ", at the end it takes more time because lines usually have different lengths thanks to the color tags.Note you can do the entire thing really fast in any editor that offers macro recording. Like I use Notepad++ for much of my editing, and it could update an entire image with the proper formatting in a matter of seconds. Not that you'll need it once REXPaint can output this format, just mentioning for the meantime :)
the previous solution works fine assuming the user resizes the canvas width to 41 characters, which he should do anyway if he makes art for CDDA.Indeed, the export format should be applied properly as if the entire image is to be used, so resizing the image (and really the canvas via the settings so that it uses the required dimensions as default) should be required of the user.
Update: I've added the font used in the game! Was tedious but super easy. I've attached it so you can add it to resources if you want to.Oh awesome, thanks for that! Will be adding this to the resources.
I could get other prefixes or background colors to work by adding them after the "color" prefix i. e. <color_light_gray_light_red> or <color_i_red> but they produce errors regarding line length. If I wanted it to work without errors I would have to ask a coder to fix it, but I'm not sure if I even need that. As you said somewhere previously background colors make the art look "blocky" and I did fine without them. So because background colors don't work you shouldn't implement them.So you did get background colors to technically work (as in they're okay to have in the file), they just produce errors for now? As in they don't stop execution or anything? Technically I should include those in the implementation since they're part of the specification, even if the code is not yet ready.
3. Background colors don't carry on between the lines, so they have to be typed every new line like in the example art (not that much of a problem thanks to "useless" color tags for spaces).Ah, well not an issue for converting the existing BBCode format, but it would definitely be an issue for the new export I just finished working on! I've got a new dedicated C:DDA export feature (ctrl-j), but it sounds like it's hard to call it official if there are so many issues...
Anyway, I'm pretty hyped for the new release, I think I'll have to celebrate by making new art and posting a guide for using REXPaint for CDDA!Yeah this would be great! Definitely drop a note here in the thread when you do, both so that I know and can also probably link it from elsewhere.
I guess it can be assumed background colors should behave as foreground colors do, wrapping to new lines etc?I guess so, I think the developers simply didn't even consider someone would use background colours. I'll let you know if background colours get fixed.
I discovered that it's not entirely clear how background colors would be handled if they change from the previous color. Overall there needs to be more examples and guidance on the specifications there :/I'm not sure what you mean exactly, are you asking if for example in this case
So far it errs on the side of always including the foreground and background color whenever either changes since the last time it was set.
"<color_white_red> A </color><color_green> B ",
background of B would be black, because background is not specified, or red because the previous background was red? The answer is that B would be black. If color of the background isn't specified, it won't be colored (or it will be black? Which is the same thing anyway). background of B would be black, because background is not specified, or red because the previous background was red? The answer is that B would be black. If color of the background isn't specified, it won't be colored.Yep, wasn't sure whether to do it that way or not. So it's apparently assumed the background is black if not specified. Really the specifications are way too slim on details xD
I noticed that if the background color is black, then it's exported as <color_colorname_black>. This generally doesn't work in CDDA, instead it should be simply <color_colorname>, which has the same visual effect but is actually accepted by the game.
(or it will be black? Which is the same thing anyway)Exactly part of the problem with the specification not including any details here, since I don't know if it's possible to change the default background color in CDDA, and if so then would CDDA then treat any art's unspecified background color as the new default? Or would black then be actually black as specified by the art??? :P
"<color_white_red> A </color><color_green> B ",
What if we wanted to change only the background color, but retain the same foreground color as before? The lack of differentiation between the two in a string means that you then have to restate the foreground color, I guess,e.g."<color_white_red> A </color><color_white_green> B ",
in order to change the background while keeping the foreground white.Also it's not exactly CDDA related but it might helpful for users with small screens. It existed in previous versions too: if your screen is small and font height is big, then the program window will not fit on your screen.As a terminal program with a minimum static row count, this is just how REXPaint works--a large screen is required for larger fonts, though the manual describes a setting that offers a partial workaround for those who don't mind having negative side effects. (2.0 will likely be different since the UI will be more flexible.)
Also an issue that's present both in this and previous versions: whenever I set canvasWidth to less than 42 in config file the program changes it to 42, and I have to set it manually every time I open it.Ah true, this is actually the minimum default canvas size allowed by REXPaint in order to fit certain UI elements (this is indicated in the context help for that setting in the options menu). I'd forgotten about the relevant settings and should update the new CDDA Appendix to point out that it's not default canvas size that should be updated, but Default Image dimensions (also found in the options menu). That's what should be set to 41 in order to make editing more convenient.
I see that the color tags for spaces are back, I assume it's the price we had to pay for fixing the issue with spaces with background colors? If it's possible to add color tags for spaces only when it's absolutely necessary it would be really nice because it would make the text file image more "clear". If you can't do that then alternative would be to add 2nd option to export with the previous system where spaces with background colors don't work as intended but you get a nice, clear text file.Maybe it's not necessary at all? I mean I'm not really sure what's absolutely necessary based on the specification since it's so sparse, and I don't have a CDDA setup to test with so I'm relying entirely on you xD
Overall it seems to be working fine, I exported an image and put it into the game. But while I was doing it I remembered one thing: single \ in game file is treated as if it didn't exist (I think it has something to do with json in general?). The solution is to replace every \ with \\, which will display \. 2 backslashes will be treated as one character for purposes of line length calculations and the solution works fine also if you want multiple backslashes.Ah, okay I wasn't aware this was going to be an issue. Yeah backslash is a JSON escape character, so I'll have to change the output such that it converts that to two characters, no problem.
Also can you tell me which section of the manual describes this workaround setting ? I've read all the sections except for the layers but I couldn't find it.It's in the Options section under Customization. It describes the "unlimitedFontSize" setting.
Setting this value to 1 loads all fonts, even those which will allow extreme zooming where it produces a window which doesn't fit on the screen!But I can load the same fonts (many of which indeed don't fit on the screen) on either setting .
About the black color tags: yeah, they are completely unnecessary: for spaces because it doesn't change anything and for other characters because well, why would I want to draw anything in black if it's gonna look like an empty space anyway?Yep, just originally wasn't sure how CDDA renders things like the terminal background.
I don't see any difference between unlimitedFontSize 0 or 1, manual saysHm, this is an unrelated issue to what we're doing here, but it might be because the unreleased v1.50 you have contains an issue with the font size calculations? I rewrote a bunch of that in order to support unlimited numbers of characters in fonts, and thought I fixed any new bugs in all cases, but perhaps not.QuoteSetting this value to 1 loads all fonts, even those which will allow extreme zooming where it produces a window which doesn't fit on the screen!But I can load the same fonts (many of which indeed don't fit on the screen) on either setting .
I assume that the max resolutions are the same as defined in data\fonts\_config.txt?No, max resolution is not defined anywhere because there's no need to explicitly define it. There are some comments in the config file, but that's it. But anyway, found that there's apparently still a bug in the new font loading process so I'll have to address that before release.
I attached the run and _config.txt files . I see that only CP437 20x20 exceeds resolution (and can't be used, I think? Hard to tell when the font name is outside the screen).Your run.log looks normal. With a 1080p screen 20x20 is the only font that should not fit, and indeed it should not be loading unless you have unlimitedFontSize set to 1.
With a 1080p screen 20x20 is the only font that should not fitThat's the problem, 14x14 is exactly the height of my screen:
" ",
" <color_light_gray>|\\</color> ",
" <color_light_gray>|</color> <color_light_gray>\\</color> ",
" <color_light_gray>|</color> <color_light_gray>\\</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_light_gray>|</color> <color_light_gray>|</color> ",
" <color_dark_gray>(____)</color> ",
" <color_dark_gray>[__]</color> ",
" <color_dark_gray>[__]</color> ",
" <color_dark_gray>[__]</color> ",
" <color_dark_gray>[__]</color> ",
" <color_dark_gray>[__]</color> ",
" <color_dark_gray>[__]</color> "
and it would be better if it looked like this: " ",
" <color_light_gray>|\\ ",
" |\\ ",
" | \\ ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | | ",
" | |</color> ",
" <color_dark_gray>(____) ",
" [__] ",
" [__] ",
" [__] ",
" [__] ",
" [__] ",
" [__]</color> ",
and it would be better if it looked like this:Hm, could be more complicated, but anyway I guess the idea there is that spaces without any explicit background can't reset the color in any way. I'll look at it, thanks for the specific example.
That's the problem, 14x14 is exactly the height of my screen and anything bigger doesn't fit, but only 20x20 can't be selected.Ah okay, then this isn't a bug, just what happens when you have DPI scaling enabled. REXPaint normally tries to deactivate it, but it would appear your OS is forcing it on the program anyway. REXPaint's engine reads the actual pixel dimensions of your display settings and bases font loading on that--it doesn't know anything about scaled DPI effects and can't compensate for it. (To confirm, you will also be seeing this effect in REXPaint v1.04, which has the same behavior.) Your screenshot does appear to be showing REXPaint with DPI scaling applied, as it's not pixel-perfect like the original fonts. Without DPI scaling your display will be able to comfortably use larger REXPaint fonts that also look more precise.
Also unifont still isn't on the resources page.It's there, I put it there last week shortly before the official release--you'll find it down at the very bottom, and if you don't currently see it then your browser is probably using a cached version of the page. Use Ctrl-F5 to force reload the page.