You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It works fine. For the moment it sends an adapter "Sprite" to Hex that intercepts loadTexture calls. When a Hex calls loadTexture the new functionality fills arrays with the Hex.display and Hex.overlay texture keys, then uses the values of those arrays to assemble a couple of large textures that represent the whole grid.
Call this ensemble of arrays GridVisuals.
So far, so good.
But the reason separating GridVisuals from Hex and HexGrid is so that the game isn't tied to Hex updates for visuals. In particular, it's my goal that revamped abilities will update their own visuals and handle callbacks directly.
However, simply letting any function – anywhere anytime – update GridVisuals is ... probably not ideal.
To address that, I think we create a small GridVisualsGuard object that holds a stack. It can offer up a "manager" interface to allow pushing and popping to the stack. And it can offer a "user" interface that makes GridVisuals available, but only to the top object of the stack.
Hexs and HexGrid can merrily keep updating, but the updates won't have any effect unless they're at the top of the stack.
Note
If I were making a game on my own, I wouldn't bother with the GridVisualsGuard. But given that lots of people update this project, it's probably not a bad idea to do some defensive coding here.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've got a local working version of what was discussed here:
#2460
It works fine. For the moment it sends an adapter "Sprite" to
Hex
that interceptsloadTexture
calls. When aHex
callsloadTexture
the new functionality fills arrays with theHex.display
andHex.overlay
texture keys, then uses the values of those arrays to assemble a couple of large textures that represent the whole grid.Call this ensemble of arrays
GridVisuals
.So far, so good.
But the reason separating
GridVisuals
fromHex
andHexGrid
is so that the game isn't tied toHex
updates for visuals. In particular, it's my goal that revamped abilities will update their own visuals and handle callbacks directly.However, simply letting any function – anywhere anytime – update
GridVisuals
is ... probably not ideal.To address that, I think we create a small
GridVisualsGuard
object that holds a stack. It can offer up a "manager" interface to allow pushing and popping to the stack. And it can offer a "user" interface that makesGridVisuals
available, but only to the top object of the stack.Hex
s andHexGrid
can merrily keep updating, but the updates won't have any effect unless they're at the top of the stack.Note
If I were making a game on my own, I wouldn't bother with the
GridVisualsGuard
. But given that lots of people update this project, it's probably not a bad idea to do some defensive coding here.Thoughts?
Objections, opinions, etc.?
Beta Was this translation helpful? Give feedback.
All reactions