Page 3 of 4

Re: Try Love in your Browser

Posted: Mon Jun 07, 2010 4:51 pm
by pygy
What about porting LÖVE to Google Native Client rather than writing a custom plugin?

Re: Try Love in your Browser

Posted: Mon Jun 07, 2010 5:13 pm
by bartbes
Well, it is nowhere near done yet, so, we'll just wait for now. I might just do something when my holidays start.

Re: Try Love in your Browser

Posted: Tue Jun 08, 2010 7:52 am
by pygy
Sweeet :-)

With Google behind it, NaCl should have a larger install base than what we could get for LÖVE by ourselves :-)

Re: Try Love in your Browser

Posted: Mon Jun 21, 2010 11:55 pm
by Chris016
There is a flash compiler that is free, Its called Flex SDK, Which is actually Actionscript 3 compiler free of charge and there is a free IDE to use with it called FlashDevelop, And i was thinking of embedding Lua Alchemy into it. Havent had time but its possible. Having ActionScript interpret Lua would be really slow.

Javascript is ok but javascript interpreting lua would be massive speed drop. But if we make a lua to javascript converter. It would be faster then javascript interpreting lua.

Re: Try Love in your Browser

Posted: Tue Jun 22, 2010 12:22 am
by TechnoCat
Chris016 wrote:Javascript is ok but javascript interpreting lua would be massive speed drop. But if we make a lua to javascript converter. It would be faster then javascript interpreting lua.
http://code.google.com/p/lov8/

Re: Try Love in your Browser

Posted: Tue Jun 22, 2010 2:57 am
by Luiji
We need to retain a wiki category for ports.

Re: Try Love in your Browser

Posted: Tue Jun 22, 2010 3:18 am
by Chris016
TechnoCat wrote:
Chris016 wrote:Javascript is ok but javascript interpreting lua would be massive speed drop. But if we make a lua to javascript converter. It would be faster then javascript interpreting lua.
http://code.google.com/p/lov8/
thats pretty cool, But it not what i really meant. V8 is pretty cool and all but i mean a Love Canvas project. Where we convert love lua to javascript canvas. Theres a box2d in Javascript canvas. And html 5 audio. Im thinking we could look into something like that.

Re: Try Love in your Browser

Posted: Tue Jun 22, 2010 3:29 am
by Luiji
Doesn't sound over-complicated, except that they are indesisive about supported formats (because of, in fact, Apple).

Re: Try Love in your Browser

Posted: Tue Jun 22, 2010 3:40 am
by Chris016
Javascript in Chrome or Safari are the fastest i hear. But it is still not like native fast. Thats why you i see it as you will probably need to optimize it. So thats why maybe writting a Love Canvas wouldnt be a bad idea. That uses the same kind of api as Lov8 does because it seems to work really good as i just downloaded it.

Re: Try Love in your Browser

Posted: Wed Jun 23, 2010 12:06 am
by Jasoco
Well, Apple's against OGG/VORBIS because of the ownership. It may be open source but only until 2012 or so. Then it will need licenses. Mozilla is against H.264 because of the fee they'd have to pay to use it. Which is why WebM was invented, but once again Apple doesn't want to use it. I'm afraid we'll never get one single format. So we'll have to support them all for now. Personally I think it's stupid. There's hundreds because people keep coming up with new ways to make files smaller while keeping quality. But every time you turn around a new method is created and a new codec is born. This is also the main problem with DVD's. They were invented back in the days of MPEG-2. Which is so old, it only allows for 2 hours on a DVD disc. An H.264 file of the same length takes up a lot less space. But they can't switch DVD's over to H.264 because then nothing would be able to play it. Same with TV signals. TV stations could save so much bandwidth and give much better video quality if TV used a better codec, but since modern digital TV signals are once again MPEG-2, we can't switch to something else because once again, nothing would know how to use it. HD signals and Blu-Rays use better compression these days, but still, in a few years we'll look back and wish we could upgrade the HD signal to whatever the hot codec is out at the time.