That's interesting. Here's what it looks like in both Chrome and Firefox when using Intel GPU: But it works fine when I run the browser with a discrete NVIDIA GPU.
I use Windows 10 x64 with the latest 64-bit Chrome and Firefox.

There seems to be a problem with ParticleSystem drawn to a canvas. It is rendered correctly when drawn directly to the screen but when I try to render it to a canvas and then draw the canvas to the screen, it looks nothing like intended. Here's an online example and here's the source code for it.

Characters in some games skirt around an obstacle when trying to butt against its edge. Any ideas how to implement this behavior with bump?
(don't mind the artifacts)

It's nice to see a new concise implementation of the same great functionality.
Just to be sure: does Stateful work correctly with the new version?

That's a lovely little puzzle, pretty well-designed from a gameplay standpoint and the visuals are smooth too. I think that it actually has a huge potential for becoming a bigger game with more levels as there are plenty of gameplay elements to use. However, here are some of my complaints. I didn't ...

A really nice and clean library.
I think it would be useful if the field which is to be used by a widget to store its value was selectable instead of hardcoded to "text" or "value". It could be used to make quick debugging GUIs to adjust objects' properties in runtime.

Tile object probably shouldn't have an outline, eh? Yeah, I guess? I'd simply put a check for gid property before drawing a shape, like this: for _, object in ipairs(layer.objects) do if not object.gid then -- here if object.shape == "rectangle" then drawShape(object.rectangle, "rect...

Hello, it's me again. Running my game under ProFi I've noticed that STI spends too much time in drawObjectLayer method. I've found out that it draws (or at least tries to draw) rectangular shapes even for tile objects which normally have their width and height set to 0. This results in nothing being...

User-defined properties are stored in object.properties for objects or tile.properties for tiles so you should do something like a:getUserData().object.properties.type instead. But I'm not sure what's wrong with that object field. Hard to tell without seeing the entire code.

Here's another couple of suggestions. 1. I still think that it would be really convenient to have access to tile/object properties within collision callbacks. In my opinion it makes it easier to implement a lot of things related to player-environment interaction (e.g. using doors, taking damage from...