Support for multiple tileImage's

[AxeLanderMoreira]

Not sure if this fits as a suggestion or question, but here it goes:

I've noticed that your library is designed around having a single global tileImage / texture, passed to the global engineInit() function, and that's it. All sprite frames and map tiles should be placed in that single texture, and the developer should plan beforehand what is the ideal tile size that the needs (which is not a bad thing in itself, by the way). Is my understanding correct?

I think that having multiple tileImages with different tileSizes and dimensions could make easier, for example, to create large boss characters.

But first I want to know if this notion is against the fundamental design philosophy behing Little JS (which is to help creating an HTML5 game as tiny as possible).

If that's not the case, I wonder if maybe the following suggestions apply:

• add an optional tileImageSource argument to the EngineObject constructor.
• actually, with so many arguments - and a few of them optional - I wonder if the best approach would be using named arguments instead of positional arguments (i.e. through a single object). Of course, that would break compatibility with previous versions.
• perhaps the same could be applied to the TileLayer constructor as well?
• of course, that means that tileImageFixBleed and related variables, inside engine.js, would have to be handled in a more dynamic way.

Please evaluate.

Additional question : Is there any restriction in using non-power-of-two textures for the tilemap?

[KilledByAPixel]

Hi, thanks for taking a look, you bring up some good points, I have solutions!

It is built all around 1 tile image. The reason for this is not just simplicity but also rendering speed. This way everything can be drawn in giant batches for very fast performance.

You can mix and match the tileSize in the tile sheet. So you can and probably will have some 8x8, 16x16, or even rectangular shapes like 32x64 shape sprites. (see platformer example)

For advanced users like yourself my suggestion is easy. Just load whatever different tile sheets you want yourself first, then combine them together into 1 tile sheet and pass that to engineInit. For pixel art style games this should not be a problem because a tile sheet of 4096x4096 is the limit and that would be huge. Or you can prototype without this using only a few sprites, then swap it out later when you are want to add more stuff.

I made it easy to customize also, so if you'd like to create your own EngineObject where you pass in an image, you can do that by just extending the class and overriding the render function.

You are not meant to be creating objects with that many parameters from game code. It is better to extend EngineObject with your own class like in the examples. The parameters all have defaults and instead of going the named approach you can just set these on the object after it is created. For example, create an object then do object.angle = 20.

I like named parameters for some stuff, but it really does work against our philosophy here, and it's not just theory but for the practical purpose of size coding competitions. Also it somewhat works against the simplicity theory of the engine, but usability is also important. I hope this paradigm strikes a good balance.

For the tile layer constructor, let's take a look at it...

/** Create a tile layer object
    *  @param {Vector2} [position=new Vector2()]   - World space position
    *  @param {Vector2} [size=tileCollisionSize]   - World space size
    *  @param {Vector2} [tileSize=tileSizeDefault] - Size of tiles in source pixels
    *  @param {Vector2} [scale=new Vector2(1,1)]   - How much to scale this layer when rendered
    *  @param {Number}  [renderOrder=0]            - Objects sorted by renderOrder before being rendered
    */
constructor(pos, size=tileCollisionSize, tileSize=tileSizeDefault, scale=vec2(1), renderOrder=0)

At first glance it seems like a lot. But for most games you actually won't need to pass in anything. (one typeo, i noticed size=objectDefaultSize should be size=tileCollisionSize, was correct in code but not documentation)

But these params can also be set on the object instead. So, renderOrder is the last parameter in the list. If you don't want the default you can call myLayer.renderOrder = 123, or whatever you want.

For non power of 2 textures, I would advise against it, but I think nowadays most gpus will work if it is a multiple of 4. It doesn't hurt to have extra space in your texture, good to space things out.

I hope that helps, let me know if you have any more questions.

[AxeLanderMoreira]

Thank you very much for the detailed answer.

About mix and match the tileSize, I hadn't notice it before. But now that I've dug a little deeper in the platform example, I've seen it.

So you can have specialized EngineObjects with specific tileSizes (e.g. Grenade with 8, Enemy and Player with 16). And also a TileLayer has its own tileSize as well and does not interfere with the EngineObjects. Good.

I will experiment a little bit with it, but it seems to fit my needs pretty well.

I understand your points about the preference for positional arguments. Since the performance is a key concern, and the API is pretty much stable, I think it's fair enough.

About the texture size, I agree it's best to stick with power-of-two sizes for the sake of portability.

[KilledByAPixel]

I have added support to set additional textures with the command glSetTexture

This will flush the gl buffer and bind the new texture. It will be slow if used often throughout the update causing more draw calls, but can be useful for post processing and hud elements that are rendered after the objects.

[KilledByAPixel]

A while ago I added support for multiple textures, it seems to be working fine so I am going to close out this discussion.