When the contact handler returns an entirely new node in the second or third component of the result triple, that new nodes does seem to get ignored.

• Round trip marshalling of the various types of nodes
• Tests covering the node merging/updating

At the moment, it makes no sense to make the fields of Node components strict as we exploit laziness for lazy marshalling back to Haskell. However, the following would be even better.

• Make all Node components strict (at least those of elementary type, but maybe also some frequently modified ones of Point, Rect, and so on types).
• Marshal all strict components eagerly from ObjC to Haskell (in one foreign call!) and keep the rest being marshalled lazily.
• Set the eagerly marshalled components on the ObjC object only if they changed in the Haskell world (using comparisons on the elementary types, rather than on thunk references).
• Do the same for Scene. (Maybe even do it first for Scene.)

This balances thunk creation and entering overhead with the overhead of marshalling elementary values that are not ending up being changed.

See definition of Action in Types.hs.

I'm playing around with the SpriteKit binding trying to learn and understand the basics. I have the following simple scene:

import Graphics.SpriteKit 

moveThisNode = (moveTo (Point 200 200)) {actionDuration = 10}

aSprite = (spriteWithColorSize redColor (Size 2 2)) {
  nodePosition = Point 125 125,
  nodeSpeed = 1,
  nodeActionDirectives = [
    RunAction moveThisNode Nothing
  ],
  nodePaused = True
}

sceneWithSprite = (sceneWithSize (Size 250 250)) { 
  scenePaused = True,
  sceneChildren = [aSprite]
}

Since both, the node and the scene are set to be paused, I would expect the sprite not to move.

However, when I render the sceneWithSprite in Haskell for Mac, I clearly see the little red sprite moving.

Am I doing something wrong? Is my understanding of paused wrong?

• Provide access to SKNode(fileNamed:)
• The docs say that the archive needs to be in the app bundle. Can we load it from the .hsproj project resources?
• Create a new ticket to also load action files.

Currently, the build system doesn't build a profiling flavour of spritekit. This is as the unique identifier names generate by language-c-inline for 'hswrapper's get different names in a profiling build, and so, would need a different variant of the wrapper Objective-C code.

This is really an infelicity of language-c-inline.

• All the spriteWithXYZ functions actually ought to be called spriteNodeWithXYZ.
• Rename, but keep the old version (deprecated) around for a while to ease the transition. Maybe we should keep them and introduce similar short forms for the other nodes...
• Add support for normal maps to sprites and also add light nodes (and the needed functionality on textures). Moved to #12.

Consider this alternative scheme (and adapt the todo items below):

• The SKNode representation keeps a stable pointer to the Haskell representation it originates from. (Then, we can probably get rid of the special case of how we are doing that for scene nodes right now and we don't need to have the "haskellUserData" entry in SKNodes userData as this is subsumed bu a reference to the entire Haskell representation.)
• We update the Haskell representation each time we marshal the node back from SKNode to Haskell.
• When merging a (possibly) updated Haskell representation into the foreign SKNode representation, we always determine the to be updated delta by comparing to the Haskell representation refereed to be the SKNode (that crucial depends on the previous point).
• When we call back into Haskell in scene update functions or custom actions, we have no idea which part of the referenced Haskell representation (except the user data) is still valid and so need to create a new Haskell representation from scratch. However, when we need to marshal the Haskell representation to an SKNode to invoke methods, such as frame or calculateAccumulatedFrame (assuming nodeForeign is set), we update the reference to the Haskell representation, which then serves as the delta for the next Haskell to SKNode marshalling — saving work when we call multiple functions, such as frame or when the Haskell representation is passed back unchanged as a result node.
  One big advantage of this scheme is that reordered lists of children don't take any effort to match the old and new Haskell representations that need to be compared.
• The current implementation of addChildren is quite inefficient for large arrays of children. We should use sets for the containment testing when the arrays get bigger.
• The current implementation of addChildren doesn't generally preserve the order of the children (wrt to the order in the Haskell structure). This is bad as the drawing order depends on the order of the children.
• Improve Node.addChildren and related functions. When we update an existing SKNode tree with Haskell-side changes, currently, the whole tree gets traversed if the nodeChildren field of the root changed at all. This is quite inefficient on large trees. It would be better, while inspecting the individual children to see whether some children didn't change at all and then prune the traversal using that information.

I am having a problem compiling the HaskellSprite kit in Xcode 9.1 with GHC v. 8.2.2.
The error is placed below:

Showing Recent Messages
[ 8 of 14] Compiling Graphics.SpriteKit.Types ( Graphics/SpriteKit/Types.hs, /Users/braedenfoster/Library/Developer/Xcode/DerivedData/HaskellSpriteKit-ckqakbbckyvankhijtgdgqnstbxs/Build/Intermediates.noindex/SwiftMigration/HaskellSpriteKit/Intermediates.noindex/HaskellSpriteKit.build/Debug/HaskellSpriteKit.build/spritekit/build/Graphics/SpriteKit/Types.o )


Graphics/SpriteKit/Types.hs:395:19: error:


    Not in scope: type constructor or class ‘GHC.Any’


    Module ‘GHC.Prim’ does not export ‘Any’.


    |


395 | newtype Any = Any GHC.Any


    |                   ^^^^^^^


cabal: Leaving directory 'HaskellSpriteKit/spritekit'


cabal: Error: some packages failed to install:


spritekit-0.9.0.2-CQBFv3qNfz48eVFPtHanfT failed during the building phase. The


exception was:


ExitFailure 1


cabal install failed

The haskellScenePtr refers to the Haskell version of a scene including the scene's children. Those children may, however, be outdated when we get back to sceneUpdate on the next frame as both actions and contact handlers may have changed arbitrary children in arbitrary ways.

• Update scene children when making use of haskellScenePtr at the start of a frame (using lazy marshalling as usual).

If actions are used repeatedly, it is more efficient to create the action objects once and run them on multiple nodes. To do this in the Haskell binding, use stable names to identify identical actions (actually action trees) and reuse them.

(We need to be careful to free them after a while of not being used, though.)

• Add support for normal maps to sprites (constructors and properties)
• Add light nodes
• Add normal map functionality to textures