Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

LED colors: Do you want to have both states (on/off) configurable (e.g. on = green, off = red) or just one color with different brightness will be enough (e.g. like it's implement now, on = light green, off = dark green)?

T-Junctions: Yes it's only an editing thing. To be honest, a couple of other users suggested that you should be able to start a wire from an input pin. It's already in my TODO list but I've categorized it as not important so it's a bit low on priority :) Hope it's not much of a hassle until it's "fixed".

RAM: As far as I can tell, the RAM described in the page you linked is async. One Write input which works as a clock signal (whenever a rising/falling edge is detected, data is written to the RAM). Problem with implementing just this version is that if you want to implement anything more sophisticated on top of it (e.g. synchronous pipelined SRAM with burst reads/writes), you'd have to build a component and you'll loose the ability to inspect the RAM's contents (once a RAM is inside a component you don't have access to it from the master schematic). That's why I'm thinking whether it'll be good to implement extra (configurable) features for it or not.

16-bit limit: Unfortunately, the way the simulator is implemented (how signals are stored and moved around and how special values such as Undefined and Error have been implemented) doesn't allow for a larger signal width at the moment. It bugs me too and it's on my list of thins to "fix", but since it's still early in development and it's supposed to be a game at some point, 16-bits should be enough for now.

Would love to see what you manage to build with DLS :)

In case of LED color I was thinking about something else - like it is implemented but with option to set LED color (green, red, blue, etc.). So before you place LED component you can select it color and then in circuit for e.g. it is dark red or green or whatever color you can pick and when on light red, green, etc. Something like standard LED.

There is a little bug - when you place buttons in a column label from other button is overlay button and it is hard to click on a button because it will open edit label dialog, maybe label should be on the left side of button?

OK about the LEDs.

Regarding the push buttons (and any other I/O port in general). This isn't actually a bug. It's by design. In order to avoid something like that, please arrange the buttons in reverse order. All ports are rendered in the same order they are created.So by reversing their order, you can hide their label behind the newer port.

Putting the label on the left side of the button will not look good in case the button has a large name. Sorry about that :)