On 12/27/2023 6:32 AM, Dan Purgert wrote:

>>> 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.
>
> Close enough :). The issue is, now I'm tossing an MCU onto each tile,
> to try making them "smarter", and adding complexity to the "master"
> board to accommodate selecting which row/column is active.

The master would previously have had to select which LEDs were
illuminated. AND, sequence them ALL as multiple effects
could be running in different parts of the board (the master
is the only thing that knows about the whole board so it would
have to assume ALL of that activity)

> It's certainly an option; but on the other hand, "dumb LEDs" where a MCU
> can just act as a CPU and push out "turn on 4,2" with a BJT and a shift
> register.

The problem relates to scale. As the number of LEDs (tiles) increases,
the effort and hardware to control them does, too.

I have a patch-panel at my switch that represents the "field" of nodes.
Each node can be in one of several *significant* states:
powered off
powered on, running POST on CPU, field off
powered on, running POST on field
powered on, passed POST, waiting for slushware as a "warm spare"
powered on, running diagnostics to identify a detected fault
powered on, slushware loaded, waiting as a HOT spare
powered on, field disabled, acting as a compute node
powered on...
"selected" (i.e., this is the wire that you want to plug/pull)
(the indications being necessary as the actual "nodes" being
controlled may not be visible/easily accessible so looking at
THEM is not practical)

I use multimode indicator (like the idiot lights on most switch ports)
to convey this state to the user/observer. It allows him to verify
things are running "as intended", or note periods of low activity
(lots of nodes intentionally powered off), or some fault detected,
or...

Anyway, there are ~300 indicators so drive becomes an issue
beyond just a static approach (in other installations, there can
be thousands of indicators... same design approach).

The "smart LED" approach requires a shitload of data to be passed
into the LED array, constantly. (note that patch panels tend to be
physically large)

I use the "effect" approach to encode a "state" into the data
delivered to each indicator and let that "state" be displayed
locally. So, the controller for the panel only has to deliver
that information and not dick with RUNNING the effects at each.

>>>> 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.
>
> Ah, so "sorta" like the idea behind the WS2812 driver chips, but using a
> selector switch (for example) to enable the data to "Row N"

Yes, but "smarter". The "smart LEDs" are only smart in that
they can control the intensity of the individual emitters
from data presented.

But, that data has to be relatively large (three bytes?)
regardless of what you are telling the LED to do. It's
just a set of RGB "values" that feed a (static) driver.

I'm advocating decoupling the data from the drive and
raising it to a higher level of abstraction. E.g.,
"You four LEDs, run through the predefined sequence
of colors and intensities that simulate an explosion
at your location". Or, "You four LEDs run the
predefined sequence of colors and intensities that
simulate a candle burning out"

I don't know what your effects are so I am just making
up stuff. The point is, the colors and SEQUENCES
are delegated to the individual MCUs. The "controller"
just coordinates the actions of adjacent MCUs
(for effects that extend beyond a single tile)
as well as telling them what is happening "now", in
the game.

[The effort that is in the MCUs would otherwise have
to be in the controller as it drove ALL the lamps]

>> 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?
>
> Yeah, *MOST* of them are quite likely "floor style, variant X" (e.g. a
> "dungeon" set may have 4 "open floor" variants -- "empty" [just four
> flagstones], "some rubble" in a space, or perhaps something like "trap
> door" or "collapsed floor"). Then there's also the "border" pieces with
> walls (and doors, etc).

But, do the effects change, based on the "bits of plastic"
that differentiate these different types of "floor"?

And, do the effects for floors differ from bottomless pits?

>> 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.
>
> "Sort of" but at the present time, I'm not planning anything quite so
> complex as to know what the floor features are.
>
>>>> 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?
>
> Yep, or a little hole in the space where a player piece would be

Or, a bit of rubble...

> standing. PROBABLY a hole, since painting the tiles wouldn't become
> problematic (I mean, let's face it, 3D-Printers are entirely uniform
> colors, and while that's perfectly fine for a testing phase ... )
>
>> 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?
>
> No. Taking that little room shown in the picture there, maybe the
> players set off some kind of trap from the door in the "north" wall that
> sprayed fire at them when they tried opening it.
>
> So this is the grid, with the "W" representing the spaces with walls,
> "D" being the doors, and the "0" being the tiles a character might be
> on.
>
> W W D D W W
> W 0 0 0 0 W
> D 0 0 0 0 D
> D 0 0 0 0 D
> W 0 0 0 0 W
> W 0 0 0 0 W
> W W W W W W
>
>
> Here, we've switched "on" the fire effect ('1's)
>
> W W D D W W
> W 0 1 1 0 W
> D 0 1 1 0 D
> D 1 1 1 1 D
> W 0 0 0 0 W
> W 0 0 0 0 W
> W W W W W W
>
> So, any character that happened to be standing in the "1" spaces would
> get hurt.

So, characters can occupy any (1,1) cell? I.e., in the example, above,
every 0 (or 1) could have a character -- as well as "in" the doorways?

How do players distinguish THEIR character from others (and effects)?
Or, are their characters real bits of plastic sitting ON the tile?

>> [I'm trying to get an idea of what the effects would be like,
>> in terms of complexity]
>
> For now, they're gonna be really simple (just solid red). Eventually,
> probably replace the shift-registers with proper LED drivers, that can
> help do brightness control, etc (so I can mix the RGB channels and get a
> more "fire" looking color orange, or "electric blue", and so on)

The downside of putting the effects in the MCUs is that you'd
either need to reflash them each time you tried a new effect
*or* design them with RAM in which the effect could be stored
(DL at game initialization?)

[I took the latter approach]

>>>>> 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?
>
> good enough, but I don't have a CRT to hand.

CRT == LCD

> I've done it small-scale
> with protoboard and 64 (white) LEDs, and it came out well enough. Plan
> for the week is to drop by the hardware store and pick up one of those
> 12x12 project panels (assuming I don't have any suitable plywood hanging
> out around the house already) and put some LEDs on a big grid.
>>
>>>> (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.
>
> Yeah, but the thing you're not accounting for is that a "Ruined Floor"
> piece isn't the "standard(tm)" nominal 2" square -- rather, it'll have a
> missing corner (or more) so that there's a visual hole in the floor. So
> I'd need a special PCB for that piece (or any similar piece that "breaks
> through" the plane of the floor.

Wouldn't it just be dark? The plastic piece atop it doesn't magically
become ruined...

> With the current multiplexed approach, those "odd" tiles don't cause any
> trouble (other than an extra ring of non-effect that's suboptimal, but I
> can live with that, since it's less engineering

Why can't one of the "effects" commanded to an MCU encode the
same appearance/behavior?

>>> 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?
>
> FOR NOW, it's 4x4 tiles (64 LEDs), because that fits really well into
> two bytes, and I can keep it all in my head. EVENTUALLY I want to
> accommodate 8x8 tiles (256 LEDs) ...