Print

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

[mifki]

But once there's real transparency, how do we distinguish what pixels are transparent and what should show background colour?

Easy. Pure black is background and pure magenta is transparency. This could have a lot of applications, like letting you change the background color of a barrel based on what liquid is in it while still having transparency:



The only downside is that you cannot have alpha blending for the background color. But it's a worthy tradeoff since you'll have your barrel sitting on a nice floor tile or grass tile.

And also you can't use this colours if you need them in the actual image (especially black). But wait, there's still the alpha channel and it's not used at all your proposal. So maybe transparent pixels for transparency and magenta for bg colour?

Also, do tell. My current method of overwriting plants is changing them in the raws and then creating new overrides to reflect that. I'd be interested to see what you have in mind.

Isn't this very limited because you can't specify tile numbers >255 in raws, so you won't be able to use different images for different plants? I was thinking I could make use of the colours that are specified for growth/plant tiles as well in raws to expand the tile number range. It becomes more difficult to configure so just in case people really want different tiles for different plants.

[Meph]

Please use transparent pixels instead of magenta. Because if you use magenta it's like an on/off switch, while transparent pixels can have a gradient and allow shading.

For example you make a bucket, background of the bucket is transparent, but slightly darker where the shadow of the bucket falls.

[DragonDePlatino]

And also you can't use this colours if you need them in the actual image (especially black). But wait, there's still the alpha channel and it's not used at all your proposal. So maybe transparent pixels for transparency and magenta for bg colour?

That would work just fine too. The reason I suggested pure black (#000000) is because many pixel artists avoid that color. It is discouraged because it looks much better if you use other colors. So...how about magenta for the background and transparency for the transparency? I think that would fix the problem Meph is describing.



That, or we could just ditch the background color entirely like you said.

Isn't this very limited because you can't specify tile numbers >255 in raws, so you won't be able to use different images for different plants? I was thinking I could make use of the colours that are specified for growth/plant tiles as well in raws to expand the tile number range. It becomes more difficult to configure so just in case people really want different tiles for different plants.

Let's see here.....Yup. There are about 455 instances of [GROWTH:PRINT] in the vanilla raws, so it would be impossible to fit everything in one tileset. Another idea would be to have a new set of overrides. You could specify a plant override like this:

[OVERRIDE:P:Plant:Subtype:Tileset:NewTile]

Plant would be something like ARTICHOKE and the subtypes would be the growths (in order). If you want to override a growth on the plant, you would just give a number. If you wanted to override a picked growth, you would add 100 to that number. So to override the picked flowers of an artichoke, you would try:

[OVERRIDE:P:ARTICHOKE:102:Tileset:NewTile]

If you leave the Subtype parameter blank it would override the [PICKED_TILE], how the plant looks if there are no visible growths on it.

[mifki]

And also you can't use this colours if you need them in the actual image (especially black). But wait, there's still the alpha channel and it's not used at all your proposal. So maybe transparent pixels for transparency and magenta for bg colour?

That would work just fine too. The reason I suggested pure black (#000000) is because many pixel artists avoid that color. It is discouraged because it looks much better if you use other colors. So...how about magenta for the background and transparency for the transparency? I think that would fix the problem Meph is describing. That, or we could just ditch the background color entirely like you said.

Ok, I'll try to make a test implementation of this, add transparency to some tileset (Spacefox since I use it myself) and we'll see how it looks.

[Dirst]

Using either superblack or magenta for transparency is a hack to approximate an alpha channel and they both suffer from the same on/off nature.

Right now, is the fg color mixed into the whole image, or just in areas where the red, green and blue values are equal (ie, grayscale)?  If the fg is mixed into everything, it may be necessary to ditch bg colors entirely or use a completely different tile set as a mask.  If the fg is just mapped into x:x:x pixels, then the background can be mapped into x:0:x pixels.  An artist who wants to use purple just needs to include at least a smidge of green in it.

[Dirst]

One completely over-engineered solution would be to stack overrides, each one with an alpha channel, and each one with a declared color source (foreground, background, profession, as-is).

[mifki]

One completely over-engineered solution would be to stack overrides, each one with an alpha channel, and each one with a declared color source (foreground, background, profession, as-is).

The question is, do we really need both background and foreground colours? They were useful when we had 16 colours only and limited number of tiles, so we could employ tile magic to use the same tile for different objects/materials and so on. But now that we can have as many tiles and colours as we want (and use different tiles for different "material types" like constructed wall/soil wall/stone wall/...), maybe one colour will suffice?

On the other hand, the configuration is getting too complicated now anyway (look at the number of overrides in the new GemSet). So I'm thinking about a GUI where you could easily assign images to all available game features with preview, not caring about whether it will internally be tiletype override, item/building override, or will require changing tile numbers in raws. In this case, it could have a way to assign several images and stack them as you're suggesting. It would be not as terrible as if you had to configure such stacks in config files, that's what I'm saying.

[DragonDePlatino]

The question is, do we really need both background and foreground colours?

I vote to remove the background colors and simplify things for artists. Like you said, background colors are only useful from an ASCII perspective because they let you include more information in a tile. With SDL graphics and multi-colored tiles, background colors are not needed. I never used them, and sometimes disabled them entirely to make things visually cleaner (e.g. GemSet's rails). If anything, they keep graphics from being WYSIWYG and introduce more technical hurdles for artists (Huh, I drew a barrel but it's invisible in-game?!?)

Also, I think a GUI would be great. Have a little program for artists that lets them organize all of their graphics and see what they have drawn at a glance. There could be a file menu on the left and a bunch of image previews on the right. You know, like the BYOND Dream Editor. I don't even care if each image only has a single tile. It would be much simpler than the current system we have.

[Antsan]

Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?

I'm not an artist or anything, I've just wondered since this discussion started.

[scamtank]

This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.

It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?

[Meph]

Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?

I'm not an artist or anything, I've just wondered since this discussion started.

Yes, that would happen.

[DragonDePlatino]

Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?

I'm not an artist or anything, I've just wondered since this discussion started.

Yes, but if transparency were added to sprites right after background colors were removed, it would result in little information loss. Take underwater creatures, for example. They have a blue background to communicate that they're in the water, but if they could be overlaid over a water tile with transparency, that would not be an issue.

This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.

It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?

I've never experienced that issue but it sounds like it would be incredibly aggravating. Taking the X from the from the map tileset could be a problem, though, because some TWBT tilesets might use that. It would be nice if the mouse.png could be used for your cursor.

[Button]

Incidentally, mfiki, how fixable do you think the zooming problem would be? Do you know what exactly causes it?

It's keeping me from switching over to GemSet

[Max™]

Which zooming problem do you mean?

I'd love if the one that causes this was gone because I could use the gemset 48 without it happening:

Spoiler (click to show/hide)

[scamtank]

Hahaha, wow. It's like Wolverine slashed up the UI and it's bleeding tiles.