On 12/26/2023 10:17 PM, Dan Purgert wrote:
>> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd,
>> and data in/out to each board? Let boards daisy chain their "out" signal
>> to the neighbor's "in". That way, you can delegate the control of the
>> lamps to each little MCU as well as limiting the amount of "drive"
>> required on each (this would scale better than a single driver board).
>
> "maybe" -- but ultimately the issue is going to be drawing an "area" on
> the (in-game) floor where something happened.
>
> USUALLY this is done either by:
>
> (a) counting squares from the "center" of the effect
> (b) paper/plastic templates held over the "center" of the effect

I'm not advocating for the MCUs to know anything about the game
or "what's (currently) happening". "Something" drives the array,
knowing where every "feature" is located and how to run any
animations -- by directing the associated MCUs to "do this"
or "do that".

The "something" operates at a higher level of abstraction; it
doesn't deal with individual lamps but, rather, with effects
that it delegates to the MCUs in the "regions of interest".

So (keep in mind, I have no idea of DnD gameplay), if there
was an explosion at (4,2) at time t, it would direct the
MCU *at* (4,2) to run the explosion animation at time t.
The "something" (controller, for want of better word) would
know that the effect will take N time units *in* (4,2) and
then want to "dissipate" into the surrounding tiles at time
t=N.

So, the MCU at (3,2) -- just to the left of the origin of
the explosion -- would be told to run the "explosion off
to your right" animation at t=N. The MCU at (5,2 would be
told to run "explosion off to your LEFT" at t=N. The
MCU at (4,3) would be told "explosion above", etc.

The controller would just have to know (algorithmically)
how an effect propagates into adjacent tiles and which
effects it initiates IN those tiles as a result.

The value *you* would add is scripting each of these
effects *in* the specific MCUs AND their "side effects"
in adjacent MCUs (based on board geometry).

The user would just be concerned with defining which
tile is where. And, "something" would have to decide
how the game was progressing (so it would know which effects
to initiate, and where)

[Again, I am only GUESSING as to how "play" happens.]

>> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
>> but, instead, can send "commands" to each MCU telling each what sort of
>> effect you want *it* to provide for *it's* lamps.
>
> Which would require that the slave MCU to have a programmable address
> (and then there's the problem of address conflicts), and on top of that,
> there'd need to be a way to convey which slave was at which position of
> the "game board", so that the effects would be done correctly.

No. Each MCU takes the first N bits of data coming in and
assumes it is intended for *it's* use. The balance are passed
through to the next MCU "downstream".

As there is only one "downstream" neighbor, each MCU has nothing
to decide -- just pass the balance along.

Scaling "widthwise" just means making longer data streams.
Scaling "heightwise" would mean adding additional serial
streams from the controller.

>>> My two design goals were that:
>>>
>>> 1. These things be easy to use for non-programmers (especially if I
>>> opted to make it into a "product" -- doubt I will, but hey, some people
>>> have more money than time). Ideally, the only programming it's going to
>>> take is defining the room dimensions (essentially the lower-right
>>> corner, given that 0,0 is the upper-left)
>>>
>>> 2. The tiles be 180-degree rotationally symmetric, to reduce the need
>>> for "single-use" tiles (e.g. wall sections can be either North/South or
>>> East/West, rather than JUST N or JUST E). Maybe one day I'll figure out
>>> 90 degree symmetry to completely eliminate it.
>>
>> I guess I don't understand how these are further "conditioned".
>> Isn't it just a matrix of indicators? Do the (3Dprinted?) tiles
>> have additional "character" (e.g., contours, etc.)?
>
> Yep -- Think of the playing surface as a *VERY* low-resolution display screen:
> there's only a resolution of 1 pixel / inch (and for testing, I'm
> working with a "display" that's all of 8x8 pixels.). The standard
> playing surface is effectively a large sheet of graph paper, with a
> 1-square / inch grid). You draw walls and doors and whatever else on
> the board in (wet-erase) marker. The 3d printed tiles are ... well, the
> same idea, just, now it's a bunch of plastic pieces that you can set out
> in whatever order to build up the room to make things more immersive
> for everyone.

