#Active Low

21 messages · Page 1 of 1 (latest)

ripe ridge
#

It would be nice if it were possible to mark an input or an output as active low.
This feature would be especially useful when replicating processors like the Z80, where the control bus is active low, making it easier to understand what is happening.
In the image, I have shown how I believe it could look.

example.png
sinful plinth
#

The formating of text might get added at some point,
but the offsetting of pins to accomodate the inversion dot is never going to happen,
because the whole game is grid based & having this as an exception
would look waaaayy out of place.

The closest thing the you may get to that,
would be to get some form of customisation of CC shapes / visuals added.

ripe ridge
#

Oh, right, I forgot that it would be difficult, but I think it would be okay even if the inversion dot overlapped the pin

#

I mean something like this

sinful plinth
#

Honestly, the biggest problem with the inversion dot,
is the fact that a CC I/O pin doesn't have to touch a solid part of it's body at all,
at worst making those dots potentially "float" in between pins.

Like what would you do if the Output pin of this CC,
was ment to be marked with the inversion dot; where would you place it:

CC_example_that_causes_issues_for_the_addition_of_inversion_dots.png
ripe ridge
#

You are right, it would be impossible. So text formating only this is

sinful plinth
#

The only way that I'd see an inversion dot rendered,
would be by making the inverted pin somewhat hollow.
But that would impact the readability/glance-ability of the state of CC I/O, so it wouldn't be ideal.

#

Especially since wires cover the outside perimiter of a pin if they're connected,
this would take away from the center of it, leaving little visible area of a pin
to convey the state it's in as well as being able to tell wether or not there is actually a pin there.

ripe ridge
#

Or you could change the pin color to e.g. purple and abolish inversion dot here.

#

It would be still readable:

sinful plinth
#

I'm unsure if that's a good idea, we already have 5 6 different colors of pins:

  • Pink-ish - normal input pin, all bits of which are 0;
  • Red - normal output pin, all bits of which are 0;
  • Orange-ish yellow - pin that implies that it doesn't impact the values of other pins during the current tick, all bits of which are 0;
  • Green - a pin that has at least one bit that is a 1;
  • Blue - size pin, special type of pin that deal with size wires, which don't carry a value at all,
    instead their sole purpose is to carry a wire size & can be only used to supply the size to any size input pins;
  • Gray / Grey - color of an output pin that was disabled / not enabled,
    like for example on any of the switch components, when the bottom input's lowest bit is a 0 &
    when the whole wire isn't getting powered by anything else.

This pin color meaning list is already a hot mess & we don't need to add even more to it, especially since their color
when at least one bit is a 1 would most likely end up being Green anyway making that color being even more ambiguous.

ripe ridge
#

Yes, it would be a problem

sinful plinth
#

Another issue with using colors for this is color-blindness support.
The game is designed with that in mind you know, it is why there are only
green & blue components in the game and both have different brightnesses to make them unique.

ripe ridge
#

Yes, I forgot about it. So, the only option is text formatting

sinful plinth
#

In fact, look what happens to the input entry "ticks" when you have a level or CC with < 8 bit wide inputs
after you enable the Color blind mode option (they turn purple-ish magenta).

brittle citrus
sinful plinth
#

I just added it in. Oh man, that list is getting very obnoxious (complexity wise).