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