So, there are N different *types* of "tiles"? I.e., one that is
a piece of lake, another that is the side of a mountain, etc.?
And, the plastic is permanently part of the tile?

I.e., so, you could decide which effects can occur in each
type of tile. E.g., a 'splash' can't occur on dry land;
an explosion dissipates when it runs into a mountain, etc.

>> Photo?
>
> Here's an example of the 3d-printed tileset. The room here is comprised
> of nine (9) individual 3d-printed tiles (All are 2x2 playing spaces,
> even though the walls eat half the space, to keep the real-world
> dimensions "correct") : https://www.fatdragongames.com/images/FDG0160AW7.jpg

So, you'd have 36 tri-color LEDs in that same space?
I assume *under* the tile? So, the floor would have to
be transparent/translucent?

What would you do with 36 lamps in such a room? Would you
try to indicate the positions of some number of players
(each a different color?) within? Or, the motion of a
player THROUGH the space?

[I'm trying to get an idea of what the effects would be like,
in terms of complexity]

>>> To accomplish #1; I went with using standard LEDs with multiplexing,
>>> this eliminated two problems I faced with smart/programmable LEDs:
>>>
>>> 1. Data delivery --> while you need 75% fewer control signals for
>>> "smart" LEDs, things get massively ugly when trying to divide them
>>> into rows and columns. You're either zig-zagging the signal on
>>> every other row; or having a return path on every row, so that
>>> they all start from the left (right). Conversely, with
>>> multiplexing, I just have a grid, with {0,0} being the upper-left
>>> corner.
>>
>> Keep in mind that if you multiplex the lamps (which seems like
>> you may be intending?), then brightness falls with duty cycle.
>> And, that you need to keep the "frame" rate high enough that
>> the user doesn't see flicker or visual artifacts as it beats
>> against the room lighting.
>
> Yep, the framerate (and brightness) should be fine; at least for this
> initial testing size. I mean, let's face it, this is already 64 LED
> packages with "just" an 8x8 grid; "testing" with 16x16 (256 LEDs) or
> 24*24 (576 LEDs) would just be madness :)

How good are your coding skills? Could you emulate it
on a CRT to get a feel for what it would look like?

>> (you may discover that a non-sequential refresh sequence helps
>> hide visible patterns)
>>
>>> 2. Requires "Special" tiles to facilitate data flow. For example, a
>>> chasm in the middle of the room would still need some kind of
>>> carrier PCB to keep the signal flow across / around the chasm
>>> set-piece. Whereas with the multiplexing, the row/column control
>>> plane (on the carrier-board itself) is otherwise unbroken.
>>>
>>> To accomplish #2, I went with some low-profile board-to-board connectors
>>> (cue them NOT being rotationally symmetric when I get the 10 or so I
>>> ordered :) ) ... I want to keep things relatively low-profile, so the
>>> individual boards can survive semi-rough handling (e.g. getting stacked
>>> in a case / bin / etc.) that would be problematic with pin-headers. I
>>> envision needing a few revisions here, since eventually I want to do
>>> away with the "strips", and replace those with what would amount to
>>> individual breakout boards, since the PCBs are otherwise quite big and
>>> sparsely populated due to the physical spacing of the game-board.
>>
>> *If* the 3D "skin" is something that the user can clip on/off the
>> "lamps", then you could just put a "no feature" tile atop
>> the lamps so that they can't be seen AND program that MCU to keep
>> them dark.
>
> Sure, I could do that (maybe). But I *really* want to avoid making
> "special cases" for myself at this point (or, frankly, at any point).
> As it stands, if there were a feature that breaks the "standard tile"
> for some reason (e.g. a chasm, or collapsed floor, or ... whatever),
> it's not going to have any effect on any other LED in the given
> row/column.

In my scenario, the "gap" would just be an MCU told "do nothing"
(stay dark?) but continue to pass the BALANCE of the data stream
across to your downstream neighbor.

> Maybe someday I'll figure it out (or scrap this approach as subpar, and
> revise the whole thing ...)

Is there a nominal "game board size"? I.e., could you
standardize on 8x8 "subpanels" -- onto which the
plastic parts could be placed for textural effect?

[A larger "base unit" may afford you more design economies.
You can always tell the unused parts of a subpanel to "stay dark"]