If I knew anything about C, do you think I'd be here?tsturzl wrote:Go do it then :p I don't know much about NaCl and I think Javascript/HTML5 is a better route. You're the one who's got the ideas about it.Jasoco wrote:It may be horrid, but it's still amazing given the situation. I can't imagine what BrowserLöve will be like in a few years. I still think we should make a NaCl version. Google is hoping to get it picked up by other browsers, and what better way than to have some solid awesome stuff. But I'll settle for anything that gets even half the performance of normal Löve.
Go forth and do!
Love2D WebPlayer (WebGL)
- Jasoco
- Inner party member
- Posts: 3725
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Love2D WebPlayer
- ishkabible
- Party member
- Posts: 241
- Joined: Sat Oct 23, 2010 7:34 pm
- Location: Kansas USA
Re: Love2D WebPlayer
NaCl is a good route to give us almost the same performance as vanilla love but there's better way. NaCL code usees a smaller, safer, subset of x86(or ARM as the case may be) which means you get slightly slower applications because the optimizer can't fully do what is needed. it also means no JITing so LuaJIT for NaCl is not possible which means an NaCl version will be slower than vanilla love. JavaScript is however highly optimized and JITed on almost all browsers. Because Lua is so similar to JavaScript in terms of types translation can yeild efficient code that becuase of optimization and JITing would actually be faster than vanilla Lua! Now as long as we get accelerated graphics this should actually yield a FASTER than vanilla love web player. It wont be faster than LuaJIT love however; Nothing I can think of will beat that. the translation from Lua to JavaScript is the biggest issue but it shouldn't be that much of a performance drain if done correctly and optimized correctly.
So just becuase an NaCl implementation would be native doesn't mean it's going to be faster; you have to best use the tools that are given.
All this said however; an NaCl implementation we should be able to use all the same code so it would function exactly as the current love does. your compatibility would be much higher.
So just becuase an NaCl implementation would be native doesn't mean it's going to be faster; you have to best use the tools that are given.
All this said however; an NaCl implementation we should be able to use all the same code so it would function exactly as the current love does. your compatibility would be much higher.
- Jasoco
- Inner party member
- Posts: 3725
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
- Contact:
Re: Love2D WebPlayer
I say use whatever method yields the best fastest result with the most compatibility.
At some point you could release simultaneous equivalent browser versions of the code when binaries are released.
At some point you could release simultaneous equivalent browser versions of the code when binaries are released.
- ishkabible
- Party member
- Posts: 241
- Joined: Sat Oct 23, 2010 7:34 pm
- Location: Kansas USA
Re: Love2D WebPlayer
Unfortunately there is a conflict there, it's hard to have both. I actually prefer having 1 implementation that has near perfect compatibility so I'm actually in favor of a NaCl implementation but only conditionally. NaCl only works for 1 browser and it's not as portable so for non x86/ARM devices(certain phones?) it wont work. It would also require the "Pepper" API to make calls to system functions for keyboard/joystick input, OpenGL, sound, etc... If better support comes out then I'm all for it. otherwise JS is still a better option.I say use whatever method yields the best fastest result with the most compatibility.
Re: Love2D WebPlayer
it isnt?ishkabible wrote:it also means no JITing so LuaJIT for NaCl is not possible
also, i don't think translating lua to javascript is entirely trivial since based on the lack of support for __mode and __gc in lua.js it almost looks like not only does the garbage collector have to be implemented in javascript, but memory management as well! afaik, js doesn't support weak references, and even what i've seen in harmony's implementation of weak maps is still insufficient (weak keys only, can't iterate them)
- ghoulsblade
- Party member
- Posts: 111
- Joined: Sun Oct 31, 2010 6:11 pm
Re: Love2D WebPlayer
Well, it obviously works, not perfect, but even supports metatables, as you can see in the demos.Xgoff wrote:i don't think translating lua to javascript is entirely trivial
I don't wanna bother with NaCl atm since that'd only work in chrome for the time being, and we already have a working prototype with the translate-lua-to-javascript solution and more and more of the api is implemented every day =)
With enough interest, maybe even the current shortcomings and parserbugs of the lua-js translation can be fixed.
love-android - gamejams
Re: Love2D WebPlayer
Again, please open another thread about NaCl. I think this thread is only meant for this particular html5 webplayer implementation. thanks!ishkabible wrote:Unfortunately there is a conflict there, it's hard to have both. I actually prefer having 1 implementation that has near perfect compatibility so I'm actually in favor of a NaCl implementation but only conditionally. NaCl only works for 1 browser and it's not as portable so for non x86/ARM devices(certain phones?) it wont work. It would also require the "Pepper" API to make calls to system functions for keyboard/joystick input, OpenGL, sound, etc... If better support comes out then I'm all for it. otherwise JS is still a better option.I say use whatever method yields the best fastest result with the most compatibility.
- ghoulsblade
- Party member
- Posts: 111
- Joined: Sun Oct 31, 2010 6:11 pm
Re: Love2D WebPlayer
@mods : any chance to get a subforum for all discussions around love+web please ? =)
could be used for nacl or html5-canvas-instead-of-webgl projects if there ever are some, and to coordinate work on cooperating to implement the different love modules/api-sections.
and of course for demos and possible upload(.love)+host websites
could be used for nacl or html5-canvas-instead-of-webgl projects if there ever are some, and to coordinate work on cooperating to implement the different love modules/api-sections.
and of course for demos and possible upload(.love)+host websites
love-android - gamejams
- ishkabible
- Party member
- Posts: 241
- Joined: Sat Oct 23, 2010 7:34 pm
- Location: Kansas USA
Re: Love2D WebPlayer
I stand corrected but this hasn't been done for LuaJIT yet and would be a massive undertaking.it isnt?
well I never said it was trivial; just that the translation could produce efficient JS becuase of the similaritiesalso, i don't think translating lua to javascript is entirely trivial based on the lack of support for __mode and __gc in lua
__gc isn't obeyed for tables anyway and semantically there isn't a need for mode becuase it's only an optimization(you can ignore it). a bigger issue would be how functions work. for instance, you can't index by functions in JS so that means all functions have to be wrapped in tables and all calls and '[]' have to be type checked; that's a pretty big preference drop. differences like that are the biggest issue to me but they're perfectly solvable.
Re: Love2D WebPlayer
weak references are pretty important for gc'd languages, otherwise things like caches would never release objects. you'd pretty much end up with something not much different than a memory leak. yes, you can live without it, but if you do anything remotely complex with references you'll suffer from not having itishkabible wrote:well I never said it was trivial; just that the translation could produce efficient JS becuase of the similaritiesalso, i don't think translating lua to javascript is entirely trivial based on the lack of support for __mode and __gc in lua
__gc isn't obeyed for tables anyway and semantically there isn't a need for mode becuase it's only an optimization(you can ignore it). a bigger issue would be how functions work. for instance, you can't index by functions in JS so that means all functions have to be wrapped in tables and all calls and '[]' have to be type checked; that's a pretty big preference drop. differences like that are the biggest issue to me but they're perfectly solvable.
__gc would still be important for userdata which could be used to access the host language's data (which as far as lua is concerned, there isn't really any difference between js and c). it'd also be a problem for a 5.2 implementation since that does support __gc on tables
EDIT: anyway, this probably isnt the best thread for this discussion, so
Who is online
Users browsing this forum: No registered users and 19 guests