ghoulsblade/love-webplayer

WebPlayer for Love2D engine games (webgl+javascript)

love-webplayer's Issues

Get 'no' example working with Weblua

After this, we're going to be getting into examples that seem not to be in the repo. I'll see if I can find them and add them as submodules.

ReferenceError: MainOnLoad is not defined onload()

Basically nothing's working.

Request: Integrate with Nextcloud & Owncloud

It'd be awesome for love-webplayer to be accessible within Nextcloud as an App so I can self-host games. The project is just starting to add games and this would be an awesome addition!

Switch from existing Lua parser to Emscripten-based one

lua-parser.js sucks, and it's too much work for us to fix it on our own.

My current porting project for Hawkthorne is a nightmare thanks to the multitude of "unfinished business" in the current Lua parser. In order to get vendor libraries to work, someone would have to implement string.match, at least far enough for the following line to work:

local _PACKAGE = (...):match("^(.+)%.[^%.]+")

No. Fuck that. I'm done.

There's a better way, just waiting for us to use it.

People have compiled Lua to JS with Emscripten. This is a legit compilation of the actual C source code into Javascript. The interpreter acts the exact same way as the "real deal," because it pretty much is. There are no surprises, no unimplemented features, no parser-specific craziness to waste days debugging.

We switch our internal parsing and compilation to that, and we get a fast and accurate Lua base on which to build our kingdom.

Will this be hard?

Some parts yes, some parts no. The basic architecture should be easy to switch out, but it's the surrounding stuff (especially our customizations to the old lua-parser.js code) where we will likely run into trouble. All our existing code is built on lua-parser, and examples may temporarily break during the transition.

That said, the change is really, really worth it. A consistent, correct, and uncrippled Lua parser is essential to porting any sort of advanced game to Webplayer.

Who will do it?

Probably me. I'm the most highly motivated, all my work can happen in a toy branch over in my repo while we get it up to snuff for merging, etc. But with the satellite concerns, such as supporting other demos, it's more than a one-man job.

love.image with 2d canvas contexts

http://www.w3.org/TR/2dcontext/#images
http://www.w3.org/TR/2dcontext/#pixel-manipulation
http://stackoverflow.com/a/9048238/1185957

Single file / require

Hi,

I think requiring the files like this just doesn't cut it:

<script type="text/javascript" src="../js/lua-parser.js"        ></script>
<script type="text/javascript" src="../js/lua-parser-utils.js"  ></script>
<script type="text/javascript" src="../js/gamepad.js"      ></script>
<script type="text/javascript" src="../js/jquery.js"      ></script>
<script type="text/javascript" src="../js/jquery.hotkeys.js"      ></script>
<script type="text/javascript" src="../js/utils.js"         ></script>
<script type="text/javascript" src="../js/utils.webgl.js"       ></script>
<script type="text/javascript" src="../js/love.render.js"       ></script>
<script type="text/javascript" src="../js/main.js"          ></script>
...

I see two options:

• Using a tool like Uglify to bundle all the js files into a single one (maybe as part of a "push" task, so it is done automatically every time you push new stuff to github)
• Including a lib like requirejs so that a single file (love.js) can use it to require all the files it needs.

love.thread with "web workers"

https://developer.mozilla.org/web-tech/2008/09/04/web-workers-part-1/
https://developer.mozilla.org/en/Using_web_workers
http://dev.w3.org/html5/workers/
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html

love.graphics.draw(bg) does not draw anything

love.graphics.draw(bg) doesn't draw anything.

it should draw the same as love.graphics.draw(bg,0,0)

love.graphic.draw() not working exactly as it should.

I noticed in this youtube video http://www.youtube.com/watch?v=wPfpwgkEV3U#t=00m11s (00m11s) that the "buildings" aren't displaying properly.

I don't think it's a config issue, because I spit out the same buildings twice to get the "moving effect".

Code is here: http://cupm.net/public/gigapudding/

love.graphics.rotate doesnt work

does nothing. Leaves all unaltered.

Get IYFCT game working with Weblua

Another part of #17.

Port Hawkthorne to Weblua

Biggest, longest, most extensive porting project that we'll ever do with love-webplayer. Might as well get started now.

Pysfs

Hi,

This is the first time I look into this project. First thing I noticed is that you need to uncompress the .love file in order to play games.

I think it would be a very nice change if the player could directly read .love files instead.

Ideally I'd like to have an index.html with just one line:

<script href="love.js" data-love="http://your.game.url/game.love"></script>

I think one of the missing pieces for setting this up would be having physfs working in js. It might be possible to bind it to javascript just like the Lua interpreter has been. I don't know for sure though.

Get Clouds example to work with Weblua

I'm breaking up #17 piece by piece, since it's such a massive refactor. So for the first thing, I'm going to try to get the Clouds example working with weblua. I want to do the simplest ones first, working my way up the complexity chain until all existing examples work.

how about pixijs + love?

I was wondering if it were possible to use pixijs as the renderer for love-webplayer. pixijs uses webgl and has a backwards compatibility to canvas and pixijs is faster.

"Pixi.js is a rendering library that will allow you to create rich, interactive graphic experiences, cross-platform applications, and games without having to dive into the WebGL API or grapple with the intricacies of browser and device compatibility. Killer performance with a clean API, means not only will your content be better - but also faster to build!"

pixijs: http://www.pixijs.com/