Sprites do not change with agent color, strokeColor, size, shape changes

[backspaces]

TL;DR: Use of sprites is now static and thus inflexible. Once made, they do not change to match the four sprite-defining agent property changes. Should we make them more directly manageable by the modeler, or minimize their visibility.

Details: Sprites are static in agentscript. Once set, they do not change. This can confuse users; if they set one of color, strokeColor, size, shape, they expect the agent drawing to change but it does not.

Current architecture is a default setting: @breed.setDefault "useSprites", true.
This tells the given agentset to use sprites for all its breeds/turtles. The next draw of the breed "lazy" converts the four variables into a subimage of a spriteSheet. (They're 10 sprites across and grow vertically .. see the shapes module)

Several solutions exist. 1 - Bring sprites into the open, sorta like Color & ColorMaps did for color. SpriteMaps? 2 - Document that sprites are static. To "reset" them, set the sprite to null and it will then lazy create a new one or use an existing match. (SpriteSheets have an index) 3 - Use defineProperties for each of the four properties, which will set the sprite to null, as in 2)

I'm conflicted, sorta. If we made sprites more "public" then folks would be aware of their properties. We could even, like in color, optimize their use via spriteMaps. And users would use them for their own custom shapes. There is a minor space optimization win: the 4 properties are in the sprite index, thus are replaced by a single property for the sprite. There are other optimization wins as well.

On the other hand, simply making them part of our "Professional Modeling" approach, exposing how to manage them via the shapes primitives would be OK. The ants model, for example, uses 2 specially created sprites and manages them itself.

I can test if the set-to-null actually works well. It should but will require index lookups into the spritesheets whenever new sprites are set.

[bennlich]

simply making them part of our "Professional Modeling" approach, exposing how to manage them via the shapes primitives would be OK. The ants model, for example, uses 2 specially created sprites and manages them itself.

I think I see what you are referring to in the ants model:

if @turtles.getDefault "useSprites"
  bitSize = @patches.toBits @turtles.getDefault("size") #bugSize
  @nestSprite = Shapes.shapeToSprite "bug", @nestColor, bitSize, "red"
  @foodSprite = Shapes.shapeToSprite "bug", @foodColor, bitSize, "blue"

If we made sprites more "public" then folks would be aware of their properties. We could even, like in color, optimize their use via spriteMaps. And users would use them for their own custom shapes.

I don't think I completely follow you here. What would it look like to make sprites more public / how would people become aware of their properties? Is the idea to organize the sprites code in order to make it far more obvious how to use them?

3 - Use defineProperties for each of the four properties, which will set the sprite to null, as in 2)

Is there any downside to this part of the solution?

[backspaces]

What would it look like to make sprites more public / how would people become aware of their properties? Is the idea to organize the sprites code in order to make it far more obvious how to use them?

Yup, basically make their use "official". Right now, they're just an optimization, and not part of the NetLogo API. (I thought the same about colormaps, but then found that NL supports them now.) So making sprites & possibly "sprite maps" (the sprite sheets/canvases used to implement sprites) have a clear API of their own seems reasonable.

Is there any downside to this part of the solution?

Probably not. After using defineProperties for colors, it seems they "just work". I had to make sure object cloning included defined properties, but it was trivial and actually a simpler, better way to clone than just "copying".

However, I think I want to wait a bit before getting elaborate because of the webgl deep dive. If we have dual renderers, one 2D, the other 3D, we may want their API to be more explicit, basically make rendering first-class with its own API.

So for now, I'd favor a trivial API like turtle.resetSprite() simply because it (hopefully) is near-trivial.