Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ununsept]

Prepare for a long post. Well, maybe it's not so long since I've hidden the images under spoiler tags.
Some time ago I was playing Cataclysm: Dark Days Ahead a lot. Since it's open source, I decided to contribute to the project. I found out that someone implemented a system where ASCII art can be shown under the description of an item (probably inspired by Cogmind), but only a couple of items had pictures. I figured out it wouldn't be to hard to make some more since CDDA has so many items that I can make ASCII art for almost anything. But there are also some limitations for implementing ASCII art in CDDA: it can't be wider than 41 columns, I'm limited to rectangle font, and color palette is rather limited. It should be noted that I used REXPaint for all pictures, but the fancy text was copied from text to ascii generator and pasted in notepad, I'm not masochistic enough to do it manually in REXPaint. I also added some additional characters in some cases. Anyway, here's what's I made so far (all the screenshots are taken directly from the game):
Chemistry textbook

Spoiler (click to show/hide)

Deputy Badge

Spoiler (click to show/hide)

Electrohack (does what it sounds like - hacks electronic devices. I saw some picture in this thread with the binary thing and I really wanted to do something like that.)

Spoiler (click to show/hide)

First aid kit

Spoiler (click to show/hide)

Lajatang

Spoiler (click to show/hide)

mp3 player

Spoiler (click to show/hide)

pack with cigarettes - I did this only for this joke

Spoiler (click to show/hide)

SD card

Spoiler (click to show/hide)

Big book of first aid

Spoiler (click to show/hide)

Thermometer

Spoiler (click to show/hide)

Umbrella - I think this one came out really nice, I like the colors

Spoiler (click to show/hide)

Wristwatch

Spoiler (click to show/hide)

Halberd

Spoiler (click to show/hide)

I have never dome ASCII art before so the pictures are of varying quality, but I'm generally satisfied with them. One of the most useful features of REXPaint that I didn't notice initially was exporting to BBcode. The way colors are indicated in the game code is similar to BBcode, except < and > are used instead of [ and ], and color names are different. So manually coloring pictures like umbrella (see above) where colors change 7 times per line would be painful. Thankfully if I export to BBcode I can set the colors in a minute using replace option in notepad++. So thanks for this option. Right now I've lost some interest in CDDA so I haven't done anything new in a while, but doing ASCII art seems fun so I might get back to it soon. The CDDA community seems quite enthusiastic about adding ASCII pictures to the descriptions.

[Kyzrati]

Oh nice these are really great! Thanks for sharing, I laughed at the cigarettes

So I guess no one else is actively working on adding art for items, eh?

Will these be added to the main branch, do you think? Or maybe already were? I can imagine the community being interested in this, as you say, which at least can be motivating

And good to hear someone's getting real use out of the BBCode export! I added it just for fun back when I was using forums a lot, but even on forums people would generally just use image exports anyway (more control over the final appearance, after all, rather than leaving it to the forum software and/or browser)

[Ununsept]

These were merged about 2 weeks ago, so they can be already seen on experimental builds. And yes, I'm the only one who's working on ASCII art. There was one guy who added a bunch of items a few months ago but that's it. I guess people have a lot of other work, like fixing game breaking bugs - there's plenty of them after the nested containers update, and there are always great new features planned. On the other hand, ASCII art does look cool so who knows, maybe someone will add more.

[Kyzrati]

Ah cool, I imagine more will get added over time, yeah. Also perhaps if enough people know that you can do it without too much trouble using REXPaint, more might get made? I guess it would help if you also shared a little guide and/or the REXPaint-CDDA palette you've presumably put together to make it easier. Just thoughts on how to get it filled out more quickly

[Ununsept]

I haven't even thought about making a custom palette, I just set colors that are somewhat similar to ones found in the game, but it might be helpful to make a custom palette, it would with visualizing how the picture will look. I mentioned that I used REXPaint in my pull requests, but it's definitely a great idea to put a guide in the documentation. People should know that there's a way to automate the coloring, maybe it's not very useful for simple pictures but for ones with multiple colors it saves you a lot of tedious work. Before I found out I could do it I spent more time putting my art into game than actually making it.

