[WIP] Frogfaller

[adnzzzzZ]

This is a small demo for a game I'm making that is kinda like Downwell and with tons of different upgrades. Any feedback is welcome!

[raidho36]

Ooooh, looks awesome! Does it works natively on Android or do I need a keyboard or joystick? (I have both but I'd like to know in beforehand). EDIT: eeehhh no it doesn't, shader code is not a valid GLSL ES code. A bunch of syntax and type conversion things that mobile shaders don't support.

[master both]

THE POLISH! MY EYES!
Dude this game looks amazing! Sadly I got this error when I died in the third level:

still, pretty fun game

[raidho36]

Okay so I found the offending code - it's both outline shaders. They use integer division by float which is not allowed (just replace '1' with '1.0'), and regular one initializes a uniform which is not allowed either. Also, it uses a cursor sprite change which is not supported on mobile.

It load everything on start and that takes a while, progress bar wouldn't hurt! Or better yet, don't load everything at once, only load what you immediately gonna need. Saves plenty on loading time and memory consumption.

I also see it uses keyboard a lot, probably wouldn't fly so well on mobile like this - while Bluetooth gamepads are comparatively common, very few people own a Bluetooth keyboard for their phone, much less a Bluetooth mouse. Missed opportunity!

[adnzzzzZ]

Does it works natively on Android Okay so I found the offending code

I have no intentions of supporting mobile at this point in time but thanks for the pointers. I'll change what's simple enough to be changed.

[NightKawata]

Does it works natively on Android Okay so I found the offending code

I have no intentions of supporting mobile at this point in time but thanks for the pointers. I'll change what's simple enough to be changed.

Now, not to come at you or anything, but any reasons why you wouldn't be interested in putting it on mobile? Or do you mean just in the short term with that? I could see it doing admittedly better on mobile, especially where the bar of quality is a little lower due to the nature, which would make this game stand out even more.

No sweat if you don't tap into that long-term, but it might just be something to think about if the game's overall controls and the like are simple enough to translate well. The more people that can get access to your game, the more people are going to know and talk about it.

Not that you're really going to have that issue, as what's presented here is functionally smooth and appealing in multiple aspects. I've seen a couple projects from you, and I want to see some come out soon! Get 'er done!

Keep chuggin away dooder, not only are a lot of people going to be looking forward to this, so will I.

[raidho36]

I'll change what's simple enough to be changed.

I believe simple enough it should be! Shader problems are minor syntax "errors", and you can just put an if-guards around mouse cursor functions! Singular touch is very similar to a mouse so there shouldn't be problems there, and you can put virtual buttons on the screen to substitute the keyboard! *shameless shill mode activate* there is a library that can both handle multitouch input and do virtual keys (sans graphics but it's fully compatible with it) https://github.com/raidho36/love-multitouch

By fixing shader code and commenting out cursor functions I got it to work. It's a pretty cool game I must say! But it runs so poorly on the phone lol! It's like 20 fps; basic profiling shows the update takes 1 ms but rendering easily takes 30. I'll investigate some more into it. But man, those globals everywhere, I'm surprised nothing randomly breaks!

[Ulydev]

Damn, this is amazing. Are you doing all the art and programming by yourself?

[zorg]

Just one thing, avoid needlessly flashing the window at startup; it does this because you immediately resize the window in love.load, after löve auto-creates it with your defaults in love.conf.

Apart from what raidho said about the game "hanging" at startup because of it loading in everything, i'd like to avoid seeing flashing windows, and there's at least two ways of doing this:
1. set window to false in love.conf, and only create it whenever you're sure you have the correct size you want.
2. set your gw,gh to twice as big in your conf.lua, and don't call game.render:resize(2) in love.load.

Sadly both can be tricky, since for one, i get that gw,gh would be your "true" game dimensions, and you're upscaling the graphics, and setting window to false in conf.lua means you can't access related functions you probably would want to use to calculate the window size or something BEFORE creating the window itself... catch-22.

In any case, the point still stands that this is an issue easily fixable/avoidable.

[raidho36]

I've combed through some code and, dang, I mean DANG! The code that renders layers' canvases onto the screen takes almost half as long as all other rendering combined! The layers iterate over objects using ipairs, and rather than removing dead objects from drawable list, it checks objects' "dead" flag and skips them if it's dead. Each layer has two canvases, one to render graphics to and the other just to render that pre-rendered graphics into, before rendering it to game main canvas, which finally rendered to the screen. And all of that while constantly switching shaders and canvases and whatnot. And then also many asserts are fetched through generating disposable text strings - in the graphics code! Geez! And that's just what lies on the surface. No wonder it runs so poorly my phone that pulls perfect fps in VR apps. Come on, step it up! A Super Nintendo should be able to run this! Gotta go fast!

I love the graphics, but the code love I not