Iām toying with porting this from Pixi.js to Heaps. Iāve made a little progress as you can see (browser on the right, heaps on the left)

Itās fascinating, heaps is a different beast, and it doesnāt seem to care much about ease of portability.
First, there are many drawable types (Sprite, Bitmap, TileGroup, SpriteBatch.) I get it, best performance in each scenario. But it creates a learning curve⦠but also a weird refactor. For example, in my pixi game, I have all the assets in one atlas. Iām at ~2-3 draw calls per frame. And my code is structured such that tldr; itās all Sprites all the way up and down, all sourced from the same texture atlas.
The pixi Sprite can be a container, and have a texture, and has a pivot point. Thatās extremely flexible, and Iām sure it requires extra calculations, but if it can do all that in a batched rendering, thatās pretty awesome / flexible.
With heaps 2D, I have to make some decisions with no clear good option:
-
The docs say that Bitmap is not good for performance / is not batched. So each one is a draw call. It doesnāt have pivot, which will be an irritation during porting. Pivot is a nice flexibility feature - anything that can rotate/scale is super handy if it has a pivot, otherwise it takes an extra layer of container to achieve the same. I get it, Tile has a pivot, but Tile is not a container.
-
So what about SpriteBatch. But now I have to decide how to refactor ā
- if there was one global SpriteBatch in my level, well, now I canāt have parent/child display list relationship between Drone and its fans (all BatchElements).
- If I make each entity a SpriteBatch (e.g. the drone, and its fans BatchElements), thatās fine⦠But now each entity in my game is a SpriteBatch and causes a draw call? Thatās still not great, is it?
Is it possible to create a new 2D Sprite class for heaps that:
- is a container (transform matrix)
- has a
.tile
(can be graphics + container)
- has a
.pivot
- the whole tree batches as long as the tile is from a single texture
Or, am I structuring my code wrong. Should my logic / controllers not extend the framework classes, and rather use them? Perhaps it would have the benefit of making my code for framework agnostic? I roll my own parent/child/transform class, and I calculate all the transforms down to the textures, and I just use one big SpriteBatch renderer? At least that would be portable⦠
See, the only reason to use heaps is breaking free of the browser⦠but in his heaps FAQ, one of the main contributors says it supports mobile āin theoryā, and āuse your own compiler toolchainā when compiling for windows.
I dunno, I see the amazing things people create in heaps, but Iāve never found it approachable, no matter now may times I try. (A while back, I was trying to use h3d and get blender models into it, never really got it working.) 