On 2023-12-27, Don Y wrote:
> On 12/27/2023 6:32 AM, Dan Purgert wrote:
>> On 2023-12-27, Don Y wrote:
>>> [...]
>>> 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?

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

Yep, figurines or even just tokens stolen from other games (e.g.
"Trouble" or "Monopoly", etc). Anything that the players can remember as
"them" or "that Goblin I'm fighting" ...

>>> [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]

The "Effects" are pretty static in general terms (e.g. that flame-jet
trap is ALWAYS that shape when on the grid. If it's 45 degrees to the
grid, then it'd just look like this:
0 0 0 0 0
0 1 0 0 0
0 1 1 0 0
0 1 1 1 0
0 0 0 0 0

Other effects might approximate a circle:

0 0 0 0 0 0 0 0
0 0 0 1 1 0 0 0
0 0 1 1 1 1 0 0
0 1 1 1 1 1 1 0
0 1 1 1 1 1 1 0
0 0 1 1 1 1 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

Or just a line.

After that, it's just defining the color (e.g. an explosion would be
some kind of orange color; or a broken vial of acid might be green,
etc.) Ultimately; it really is just "shape and color".

Although your (possibly snipped) idea about "other effects" is certainly
interesting (torches on the walls sounds pretty neat, tbh).

>
>>>>>> 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

Nuh uh. CRT is a scanning electron gun in a vacuum tube (and wicked
heavy).

But yes, I should have at least one or two old monitors that'll still
accept VGA inputs, if that's what you meant?

>
>> 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...

No, it's printed that way. Normally a "full tile" is 2x2 playable
spaces, i.e.

S S
S S

But a ruin / chasm / etc tile may only be

S S OR S S
- - - S

(with the "-" indicating the missing space). The "broken" edge then
(i.e. touching the "-") will be printed up to look like the stone floor
cracked, or if it's an abandoned wooden structure, you'll have a bit of
floor joist sticking out, etc.

Ultimately, that "edge" part of the feature doesn't accommodate the
shape of my LED board; and even if I did make a custom board for those
features, the current design puts the connector dead-center on the LED
carrier. Moving those connection points around is potentially possible,
but I'd rather get the general idea into a "working" state before
changing too many other things.

>
>> 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?

Right now, a single board is basically $2 assembled (4x LEDs packages,
1x connector, 12x resistors); plus something like $6 for the
"motherboard" (ATMega328 + 3x shift registers + 8x BJTs +
caps/resistors/etc. as required).

Even adding "just" an ATTiny 202 is upping each slave board's price by
25% or so (and that's ignoring any data-integrity stuff like switching
to e.g. RS485, etc). I'm not saying I won't be going there; but seems a
bit premature to jump into that for an idea that may have other flaws
elsewhere.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860