[Kyzrati]

Makes sense, lowering the barrier to entry is important with something like this. Honestly if this would become something that more people might use, or that you intend to do a fair bit more of, I'd be open to adding a dedicated method for exporting the art in CDDA's format, if that would be feasible which it sounds like it is.

And I mentioned a palette since you said the CDDA colors are limited, in which case it often helps to have a dedicated palette, yeah.

[Ununsept]

Thanks for your offer, it's really nice of you! It probably isn't some high priority issue but it would save a few minutes in notepad++. Altough I guess it doesn't make much sense without a custom palette, so I'd have to make it first. 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. Currently I'm using a font with same proportions as unifont and when I want to check how it'll look ingame I export the image to .txt and check it in notepad in unifont. It'd be great to be able to see how it'll look as I draw it.

[Kyzrati]

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.

It gets faster once you've done it before, and even faster if you've set up some kind of workflow and tools for doing it, but in the end it will still take a good amount of tweaking and repetitive work

*(via some other software--I use Photoshop but other people have their own tools that they're familiar with)

[Ununsept]

That seems like a lot of work, maybe I'll do it in the future (but definitely far future). Anyway, in case you want to implement exporting to format readable by CDDA, here's how color tags work: https://github.com/CleverRaven/Cataclysm-DDA/blob/master/doc/JSON_INFO.md#ascii_arts
And here are the color names: https://github.com/CleverRaven/Cataclysm-DDA/blob/master/doc/COLOR.md
So exactly like BBcode, but with different brackets and color names instead of hex values. I don't know if you'll need it but I attached a color palette with these colors.

[Kyzrati]

I see, so it's basically a standard set of terminal colors.

Seems like one of the complications that make it less straightforward is the ability to also use background colors which are combined into the same string name. Easy enough, though I don't recall seeing any examples in your art in particular.

Some conflicts/questions:

- The sample you linked for ASCII art uses "color_" as a prefix, but the format specification only lists "c_" as a valid prefix, not "color_"
- Technically CDDA art can specify the "i_" and "h_" prefixes, although I guess REXPaint can't do that (not sure what they really do in game, either--why invert the foreground and background color like that? is there some other meaning? the specification just says "special rules will be applied")
- It seems implied but not explicitly stated that perhaps any time a background color is not specified, that color will be black, eh?

Anyway, could probably do this, just most importantly need to know what the proper color prefix is. That said, the specification even says the prefix isn't even necessary, which would be nice for reducing file size--so can that just be ignored entirely? For example the sample art could really just be:

Code: [Select]

    "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>╚═══════════════════╝"
    ]


[Ununsept]

I tried applying different prefixes to ASCII art color tags, but apparently only <color_colorname> works. 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. 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. It makes the file look a bit messed up because there are tons of unnecessary color tags. And the last step in automation of the export process would be wrapping the lines in " at the beginning and ", at the end. 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. They can be easily added in REXpaint but then they are treated as a part of the image and will be colored. They could be applied automatically before and after each line. ", could also be applied at the point in line where there's nothing but spaces after it and then the spaces would be deleted, but that would probably take more work and 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. The last line should be without comma at the end, but that would again require a solution with detecting empty space or user resizing the canvas. Honestly it doesn't matter that much, the user could just delete the comma manually. Also I realized the example is kinda misleading, the color tags don't have to be applied every line if the color doesn't change. It could look like this:

Code: [Select]

"",
      "",
      "",
      "       <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 ║",
      "       ╚═══════════════════╝"

[Ununsept]

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.

[Kyzrati]

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.

Ah okay, I'll remove that, thanks.Edit: Hm, no wait, I think it'll stay that way because it makes the exporting code a ton more complex to have to also consider characters in the midst of its color RLE algorithm xD

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.

[Kyzrati]

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.

Some artists can do really nice things with background colors, and depending on how use them they can be very useful. (I have indeed mentioned before in my art guide that I generally avoid them for the type of line art that I do, but they definitely come in handy sometimes, and would even more so for the huge variety of art needed in CDDA.)

Would be a good idea to let them know about this issue, since I'll be including C:DDA export support in the next official release of REXPaint (soon!), and this could potentially attract more interest in creating art for it (or it could be the impetus for doing so ), since I'll be announcing that around.

