Hi everyone,
While trying to make things with varvara, a limitation I keep running
into is the inability to draw colour 0 _and_ transparency at the same
time when using the sprite port. Blend modes 0, 1, 2, 3, 4, 8 and c
will output opaque colour 0 for various inputs; blend modes 5, a and f
will turn input colour 0 into transparency; but there’s no blend mode
that has both colour 0 in the output and transparency. The only way to
get colour 0 without overwriting other stuff in an 8×8 square is to use
the pixel port, which isn’t as efficient or convenient.
At the same time, blend mode 0 has always been a mystery to me. I guess
drawing a single-colour opaque square is useful sometimes, but why
dedicate a special blend mode to it when you could just spend 8 bytes
of your ROM on some zeroes and use blend mode 1? You might already have
such a string of zeros somewhere already.
So, I know it’d break compatibility, but… would it be okay if blend
mode 0 was changed to a mode which makes some input colour be
transparent, and some input colour be colour 0? For this to work well
with 1-bit sprites, it would have to be 0 => transparent and 1 => 0. If
it follows the pattern of the other blend modes, then I guess the
remaining mappings might be 2 => 1 and 3 => 2? I’m not sure how it’d
work in the formula. I think it’d be very useful.
As an aside, I’ve always struggled to understand the formula for the
blending modes on https://wiki.xxiivv.com/site/varvara.html — what do
the labelled variables mean, and is transparency even accounted for at
all?
Regards,
hikari_no_yume
Oh um, was this the right list to send this to? I’ve seen some other
uxn discussion on this list, but the description on
https://lists.sr.ht/~rabbits/uxn suggests it might not really be
intended for it.
Hi again,
> At the same time, blend mode 0 has always been a mystery to me. I guess > drawing a single-colour opaque square is useful sometimes, but why > dedicate a special blend mode to it when you could just spend 8 bytes > of your ROM on some zeroes and use blend mode 1? You might already have > such a string of zeros somewhere already.> > So, I know it’d break compatibility, but… would it be okay if blend > mode 0 was changed to a mode which makes some input colour be > transparent, and some input colour be colour 0? For this to work well > with 1-bit sprites, it would have to be 0 => transparent and 1 => 0. If > it follows the pattern of the other blend modes, then I guess the > remaining mappings might be 2 => 1 and 3 => 2? I’m not sure how it’d > work in the formula. I think it’d be very useful.
I realised just now that if you’re only interested in opaque 1-bit
sprites, you can work out the blend mode you need for any pair of
differing colours by using (color0 | (color1 << 2)), like:
color0 | color1 | mode
----------------------
0 | 1 | 1
0 | 2 | 2
0 | 3 | 3
1 | 0 | 4
1 | 2 | 6
1 | 3 | 7
2 | 0 | 8
2 | 1 | 9
2 | 3 | b
3 | 0 | c
3 | 1 | d
3 | 2 | e
This is really convenient and intuitive! I assume it’s intentional. :)
Then I noticed that the transparent modes are when color0 and color1
would have been the same. Instead of wasting encoding space on a solid
color mode, it makes gives you transparency instead:
• mode 5 would be 1 and 1, instead it’s transparent and 1
• mode a would be 2 and 2, instead it’s transparent and 2
• mode f would be 2 and 3, instead it’s transparent and 3
But there’s a weird exception: if it followed this pattern, I’d expect
mode 0 to be transparent and 0, but instead it’s 0 and 0!
If mode 0 was changed to match the proposal in my earlier message, it
*would* fit the pattern, on the other hand. It’s almost as if mode 0’s
current behaviour is an accident or some kind of mistake?
I hope this was comprehensible :p
Sorry, I really need to be more careful about proofreading :(
> I realised just now that if you’re only interested in opaque 1-bit > sprites, you can work out the blend mode you need for any pair of > differing colours by using (color0 | (color1 << 2)), like:
This should be ((color0 << 2) | color1).
> • mode f would be 2 and 3, instead it’s transparent and 3
This should have said “3 and 3”.
Hi Hikari,
It's a good proposal, I return thinking about this myself from time to time.
If we were to change this, we'd only need to do a bit of shimming for
portability, by setting a full tile:
;empty-icn .Screen/addr DEO2
#00 .Screen/color DEO BRK
@empty-icn ff ff ff ff ff ff ff ff
One thing that I've been considering as the main advantage for this,
is to be able to erase parts of a drawing. Sometimes I want to paint a
drawing, and erase a specific selection of it, and this would allow
that. Say, like adding rounded corners to a rectangle by erasing the
edges with an arc sprite.
I'd be willing to port all the applications to support that, if you
need this badly. So far I've been able to work around this limitation,
but there are some cases where it's really tricky.
I tend to colorize my applications following this pattern where the
outlines are using color2, and the lightest fills color3, maybe this
can help you.
Let me know, I'll go over to see which applications are affected by the change.
On 7/22/23, 光の夢 <hikari@noyu.me> wrote:
> Sorry, I really need to be more careful about proofreading :(>>> I realised just now that if you’re only interested in opaque 1-bit>> sprites, you can work out the blend mode you need for any pair of>> differing colours by using (color0 | (color1 << 2)), like:>> This should be ((color0 << 2) | color1).>>> • mode f would be 2 and 3, instead it’s transparent and 3>> This should have said “3 and 3”.>
Hundred Rabbits:
> It's a good proposal, I return thinking about this myself from time to time.> If we were to change this, we'd only need to do a bit of shimming for> portability...
This would be pretty cool. I have been thinking about this a lot for
what I'm working on. My workaround was to write a function to blit a
1-bit sprite in colour 0. You can see what I was trying to do here:
https://mastodon.scot/@nettles/110754934886034943
(Link is to a Mastodon thread with a short video of a low resolution
pixel art game, in the style of the early Legend of Zelda games. A
little red haired elf girl in green clothes wanders around an area with
green bushes and grass and orange stones and rocks. There are only four
colours - light cream for the ground and her skin, bright orange for her
hair and the rocks, a deep for her clothes, the grass and the bushes,
and a dark blue for the shadows. She walks over the stones and grass,
demonstrating that a) she has transparency and isn't drawn as an opaque
square, and b) her face, although the same colour as the ground, isn't
transparent - she has a full four colours. The thread goes on to explain
how I managed to code it and has a link to a gist with the code.)
I am pretty certain there was no way to achieve this without drawing the
colour 0 parts pixel by pixel. As you can see from the mixed colours in
the background, I can't get by with just three foreground colours. I'm
very happy with the result, but it would save a lot of code if hikari's
proposal were accepted and blending mode 0 caused a 1-bit sprite to
render as transparent and colour 0.
I have some broader frustrations with the blending modes, but I think
there's probably no elegant solution. I feel like the most common
scenario I'd want to paint the same sprites with more than one different
palette, is when I want:
1. to use a consistent palette index as transparent, and
2. to swap two of the other colours.
E.g. suppose I want to distinguish two teams of players, I might have a
palette of red, blue, white and black. I'd want to draw one team
red/white/black and the other team blue/white/black. There's no way to
do that with one set of sprites because the only blend modes that have
transparency rotate the colours rather than swap any of them. But in
practice, rotating colours seems to produce unhelpful results if the
artwork uses light and shadow, because rotation necessarily reshuffles
which parts are brightest and darkest.
I don't think there's really anything to be done about it at the varvara
level, unlike the proposal for blend mode 0. But I am interested to know
how others tackle the problem, and I'm also just kind of curious about
the design behind the blending nibble, since it feels quite alien, more
of a puzzle than a tool. I wonder what kinds of thing it does work well
for.
Annette (she/her)
So, full disclosure, it was Annette’s struggles that prompted me to
finally mail the list about this, but I had hit this problem before.
In oneko-uxn for example, both the cat and the mouse sprites are
actually two 1-bit sprites each: one is the background of the
cat/mouse, and one provides an outline. Initially I only supported
black and white, but already in that version I found myself having to
use *three* colours in the palette, because I couldn’t use white
(colour 0) to mask white (colour 0)… so I made a second white (colour
2). If I’d wanted to have the mouse’s colours be completely different
from the cat’s colours, I would have had to resort to the pixel byte,
like Anette did, but luckily I only need two or three.
Mostly it’s just frustrating because it stops you making full use of
all four colours in some scenarios involving sprites. For boxy things
like UI elements, it’s no big deal, but in a game or something like
that, every colour is precious. You have to be careful with which
colour 0 you pick regardless, but it’d be nice to have one less thing
to worry about.
The blending nibble was designed to handle applications like left, orca and oquonie. Actually, all of Varvara was designed around hosting these 3 projects.
The blending nibble makes more sense if you’re think about it in terms of highlighting text for example. We had to do a project once where we had teams like you described and had to paint the team colour in a second draw which was annoying. The blending for 2-bit graphics is pretty bad, maybe it could be changed somehow but we haven’t had much success hitting the right balance, or at least not causing as many issues that it was solving.
We’re open to changing the strategy. There might also be something to look into like proper bliting. Like image that beside the pixel and sprite port, there was a screen/blit port, that takes a cmd and the address is to a bliting program. The port would be a sort of xor, and, etc blending, the bliting program in memory could do at once filling a large portion of the screen with some logic defined in the program. Not unlike the expansion port.
Rek
> On Jul 22, 2023, at 10:36 AM, Annette Wilson <clockworksaint@gmail.com> wrote:> > Hundred Rabbits:>> It's a good proposal, I return thinking about this myself from time to time.>> If we were to change this, we'd only need to do a bit of shimming for>> portability...> > This would be pretty cool. I have been thinking about this a lot for> what I'm working on. My workaround was to write a function to blit a> 1-bit sprite in colour 0. You can see what I was trying to do here:> > https://mastodon.scot/@nettles/110754934886034943> > (Link is to a Mastodon thread with a short video of a low resolution> pixel art game, in the style of the early Legend of Zelda games. A> little red haired elf girl in green clothes wanders around an area with> green bushes and grass and orange stones and rocks. There are only four> colours - light cream for the ground and her skin, bright orange for her> hair and the rocks, a deep for her clothes, the grass and the bushes,> and a dark blue for the shadows. She walks over the stones and grass,> demonstrating that a) she has transparency and isn't drawn as an opaque> square, and b) her face, although the same colour as the ground, isn't> transparent - she has a full four colours. The thread goes on to explain> how I managed to code it and has a link to a gist with the code.)> > I am pretty certain there was no way to achieve this without drawing the> colour 0 parts pixel by pixel. As you can see from the mixed colours in> the background, I can't get by with just three foreground colours. I'm> very happy with the result, but it would save a lot of code if hikari's> proposal were accepted and blending mode 0 caused a 1-bit sprite to> render as transparent and colour 0.> > I have some broader frustrations with the blending modes, but I think> there's probably no elegant solution. I feel like the most common> scenario I'd want to paint the same sprites with more than one different> palette, is when I want:> > 1. to use a consistent palette index as transparent, and> 2. to swap two of the other colours.> > E.g. suppose I want to distinguish two teams of players, I might have a> palette of red, blue, white and black. I'd want to draw one team> red/white/black and the other team blue/white/black. There's no way to> do that with one set of sprites because the only blend modes that have> transparency rotate the colours rather than swap any of them. But in> practice, rotating colours seems to produce unhelpful results if the> artwork uses light and shadow, because rotation necessarily reshuffles> which parts are brightest and darkest.> > I don't think there's really anything to be done about it at the varvara> level, unlike the proposal for blend mode 0. But I am interested to know> how others tackle the problem, and I'm also just kind of curious about> the design behind the blending nibble, since it feels quite alien, more> of a puzzle than a tool. I wonder what kinds of thing it does work well> for.> > Annette (she/her)
Oh uh, one more thing: is the illustration of blend mode 0 on
https://wiki.xxiivv.com/site/varvara.html even accurate? There’s no
image for it in the table, which I guess is meant to be equivalent to a
pure white image, i.e. for all inputs, the output should be an opaque
colour-0 square. But, so far as I can tell from the formula, while
input values 0 and 1 are both mapped to 0, inputs 2 and 3 should be
mapped to 1 and 2 respectively? That is also the behaviour I got when I
tested it in uxnemu with this program:
|00 @System $8 &r $2 &g $2 &b $2
|20 @Screen $c &addr $2 &pixel $1 &sprite $1
|0100
#f07f .System/r DEO2 #f0e0 .System/g DEO2 #f0c0 .System/b DEO2
#83 .Screen/pixel DEO ( fill bg with colour 2 )
;sprite .Screen/addr DEO2
#80 .Screen/sprite DEO ( draw 2-bit sprite with mode 0 )
BRK
@sprite
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
So to accurately describe the current behaviour, I think there should
be an image that looks like the one for mode 4, 8 or c, but with white
as the background colour? Of course, I want to change the behaviour so
the background is transparent.
Ah yes! It should be one of those cyan, black and white circles. Have a look at devices/screen.tal to see the sprite that should be there.
Rek
> On Jul 22, 2023, at 12:19 PM, 光の夢 <hikari@noyu.me> wrote:> > Oh uh, one more thing: is the illustration of blend mode 0 on > https://wiki.xxiivv.com/site/varvara.html even accurate? There’s no > image for it in the table, which I guess is meant to be equivalent to a > pure white image, i.e. for all inputs, the output should be an opaque > colour-0 square. But, so far as I can tell from the formula, while > input values 0 and 1 are both mapped to 0, inputs 2 and 3 should be > mapped to 1 and 2 respectively? That is also the behaviour I got when I > tested it in uxnemu with this program:> > |00 @System $8 &r $2 &g $2 &b $2> |20 @Screen $c &addr $2 &pixel $1 &sprite $1> |0100> #f07f .System/r DEO2 #f0e0 .System/g DEO2 #f0c0 .System/b DEO2> #83 .Screen/pixel DEO ( fill bg with colour 2 )> ;sprite .Screen/addr DEO2> #80 .Screen/sprite DEO ( draw 2-bit sprite with mode 0 )> BRK> @sprite> 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10> > So to accurately describe the current behaviour, I think there should > be an image that looks like the one for mode 4, 8 or c, but with white > as the background colour? Of course, I want to change the behaviour so > the background is transparent.
We’ve been toying with a partial clear on 0x00 colour today. It seems like it wouldn’t be too bad a change to port.
I think it might only be a matter to change line 53 on screen.c and remove !color. Try it out if you like, see if that’s something that helps :)
Rek
> On Jul 22, 2023, at 12:19 PM, 光の夢 <hikari@noyu.me> wrote:> > Oh uh, one more thing: is the illustration of blend mode 0 on > https://wiki.xxiivv.com/site/varvara.html even accurate? There’s no > image for it in the table, which I guess is meant to be equivalent to a > pure white image, i.e. for all inputs, the output should be an opaque > colour-0 square. But, so far as I can tell from the formula, while > input values 0 and 1 are both mapped to 0, inputs 2 and 3 should be > mapped to 1 and 2 respectively? That is also the behaviour I got when I > tested it in uxnemu with this program:> > |00 @System $8 &r $2 &g $2 &b $2> |20 @Screen $c &addr $2 &pixel $1 &sprite $1> |0100> #f07f .System/r DEO2 #f0e0 .System/g DEO2 #f0c0 .System/b DEO2> #83 .Screen/pixel DEO ( fill bg with colour 2 )> ;sprite .Screen/addr DEO2> #80 .Screen/sprite DEO ( draw 2-bit sprite with mode 0 )> BRK> @sprite> 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10> > So to accurately describe the current behaviour, I think there should > be an image that looks like the one for mode 4, 8 or c, but with white > as the background colour? Of course, I want to change the behaviour so > the background is transparent.
> Ah yes! It should be one of those cyan, black and white circles. Have a look at devices/screen.tal to see the sprite that should be there.> > Rek> >> On Jul 22, 2023, at 12:19 PM, 光の夢 <hikari@noyu.me> wrote:>> >> Oh uh, one more thing: is the illustration of blend mode 0 on >> https://wiki.xxiivv.com/site/varvara.html even accurate?
Ah, thanks for the pointer! I assume you were referring to this
file?[0] I looked at that now, but I was a bit overwhelmed by the
output and couldn’t immediately see how it related to the familiar
table from the varvara page. So instead I wrote my own blending modes
test (source below) that tries to match that table almost exactly, to
make comparisons easy. As expected, it matches all the images on that
page, except for blend mode 0. And on that note…
> I think it might only be a matter to change line 53 on screen.c and remove !color. Try it out if you like, see if that’s something that helps :)
I tried this out with my blending test program, and indeed, changing
the `|| !color` from the definition of `opaque` produces the result I
want, without affecting any of the other blend modes.
Thanks!
----
[0] https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/examples/devices/screen.tal
----
( varvara sprite blend modes test by hikari_no_yume, 2023-07-23 )
( SPDX-License-Identifier: MIT )
|00 @System $8 &r $2 &g $2 &b $2
|20 @Screen $2 &w $2 &h $2 $2 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1
|0100
#f07f .System/r DEO2 #f0e0 .System/g DEO2 #f0c0 .System/b DEO2
#0080 .Screen/w DEO2 #0080 .Screen/h DEO2
#80 .Screen/pixel DEO ( fill bg with colour 0 )
#00
@circles_loop
DUP draw_circles
INC DUP #10 LTH ?circles_loop
BRK
@draw_circles ( blend_mode )
#00 OVR #03 AND #50 SFT2 .Screen/y DEO2
#00 OVR #52 SFT2 .Screen/x DEO2
#00 OVR #30 SFT ;5X5_DIGIT_FONT ADD2 .Screen/addr DEO2
#01 .Screen/sprite DEO
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO
;CIRCLES .Screen/addr DEO2 #90 ORA DUP .Screen/sprite DEO
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO
;CIRCLES .Screen/addr DEO2 #10 EOR DUP .Screen/sprite DEO
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO
;CIRCLES .Screen/addr DEO2 #20 ORA DUP .Screen/sprite DEO
.Screen/x DEI2 #0008 SUB2 .Screen/x DEO2
;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO
;CIRCLES .Screen/addr DEO2 #10 EOR .Screen/sprite DEO
JMP2r
@CIRCLES
e0 f8 1c 0e c6 e3 f3 f3 00 00 e0 f0 f8 fc fc fc
@CHECKERS
aa 55 aa 55 aa 55 aa 55 aa 55
@5X5_DIGIT_FONT
( my 5x5 hex digit font, reused from hexdream.tal )
70 88 88 88 70 00 00 00
20 20 20 20 20 00 00 00
f0 08 70 80 f8 00 00 00
f0 08 78 08 f0 00 00 00
88 88 f8 08 08 00 00 00
f8 80 f0 08 f0 00 00 00
70 80 f0 88 70 00 00 00
f8 08 10 20 20 00 00 00
70 88 70 88 70 00 00 00
70 88 78 08 70 00 00 00
70 88 f8 88 88 00 00 00
f0 88 f0 88 f0 00 00 00
78 80 80 80 78 00 00 00
f0 88 88 88 f0 00 00 00
f8 80 f0 80 f8 00 00 00
f8 80 f0 80 80 00 00 00
I've had the time to check most of the 100r roms, and it doesn't
really break compability, there's some cursor drawing artifacts that I
can easily fix, but otherwise, if you think that it'll benefit your
projects, I'm willing to push this change to the repo, and update the
docs.
It'll take me a day or so to patch up the little drawing issues.
On 7/23/23, 光の夢 <hikari@noyu.me> wrote:
>> Ah yes! It should be one of those cyan, black and white circles. Have a>> look at devices/screen.tal to see the sprite that should be there.>>>> Rek>>>>> On Jul 22, 2023, at 12:19 PM, 光の夢 <hikari@noyu.me> wrote:>>>>>> Oh uh, one more thing: is the illustration of blend mode 0 on>>> https://wiki.xxiivv.com/site/varvara.html even accurate?>> Ah, thanks for the pointer! I assume you were referring to this> file?[0] I looked at that now, but I was a bit overwhelmed by the> output and couldn’t immediately see how it related to the familiar> table from the varvara page. So instead I wrote my own blending modes> test (source below) that tries to match that table almost exactly, to> make comparisons easy. As expected, it matches all the images on that> page, except for blend mode 0. And on that note…>>> I think it might only be a matter to change line 53 on screen.c and remove>> !color. Try it out if you like, see if that’s something that helps :)>>> I tried this out with my blending test program, and indeed, changing> the `|| !color` from the definition of `opaque` produces the result I> want, without affecting any of the other blend modes.>> Thanks!>> ---->> [0]> https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/examples/devices/screen.tal>> ---->> ( varvara sprite blend modes test by hikari_no_yume, 2023-07-23 )> ( SPDX-License-Identifier: MIT )>> |00 @System $8 &r $2 &g $2 &b $2> |20 @Screen $2 &w $2 &h $2 $2 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1> |0100> #f07f .System/r DEO2 #f0e0 .System/g DEO2 #f0c0 .System/b DEO2> #0080 .Screen/w DEO2 #0080 .Screen/h DEO2> #80 .Screen/pixel DEO ( fill bg with colour 0 )> #00> @circles_loop> DUP draw_circles> INC DUP #10 LTH ?circles_loop> BRK>> @draw_circles ( blend_mode )> #00 OVR #03 AND #50 SFT2 .Screen/y DEO2> #00 OVR #52 SFT2 .Screen/x DEO2> #00 OVR #30 SFT ;5X5_DIGIT_FONT ADD2 .Screen/addr DEO2> #01 .Screen/sprite DEO> .Screen/x DEI2 #0008 ADD2 .Screen/x DEO2> ;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO> ;CIRCLES .Screen/addr DEO2 #90 ORA DUP .Screen/sprite DEO> .Screen/x DEI2 #0008 ADD2 .Screen/x DEO2> ;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO> ;CIRCLES .Screen/addr DEO2 #10 EOR DUP .Screen/sprite DEO> .Screen/y DEI2 #0008 ADD2 .Screen/y DEO2> ;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO> ;CIRCLES .Screen/addr DEO2 #20 ORA DUP .Screen/sprite DEO> .Screen/x DEI2 #0008 SUB2 .Screen/x DEO2> ;CHECKERS .Screen/addr DEO2 #01 .Screen/sprite DEO> ;CIRCLES .Screen/addr DEO2 #10 EOR .Screen/sprite DEO> JMP2r>> @CIRCLES> e0 f8 1c 0e c6 e3 f3 f3 00 00 e0 f0 f8 fc fc fc>> @CHECKERS> aa 55 aa 55 aa 55 aa 55 aa 55>> @5X5_DIGIT_FONT> ( my 5x5 hex digit font, reused from hexdream.tal )> 70 88 88 88 70 00 00 00> 20 20 20 20 20 00 00 00> f0 08 70 80 f8 00 00 00> f0 08 78 08 f0 00 00 00> 88 88 f8 08 08 00 00 00> f8 80 f0 08 f0 00 00 00> 70 80 f0 88 70 00 00 00> f8 08 10 20 20 00 00 00> 70 88 70 88 70 00 00 00> 70 88 78 08 70 00 00 00> 70 88 f8 88 88 00 00 00> f0 88 f0 88 f0 00 00 00> 78 80 80 80 78 00 00 00> f0 88 88 88 f0 00 00 00> f8 80 f0 80 f8 00 00 00> f8 80 f0 80 80 00 00 00>>