Another vote for LUA here.
cocos2d 2.0 - ideas
(153 posts) (67 voices)-
Dell makes a good point. It would be interesting to define a bridge API that multiple scripting languages could hook into to support both. However that seems a fair bit more complex than just supporting one.
If I had to pick one or the other I'd pick JS, mostly because of the war on making it perform better all the time. I have little experience with either as far as any real development projects, so it's all new to me.
If we did end up using JS you could do silly things like cappuccino on top of cocos2d. :D
Posted 10 months ago # -
Another point come to my mind in development of my latest game.
An CoreAnimation behaviour for action would be great.
Shortly speaking a kind of animation proxy for the object. Actions would only modify the values of the presentationProxy. As long as actions are running rendering uses the proxy, if actions are stopped it falls back to itself.That has the advantage that you can be sure about positions/state of objects, when actions are stopped.
And it will be a lot easier to meet sprites with MoveTo actions.Posted 9 months ago # -
@slembcke:
Thanks for the suggestions. I've just implemented the new way to link physics with cocos2d:https://github.com/cocos2d/cocos2d-iphone/blob/gles20/tests/ChipmunkAccelTouchTest.m
Posted 8 months ago # -
Cool, I think I'll have a chance to check that out tomorrow.
Posted 8 months ago # -
MANT
MemberI've worked with both JS and Lua. They're both excellent languages. Personally, for a *scripting* language for Cocos2D, I think Lua is the clear choice.
If you've ever played World of Warcraft, you know that there are thousands of add-ons written for it, all in Lua. Back in 2005 I played the game with 20+ different addons running simultaneously, updating the screen, and still able to maintain 50+ FPS. So Lua is definitely fast enough for games.
Lua was designed from Day One to be embedded as a scripting language as part of larger programs. Its C interface is clean and very easy to implement. It's just as mature a language as JS, but it's a SMALLER language without some of the cruft you get with JS.
Here are most of the comparison points Riq mentioned:
RUNTIME: This depends on the implementation. Typically I've found speeds to be comparable, but Lua uses less memory. The overall footprint of the Lua runtime is smaller. One of Lua's main design goals is to be small.
SUPPORT: Both are mature languages. JS is definitely more popular generally and has more free help available. There is also plenty of help available for Lua, just less of it.
INTEGRATION: I haven't tried integrating either of these myself, but if you Google it, you'll find a lot of people who love Lua once they integrate it after trying other languages first. JS may be OK to integrate but Lua was *designed* for it.
LANGUAGE: From my own experience learning each language, Lua is a little easier to learn. It's a smaller language, there's less "tricky" stuff with it, and the syntax is pretty clean. JS/C/C++ programmers often don't like Lua because of its begin...end syntax and having to declare everything as local, but you get over that pretty quickly. Both languages are very powerful, offering true closures for instance.
MULTIPLATFORM: Both languages run on many/most platforms.
CROSS-ENGINE: 1 point for JS because it's web-friendly. 1 point for Lua because it's already in the c2d-x project.
Posted 8 months ago # -
wilczarz
MemberRiq, it would be really great if cocos v2 made development of universal apps easier. I know you weren't convinced to the "-ipad" file suffix, but please reconsider. The conditions like "if( iPad ) ... else ..." spread instantly making the code really hard to maintain. And the files to load are not the biggest problem - point translation is a real pain since it has to be done in million places. What do you think?
Posted 8 months ago # -
toadkick
Member@wilczarz: -ipad suffix support already exists in the current develop branch for cocos2d 1.x and in cocos2d 2.0-alpha. In fact I am using it in the project I am currently working on, and it works well. I even took it a step further and have modified that code to fall back on the -hd version if the -ipad version doesn't exist (which I believe is the part that Riq was unconvinced about...fwiw it's working well for us).
Also, I vote for Lua. An interesting note: LuaJIT 2.0.0-beta8 works on iOS and Android (http://luajit.org ). LuaJIT is screamingly fast compared to plain old Lua, which is no slouch itself.
Posted 8 months ago # -
Thanks. LuaJIT looks interesting.
Posted 8 months ago # -
toadkick
Member@rolando: Yeah, I think you're right about that. From http://luajit.org/install.html :
Note: the JIT compiler is disabled for iOS, because regular iOS Apps are not allowed to generate code at runtime. You'll only get the performance of the LuaJIT interpreter on iOS. This is still faster than plain Lua, but much slower than the JIT compiler. Please complain to Apple, not me. Or use Android. :-p
Seems really silly to me to disallow this. I don't really understand why it makes any difference to Apple if you're running interpreted code or just-in-time compiled code :P
Posted 8 months ago # -
zaaroth
MemberThat's a big security hole to be left open. I may be wrong, but JIT means you must allow code to run from data memory pages. Say hello to buffer overflow/heap overflow like attacks that way.
They should be using ASLR as well to prevent simple buffer overflows, but I am not sure (and that does not change the fact that a heap overflow is doable).
Posted 8 months ago # -
toadkick
MemberSure, that makes sense. But couldn't interpreted code also be vulnerable to the same attacks? I suppose since Lua can be sandboxed that would eliminate the vulnerability, but (unless I'm wrong) I thought it was possible to sandbox LuaJIT as well. Also, unless you allow running untrusted scripts, which Apple doesn't allow anyway, I still don't see what difference it would make.
Posted 8 months ago # -
zaaroth
MemberNo, interpreted code means that you read a lua (on this case) bytecode and there is (its not likely this way, but could) an if in an actual code page (probably a codepage that has the interpreter) that contains the assembly that executes the line. This is a rough description, the actual process should be optimized.
JIT means that a specific sequence of bytecodes can be translated into the actual assembly and cached to avoid lookup/translation of bytecodes. That assembly must be stored in a codepage (that is read from disk, i.e.: the app itself) to be ran. Since JIT will generate code on the fly to speed up the process (and so avoid lots of ifs, lets say) you got to store it on data pages (code pages cant be changed by the app itself once it is loaded from disk). Those pages have no X permit (eXecution) to avoid hacker attacks. Only codepages have X permit (in the most common case).
EDIT: Tried to enhance the text a bit. And again. It is actual an easy topic to talk in my primary language :-P
Posted 8 months ago # -
-
Lua is neat until you try using it's terrible C FFI. Unless I'm highly mistaken (which is possible) you can't even store references to Lua objects in C. Whenever you are accessing Lua data, you do so using a reference to an interpreter and a stack index. There used to be ways around it, but the Lua API is designed to make that impossible because the garbage collector is really primitive. So when you want your Objective-C object to store a reference to a Lua object and call code on it... you can't. The only way around this is to make a global variable in the registry for EVERY lua object that you would ever want to reference. O_o
The garbage collector's design also makes it difficult to manage memory allocated outside of Lua. Either you let Lua malloc the memory for you and destroy it as soon as the last Lua reference goes away or you manage the memory outside of Lua and manage the memory manually from Lua. Lua lets you provide memory management functions, so you can work around it's GC by providing a modern one such as libGC and using light userdata. This won't work with Objective-C because you can't use libGC with Cocoa. You also aren't allowed to use the Cocoa GC on iOS. So... sorta out of luck here.
My point being why use Lua when you can use a modern language implementation with a modern GC and a sensible C FFI? Lua became very popular because it used to be pretty much the only lightweight embedable language around, but that's just not the case any more.
Posted 7 months ago # -
I vote for Objc++, there is too many IOS versions already to worry, I don't care about Android, every ppl I talk about androidmarket say It doesn't work to sell(just as marketing), and mobile carriers companies are giving free android mobiles here in Brazil, so these ppl aren't even buying their mobiles, and there are already cocos2d for JS, android, and c++.
So cocos2d-iphone should stay for iphone only, in my opinion, I think it's much easier to develop and it will run smoother if it stays as native port, if you want to migrate to another platform, just port to another cocos2d platform. If I would like to port my game to other platforms, I would do it on Cocos2d JavaScript or on it's native port, and financially, I think the iOS market is the best market for indie dev right now and will stay for some time, it might change, but for now I would stay on iOS only.
Posted 5 months ago # -
InquirerK
MemberI really like everything that Riq has planned for cocos2d 2.0.
I love the idea of leaving behind the past and finally embrace the present with OpenGl 2.0, and focusing absolutely on iOS.But following that same line I would definitely like to see the built-in GameCenter and iAd Support. As those are iOS specific, and not too easy for the little ones like me (I'm just a Designer learning my way onto programing and game development).
And I am with the idea of start anew and with a new name, as some suggested, but I would not go as far as dropping the Cocos2d from the name as that's of historical value, and I definitely like the "2.0" part of the name, as that reflects the OpenGL 2.0 specification. I would suggest though, to go better with Apple design guidelines (less is more), to change the name to something cleaner:
.Cocos2d-iOS 2.0
.
What, at least to me eyes looks amazingly beautiful, and goes with the focus towards iOS, and with Apple's change from "iPhone" this and that, to "iOS" this and that.And I want to repeat that all this is awesome!, and as someone already told: Riq, you're the hero.
Posted 3 months ago # -
Thanks for the feedback InquirerK.
cocos2d v2.0 already has better GameCenter and iAds support. Please, check the new templates. They already come with GameCenter integration.
Regarding the name "cocos2d-ios" perhaps is a better name than "cocos2d-iphone", but it is still doesn't include "OS X".
Posted 3 months ago # -
lol, looks like apple are going to solve the naming problem by moving iOS to the Mac with Mountain Lion.
Maybe have to wait for the next version 'Awesome Monkey' before they fully drop OSX ;)
Posted 3 months ago # -
-
We're working on a project aiming to bind JavaScript and Cocos2D-iPhone together. Please refer to our blog for more information. http://openaphid.github.com/blog/2012/02/20/javascript-and-cocos2d-a-sneak-peek/
Posted 3 months ago # -
@OpenAphid:
Interesting. If I understood correctly, you rewrote cocos2d-iphone in C++ (or are you using cocos2d-x?) and added JS bindings to it. Is that correct ? Or did you create bindings for cocos2d-iphone ?
What are you plans with this project ? Is it going to be open source ? If so, and if you are creating bindings for objective-c, they are going to be a great enhancement for cocos2d.
As I mentioned before, I want to add JS bindings to cocos2d. I have not started yet, but I most probably I will start working on it in March / April.Posted 3 months ago #
Reply »
You must log in to post.