Proposal: Tilemap changes

#48

Would the possibility of isometric support be a silly idea?

#49

What do you mean? Isometric is just a matter of position and z-order…it’s up to you!

#50

Indeed, it is! That’s why I thought of the possibility of adding a flag to Tilemap for handling such things out of the box.

#51

Could you try OpenFL 4.2 and Lime 3.2, and see if it resolves it? If I remember, there were a few different commits that amounted to fixing tile.visible

#52

Could this be used to restore the functionality of Tilesheet class?

#53

Tilemap can do much of the work of the old Tilesheet class, but without the same bugs, and with better performance. There are a few key differences (Tilemap preserves state between renders, is “passive” not “active” in rendering and is a DisplayObject) but should otherwise should do the job

1 Like
#54

And how to apply color transformation now? (Previous Tilesheet.TILE_RGB)

#55

This feature doesn’t exist yet.

#56

Any hints how to apply colour transformation for now?

#57

If you want to change the color of a whole Tilemap object I think it’s possible actually by using tilemap.filter = [new ShaderFilter(yourShaderToChangeColor)].
For individual Tiles, there is no way to achieve that except by rewriting the GLTilemap (add support for custom shader attributes) and Tiles (add color attribute) classes and use your own Shader.

I would be interested to have such feature but for now I don’t have the time to write it myself.

#58

Care to share a code example, please?

#59

To tint, just try tilemap.filter = [ new ColorMatrixFilter (matrix) ]

http://api.openfl.org/openfl/filters/ColorMatrixFilter.html

http://www.emanueleferonato.com/2009/04/28/understanding-as3-colormatrixfilter-class/

#60

Thanks @singmajesty!

I just hope some method of manipulating separate Tiles will be possible to implement soon! :slight_smile:

2 Likes
#61

I’m running into the same issue, currently on openfl 4.4.1, lime 3.4.1. Setting tile.visible to false seems to have no effect on whether or not it renders.

Is this still a known issue?

EDIT: Looks like I posted too soon–after a bit more debugging it looks like there was an issue in my code. tile.visible is working for me.

1 Like
#62

This might be weird, but you may also be able to do openfl test html5 but connect to the running HTTP server from your desktop. I do this sometimes by running on the desktop, but opening in a mobile browser :slight_smile:

#63

Agree. the possibility to add different filters to each Tile would be a real plus. Especially if it allows to make a single GPU draw call for all Tiles with same Bitmapdata but different filters applied to them (to model particles effects for example. It should make a huge difference in performance with the “naive” method consisting in having one sprite/particle)

#64

Assuming filters are implemented at the shader level, then different filters require separate GPU calls. However, the same type of filter with different parameters might be fine. (For instance, if all particles used glow filters, but they had different glow colors, that might be possible with a single GPU call.)

#65

yes I was thinking mainly of same filters for each Tile but with parameters that may change for each (like the matrix for a ColorMatrixFilter or the color of a GlowFilter)
Anyway, why would different filters (shaders) require multiple GPU calls. Can’t you send to openGL a batch of draw commands with bitmapdata and associated shaders in a single “call”?

#66

A GPU is a whole bunch of small processors, letting it perform lots of simple calculations in parallel. It’s called a Graphics Processing Unit because graphics generally require a large number of simple calculations, and the calculations can be done in parallel.

Shaders are the programs that the GPU runs. When you’re going to use a shader, you upload it to the GPU, the GPU distributes it to all of the parallel processors, and the processors prepare to run it. Then you pass some data to the GPU, the GPU splits up the data among its processors, and the processors run the program on the data.

There’s more data than there are processors, so each processor is going to need to run the shader multiple times. But since they never switch shaders, there’s no delay. GPUs don’t even offer the option to switch shaders midway, because that would require a lot of extra if statements, which would slow everything down whether or not any switching happened.

1 Like
#67

What if we use a shader for all tiles but we pass some attribute per Tiles (instead of an uniform which need a shader per Tile so it means one draw call per filter), one of these attributes could activate or not the shader for the current vertex.
Example:
-Tile 1 (use shader)
attribute activate bool true
attribute colorFilter
-Tile 2 (don’t want to use the shader)
attribute activate bool false
attribute colorFilter

Then we pass the attributes in the vertex shader, convert it to varying to make it available in fragment shader.
And in the fragment shader, if the varying activate is true, we manipulate the color. But if it is false, we output the original color. It should use one draw call right?

1 Like