[Ununsept]

I just did more extensive testing regarding the background colors and I've found out a few things:
1. Some color combinations work fine except for line length errors in some cases.
2. Some color combinations don't seem to exist? Apparently if color pair doesn't exist in https://github.com/CleverRaven/Cataclysm-DDA/blob/master/src/color.cpp, it can't be used.
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).
I'm gonna do some more testing and then submit an issue on GitHub and hopefully someone will work on it. For now the option to export background colors can just sit there and wait until something changes.
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!

[Kyzrati]

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...

I guess it can be assumed background colors should behave as foreground colors do, wrapping to new lines etc? And although people just can't use them via REXPaint yet, the feature will be available once it's ready.

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'm about done with this feature, but went out to dinner so hadn't gotten to the testing part yet. Was going to get you a build to test, too, to see if it's good enough to include in v1.50 proper. (I'm not set up to test it within CDDA itself, and can only base things on the specifications and examples I've seen so far.)

[Ununsept]

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.
Make sure to send me a test build, I'll gladly test it when I'll have time.

[Kyzrati]

I've sent you a test version of the current state via PM.

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 :/

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. Also empty lines actually include all their spaces rather than the shorthand method. In any case, let me know how the current approach works out for you!

[Ununsept]

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 :/
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.

I'm not sure what you mean exactly, are you asking if for example in this case

Code: [Select]

"<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).
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.
Other issue related to background colors is that if I set a background color with space glyph, it will be exported as if every space until next color change had that background color. As a workaround it's possible to use the █ glyph instead, which has exactly the same visual effect.
I noticed I've made a mistake in the color palette with light_cyan color, I've attached a fixed version (the manual should be updated to include that).
Maybe it's nitpicking but it should be made clear in the manual that ASCII art for CDDA doesn't have to be exactly 41 columns long, it simply can't be longer.
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. It's not a problem for square font users because they can just change the font to a smaller one, but with rectangle fonts proportions are different, so art will look different. I wouldn't even write about that if it wasn't for the fact that instead of appearing exactly on top of your screen and "cutting out" the bottom part which doesn't contain anything extremely important if you don't care about layers, a bit of the top part is cut out too, preventing you from browsing images (which is rather important). So it would be cool if the program window had its top exactly at the top of user's screen. Not like there's not a workaround (at least it works this way on windows 10, idk about other systems): you have to shift-RMB on the REXPaint icon on the taskbar, click "move", then press down arrow key on your keyboard until the top of the window is visible. You may be wondering why I don't consider selecting images at the bottom of the browsing list important? Because I've got another workaround for that. Simply make a bunch of empty images and name them "zzz1", zzz2" etc. until they fill the bottom of your image list.

[Ununsept]

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.

[Kyzrati]

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.
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.

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

(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???

I.e. can you force a black background in art? Ideally this should actually be possible for ANSI art that might appear on a different background, since the visual effect can be significantly different. And which way it's handled makes a difference for the implementation... That said, considering CDDA is using a 16-color terminal, it's likely enforcing black or whatever color replaces black as the default background no matter what, regardless of what that might do to an image. So I guess it's safe to assume that's the case.

Honestly the color encoding for CDDA seems rather weird. Back to the example you provided:

Code: [Select]

"<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.

Code: [Select]

"<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.

[Kyzrati]

Updated the build with new export behavior, same link I sent before.

[Ununsept]

Yes, the game "forgets" the colors from previous color tags once you enter a new one, so you have to define foreground and background color (if any) in every color tag. Also regarding the background color if unspecified: if you change your black color to something else (cyan in this example), this is how it looks like:

So the spaces whose color was specifically set to black changed their background color (note how the ones at the beginning don't because their color is unset), but everything else has the "true" black background. So changing black color only affects things that have their color set to black.
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.
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.

[Ununsept]

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.

[Kyzrati]

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

What if just every instance of "<color_black> ... </color>" is just removed from the file. Does it work then? And in that case do we even need to care if it's spaces or another character? Like, literally just removing every one of those pairs would be okay?

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.