Pixellation using push with love.js

[coltonoscopy]

Hello!

Not sure if this is on push's part or love.js's, but it seems that using push while building a game with the main branch, 0.10.2, of love.js (https://github.com/TannerRogalsky/love.js/) produces an odd pixellated/dithering effect with any game, with the exception of some solid colors, like pure red; see below screenshots for a basic example of a Pong game with a greyish background color:

Without push:

With push:

Happen to know what's causing and what the easiest fix would be? Thanks so much!

[Ulydev]

Hello @coltonoscopy , thanks for opening an issue!

I have noticed this too a while back, when making a LÖVE-to-web tool.

It seems related to love.js, as it was reported in this forum thread. Basically, canvases have artifacts on some GPUs (for example MacBook and iPad).

You can check this for yourself in this example. On the left are particles rendered with canvas, and on the right without canvas.
For a temporary fix, you might want to disable the use of canvases in push (canvas = false). I haven’t tried this myself, but it should work :-)

[coltonoscopy]

Hey @Ulydev, thank you so much for the fast response! :) I'm indeed on a Macbook, and the canvas = false flag in the config options fixes the problem (or at least masks it) for now! Since it's not an issue with push itself, I'll close :) Thanks again!!

btw I'm using your library for all of the games I use in a course I teach at Harvard on game dev (cs50.github.io/games); really an amazing library. Thank you for making it and maintaining it! :D

[Ulydev]

@coltonoscopy, you're welcome!
Thank you for using my library in your course, I really appreciate it :-)

[coltonoscopy]

@Ulydev all thanks go to you! :) Really makes teaching in the context of retro-style games much easier!

[coltonoscopy]

@Ulydev PS, given your experience with love.js, happen to know what might cause performance issues for games in the browser that run perfectly fine (60 FPS) natively? a la the following simple Super Mario clone?

Original repo (mario subfolder): https://github.com/games50/mario
Live deployment: https://coltonoscopy.github.io/mario-love-emscripten/

[Ulydev]

Hello @coltonoscopy, sorry for the delay.

There indeed seems to be a performance issue in the love.js version of your game. I must admit it's been a while since I used LÖVE, but here are some first guesses.
First, try the release-performance release type of love.js - it makes it harder to debug, but could also improve performance.
Also, I suggest you use LÖVE's SpriteBatches for tile-based games. In my experience, it makes a huge difference when there are many draw calls. For instance, Mari0 uses it, and even the love.js version runs pretty smoothly on my laptop.

Good luck! Please let me know if you have any other questions 😄

[coltonoscopy]

Hey @Ulydev, thanks so much for the response! I'll try both of those techniques. Offhand, do you know what would cause performance differences between love.js and native LÖVE in the context of draw calls such that a SpriteBatch would indeed make such a difference on the same machine? Does WebGL suffer more from that particular bottleneck?

[Ulydev]

Hello @coltonoscopy,
That's a great question, I wish I was experienced enough to answer it correctly. I'm not sure draw calls are the only thing that make a difference when porting to the web. It could be due, more generally, to the way Lua code is interpreted in the browser.
My suggestion about SpriteBatches was just a guess, as it is one of the most efficient improvements I noticed when I first started using tile maps with LÖVE. The fact that in general, WebGL is slower than native OpenGL makes it possible that reducing the amount of draw calls improves performance.
Your question made me wonder if there's some kind of benchmark that measures regular Lua usage vs. love.graphics draw calls. One could run them both in native and web environments and see where is the biggest difference in performance.
I'll be sure to let you know if there's such a thing - or if I end up making one. Thanks!