cocos2d 2.0 - ideas « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d internals

cocos2d 2.0 - ideas

(153 posts) (67 voices)

Started 1 year ago by riq
Latest reply from riq

Tags:

12…6 Next »

riq
Key Master

Here are my ideas regarding cocos2d 2.x (and cocos2d 1.x):

cocos2d 1.x:

Compatibility (Apple's Technologies):
- works in every device: 1st, 2nd, 3rd, 4th, (5th, 6th,...) generation devices
- works in every supported iOS version: iOS v3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 4.3, ...
- works on Mac 10.5, 10.6, ...
- Xcode 3 and Xcode 4

Compatibility (API):
- API will be backwards compatible. What works in v1.0, will work in 1.1, 1.2, 1.3, etc...

Stable
- No "revolutionary" features will be included in v1.x. They will be added in 2.x

cocos2d 2.x

(Un) Compatibility (Apple's Technologies)
- Only 3rd generation and newer devices will be supported (OpenGL ES 2.0 requirement)
- Only iOS 4 and newer (Accelerate framework, Blocks, integrated fonts, GCD, etc.)
- Mac OS X 10.6 and newer
- Xcode 4 (and newer) only

(Un) Compatibility (API):
- Compatibility with 1.x is not guaranteed. In fact, CCCamera / CCNode will be rewritten (lighter, faster, easier to use API)
- Also, CCNode / CCGrid will be splited (lighter, faster, easier to use API)
- Post processing filters: CCGrid might be merged or simplified with CCRenderTexture. More post processing filters (shaders, and client side effects).
- Will use 4x4 matrix. CGAffineMatrix (3x3) won't be used. Multiplications can be accelerated with BLAS. Matrix will "exposed" (in fact CCCamera will use it).
- Obsolete / Deprecated / Old libraries will be removed:
-> cocosLive (GameCenter or OpenFeint are excellent replacements). User can added it manually if they want
-> FontLabel: Not needed in iOS 4
-> TouchJSON: Not needed. It was a cocosLive's dependency
- It might use "unstable" box2d/chipmunk, depending on the context.

(Un) Stable
- New features like OpenGL ES 2.0 will be supported.
- OpenGL ES 1.1 won't... (although it might be added later) [*] (See below)

[*] Why OpenGL ES 1.1 might not be included ?
cocos2d will do its best to hide the complexities of OpenGL to the end user (like in cocos2d 1.x) However there are scenarios where the user might need to code directly using OpenGL (also like in cocos2d 1.x). If this is the case, the user can use OpenGL directly (like in cocos2d 1.x).
But in cocos2d 2.x, OpenGL ES 2.0 will be used (shaders), instead OpenGL ES 1.1 (fixed pipeline).
Supporting both OpenGL ES 1.1 and OpenGL ES 2.0 will take a lot of development & maintenance time and energy. Personally, I want to focus my time and energy on the new stuff. If someone wants to add support for ES 1.1, you are welcome.

My vision regarding OpenGL ES 1.1 and the fixed pipeline:
- The fixed pipeline was deprecated in OpenGL 3.1 (March 2009) (It is only available as an extension)
- OpenGL ES 2.0 doesn't include fixed pipeline (although most mobile GPUs are implementing the fixed pipeline with shaders, but it is not part of the specification).
- 1 ~ 2 year old devices already support OpenGL ES 2.0 (both iOS and Android devices)
- WebGL is built on top of OpenGL ES 2.0 (no fixed pipeline. It is impossible to use fixed pipeline in WebGL. Also, think of portability, think of cocos2d-webgl).
- Sure, some things are easier to do with fixed pipeline, but they can also be done with shaders (I reckon that sometimes with very complex shaders)
- Shaders means: creativity, new effects, performance

If you are going to learn OpenGL, IMHO, it is better to learn OpenGL ES 2.0 / WebGL, and skip the fixed pipeline functions.

Your views are more than welcome.

Posted 1 year ago #
Pearapps
Member

2.x should maintain as much API compatibility as possible.

Posted 1 year ago #
riq
Key Master

I forgot to mention: If you agree, disagree, has a different opinion; please, explain why / explain the rationale behind your thoughts. Try to be very "verbose". Thanks.

Posted 1 year ago #
Pearapps
Member

Ah sorry. Keeping the API similar will make it easier to upgrade obviously. And the API as it stands is very nice.

Posted 1 year ago #
liquidfire
Member

Hmmm, I not sure what I think about the dropping support for < 3rd gen devices, as they still could be around (Who knows).

I would, however, support it if Cocos2D 1.x would still be supported by some extent (Just occasional bug fixes).

Posted 1 year ago #
andrew
Member

will Apple allow you to sell an app that is incompatible with certain devices?

Posted 1 year ago #
liquidfire
Member

@andrew - Yeah that's allowed, lot's of apps aren't compatible with every device

Posted 1 year ago #
Dragyn
Member

@andrew: Yes, you can specify the features required in your info.plist, including a requirement for OpenGL 2.0. You don't explicitly state what devices it works on - Apple figures it out based on the features required.

@riq: I think that it would be nice if we could have BOTH 1.x and 2.0 supported in the same framework. Perhaps separate templates that include 1.x, 2.0, or both, like how we have the separate templates for box2D, Chipmunk, or pure cocos2D now. Obviously, if an app is doing their own OpenGL calls, then there would be more conditional code around how it is handled for 1.x or 2.0, but that would be on the shoulders of the devs who want to do something more than the cocos2D API handles. No different than the approaches people are taking to integrate UIKit components into cocos2D - not supported by the core, but possible for a dev to implement on top of cocos2D.

I do think it would be a little risky for the continuity of the dev community if we had 2 similar yet slightly incompatible versions of cocos2D actively being used. I think it would put an extra barrier to new devs coming to the community if they had to decide which "flavor" of cocos2D to use. We already have enough splintering from folks using really old versions of cocos2D and the challenges of giving useful advice on a version we aren't using anymore.

I also think it would be a nice feature for cocos2D (1.0 and 2.0) to have some in-built GameCenter support. The forums are flooded with challenges getting GC implemented, so it might be nice to add handling core to the core. I'd say this is a good option for GC only, since it is an official Apple component. This also would be a good way to replace the cocosLive module you want to drop out. Having a high score/achievement system integrated would be a nice feather in the cap of an already wonderful framework.

Posted 1 year ago #
cybergreg
Member

+1 to @Riq's ideas

Posted 1 year ago #
letmeknow
Member

2.0 would be nice if there are:
- built-in iAd, adwhirl, etc support
- multiplayer support
- built-in Gamecenter support
- built-in Cocos leaderboard, achivement and cocos point system (like OF).
- movie clips support (for trailer or cut-scene)

No backward compatible is ok, if you plan to release it next year or a year later.
Currently I don't know how many people using iOS3 and old devices, but since TW can be top without retina support; I believe (in this time) without old devices support developer can't sell much.

Posted 1 year ago #
Steve Oldmeadow
Administrator

@Riq - I agree. The only thing I wouldn't like to see is blocks incorporated into the API like Apple are now doing with their APIs. My reasoning is that blocks are hard to port to lots of other languages. It would be fine to use them internally but I wouldn't like to see it in the public APIs. I'd also like to see consideration given to rewriting as much as possible in C++ or Objective C++, again to aid porting. Finally, I'd suggest a completely new name rather than cocos2d 2.0 - something like cocos2d++ or cocos2d DX.

I also think it would be a nice feature for cocos2D (1.0 and 2.0) to have some in-built GameCenter support.

@Dragyn - This highlights the dilemma Riq is talking about. Game Center only works on 4.1 onwards and not all 4.1 devices are supported. Trying to support older devices would be a huge cost. Even if you don't think development of cocos2d has a cost, there is always an opportunity cost. On the other hand if we simply say cocos2d 2.0 only supports OpenGL ES 2.0 devices running 4.1 or greater then providing Game Center support is simple.

Hardware accelerated maths is the same. This is only available on 4.x onwards. That would mean we would need an alternative solution for 3.x devices. That is a big pain to develop and would probably add very little value.

Posted 1 year ago #
TBBle
Moderator

@Steve Oldmeadow: I assumed those features are why @riq was saying 3GS/iPod3G and iOS 4.x onwards only.

I would like to see a precooked (not necessarily always used, and taking advantage of weak-linking) GameCenter integration, although I've not used GameCenter myself. It just seems like something that'd be handy to be able to get correct once and then be able to enable with a #define or something.

I'm really really against going down the Objective-C++ route; I really like Objective-C, I really like C++, and I really don't like to think about mixing the two. There's both aesthetics and sheer code complication reasons for this. Particularly because I like to mix my C++ with boost smart pointers and whatever neat C++1X features make code more readable, which makes the combination issues much worse.

For portability, a C++ core with Objective-C glue (and then Java-looking glue for an Android port, for example) I'd be OK with, but I don't know that portability to non-Objective-C platforms is really worth the effort in Cocos2d-iOS... I'm not convinced either way. Certainly there's other projects which are more focussed on such things, I thought there was already some effort going on to centralise those developments and try and finalise something.

I'd like the possibility of having block-style functions, since I like using them. Particularly for UIKit animation and NSArray sorting, which is where I've used them before. Much more like a Python 'lambda' expression. ^_^

If cocos2d is going to focus on sufficiently newer hardware, taking advantage of GCD to do more backgrounding would be nice. Asset loading, lazy-loading, and kicking disk-sourced and unused assets back out of memory in low-memory situations would be nice. That'd probably mean more PVR focus for loading performance reasons, perhaps even caching extracted pvr.ccz files to disk as .pvr files for later reloading?

That'd also make the ipadHD effect much more achievable, where you could perhaps reload all your assets when hitting the '2x' button and so get your -hd versions dynamically loaded. I don't however know how the ipadHD effect actually works (is it an iOS thing? Simply doubling the EAGLView window?) so that might be completely unrelated.

I do like the idea of breaking the API with Cocos2d 2. Perhaps even not using CC as the prefix, since I just discovered CommonCrypto also uses it. >_< CC2? C2D?

Perhaps we could fork/rename the whole project to separate it from the cocos2d 1.0 API... "Riq's 2D 2.0"? Then our prefix is "R2D2"!

That said, _I_ have no intention of dropping older hardware or iOS versions, so unless a client specifically says "iOS 4 and 3rd-gen or later devices" I'd be still working with Cocos2d 1 more often than not.

Posted 1 year ago #
MikeSz
Member

Mixed feelings here as well

I'd love to start playing back with shaders - I started gamedev on DirectX 9.c - but this puts a lot more effort on the programmer and makes the development much longer

I'd love to make use of blocks - but at least for now they are hard for me to read and portability suffers

I'd love to forget about older devices - but at for now there's still a lot of them and we always test our games on suite composing of 3G, iPod 2G and so on (Actually I'd love to forget about anything pre-retina and make games just for iPhone/iPod 4 + iPads (forget about 3GS) - that would remove need for all the -hd suffixes)

I know that advancements require sacrifices, I am well aware of that. However - I believe that as indies our strength is not in graphics advancements but in smart gameplay and ideas. I don't want to insult Riq or anyone else in any way and it's not a personal attach - but the truth is that 99% of us cannot compete with hi-tech games coming from EA/GameLoft and others. Our strength has been and will be in pushing new ideas, in making smaller and casual games. I know that having OpenGL ES 2.0 available will allow us to make prettier games, yet I'm not sure if that's all that needed for us - the side effect will be putting much more effort on the graphics side. At the same time - graphics is what the players see on screenshots so our games have to look good ;)

I apologize for the way I write - didn't yet absorb my morning caffeine dose ;)

In any case - Cocos2d has to develop and make use of advancements and a step like this is needed. Just hope the regular Cocos2d will continue to receive some support. If there's no way for Cocos2 to be available on older devices - so be it. But please keep the first version working ;)

As for things I'd like to see in the new version - some GameCenter/OpenFeint integration (maybe with CCNotifications from manu ?), built-in node for advertisements, some other enhancements seen here like CCTable and CCUIViewWrapper... Also easier support for iPad - possibility to add autosuffixing like with -hd on retina. And some tools for more complex GUI - like CCSlider, CCScrollView... I think that incorporating replacements for elements from Apple's UI would make it much much easier to go cross platform

I'd like to sum it all up by saying - Riq, you're the hero

Posted 1 year ago #
abitofcode
Moderator

Perhaps we could fork/rename the whole project to separate it from the cocos2d 1.0 API... "Riq's 2D 2.0"? Then our prefix is "R2D2"!

lol

+1 for no need for backwards compatibility.

Looking forward to the openGL ES 2.0 support :)

Posted 1 year ago #
riq
Key Master

Thanks for sharing your ideas.

Some more thoughts:
- 1.x won't die. It will be maintained, and new features will be added as well (as long as they don't compromise the stability)

- 2.x development already started (see "gles20" branch), and expect a "preview" release in 1 or 2 months, but this won't be the final 2.0 stable release. It might take several months (perhaps more than one year) to have a 2.0 release.

- Game Center / iAd won't be part of cocos2d 2.x, but if needed I'll post some samples regarding how to integrate them. Perhaps adding a new way to initialize the director with a RootViewController (like cocos3d has) will help. A template can be added with iAd/GC support. This template can be added in cocos2d-iphone 1.x too ( Any volunteer ? )

- The aim of cocos2d-iphone (1.x / 2.x) is to maximize the iOS resources, and the decisions taken tries to prioritize that. For example, in 2.x:
-> GCD (Grand Central Dispatcher) + Blocks means: more flexibility, multithread support (think of MultiCore: iPad2, iPhone5??), faster.
-> Accelerate framework means: faster
-> OpenGL ES 2.0: more flexibility, new effects
-> iOS 4.0 has a lot new frameworks / API: Perhaps we can integrate more of them into cocos2d: like Gestures, Gyroscope, etc.

- Regarding Blocks, it is not my intention to convert all the API to Blocks, only where it makes sense. Having both API (blocks + no-blocks) is an option too (Like in CCMenuItem). I don't foresee a lot of "blocks" API... only in a few places. Blocks might be somewhat difficult to understand, but I suggest learning them. They are very powerful (and Apple is using them is most of their APis)

- Regarding c++ / objective-c++: I prefer to keep using objective-c since it is easier to use than c++. cocos2d-x is doing a great job in supporting multiple platforms by using c++, and it is not the intention of cocos2d-iphone to be multiplatform. The C++ STL is a great library, although cocos2d-iphone has some C replacements( utlist, uthash, ccArray). We still might need STL... but whenever possible, I would avoid c++.

- Regarding the namespace prefix: I like CC. I think that many cocos2d 1.x classes will be used unmodified in cocos2d 2.x. But I still don't know... I will have a better opinion once a cocos2d 2.x beta is released.

- Regarding OpenGL ES 2.0: It is not about trying to compete against big companies. It is about maximizing the iOS resources. (Also, the fixed pipeline is dead)

To summarize, I would say that cocos2d-iphone 2.x means:
- maximizing the iOS resources a bit further
- improving the cocos2d API

Posted 1 year ago #
lws
Member

Thumbs up for leaving the older devices behind for a lot to gain. Since technically, one will still be able to utilise the 1.x branch to support everybody with 3.x and/or older devices, I really don't see why the 2.x branch should be hampered by blindly pursuing maximum compatibility. (like Windows for example :p)

Future .. eh .. Present, here we come!

Posted 1 year ago #
zombie
Member

+1 for switching most of the core to c++. This would make porting much more comfortable. Maybe join with the cocos-x guys. Other platforms are getting stronger so I really think cocos2D should move to other platforms too. Objective C makes this harder.

Posted 1 year ago #
dafire
Member

Suggestion:

Make use of the XCode 4 new Workspace feature (like visual studio solutions) and make cocos a libray as default.

Also maybe c++ stuff where it might bring more performance.

Maybe make cocosdenshion an extra library

Posted 1 year ago #
ddeaco
Member

I'm defiantly excited about 2.0 and openGL-ES2.0. The iPhone 5 launch no more that 6 months away will. Which will also mean that the iPhone 3G wont have been on sale for 2 years, and not been the best model for 3 years. So backwards compatibility must becoming less of a problem? Does anyone have any app data for the percentage of there users that still run models that don't support openGL ES 2.0?

As mike suggested I would quite like to see some of cocos2D extensions becoming official and part of the main bundle, eg CCNotifications, CCTable ,CCUIViewWrapper, CCSlider, CCScrollView.

Cocos2D 2.0 - I don't think there would be much benefit from changing the CC Prefix. As for the shaders it would be cool if there was a base library in the bundle but then part of the site where people could upload and share there custom shaders.
A bit like this - http://resources.maxwellrender.com/visual_catalog.php?t=#page=1

GameCenter Multi-player suggestions - I've haven't implemented any networking code yet but its something that I am really wanting to move into. A cocos2D/GameCenter integrated example/solution would be amazing. Especially if it wasn't just turn based multi-player but synced players physics worlds... This could even be something that could be sold as a new product on sapusmedia.com.

David

Posted 1 year ago #
Verisutha
Member

I am on the fence as well.

The biggest comment we got from people at GDC was when we pulled out a 2G iTouch and demo'd the game to show how well it played on older devices and see the same performance on a 4G the one comment we would hear so often is..

"This is awesome, almost nothing plays on my 3g/2g..."

I think there are a lot of them out there and to ignore them leaves a fairly large and untapped market. Having 2 forks with different API calls might be a little rough. It would be nice to be able to support higher end calls if the device supported it, but I would imagine the coding complexity would be huge.

On a side note I don't think Riq should concern himself with things like GC, OpenFeint etc.. It would serve better to focus on what cocos is strongest at.. being a 2d engine. Let someone else code a front end for the other things, just as people have done in the past.

Posted 1 year ago #
slipster216
Moderator

-1 on GameCenter, etc support as part of Cocos2d. If people want to roll and maintain standard extensions for this stuff that are included in the repository then great, but it shouldn't be part of the 2d engine. Same for multiplayer, etc..

A more complete menu system would also be nice.

Standard XML formats for things like animations, etc, would enable more editors to be created without custom code.

Of note, I expect to move to cocos2d++ on the next project, as I'm getting a lot of requests for cross platform titles, and long term that seems like the only way to manage the sanity. I think there is a lot of merit to keeping this in mind when working on the APIs for 2.x.

Posted 1 year ago #
MikeSz
Member

Yeah, there's still quite a large crowd running older devices. I was looking through bug reports we receive from users (I'm adding a little diagnostics to the mail - with OS and device type) and definitely a lot of them are still running older devices. Just found one mail from 1st gen iPhone ;)

So as I said I'd be very happy to see some way of having both systems working, maybe even from same binary ? But I have no idea how that would work :(

I think as a community we could provide support for GC, OF, ads etc that would be easy to use and kept up to date, with tutorials and stuff. Cocos2d could be engine itself, that can be easily extended by simply adding handlers for above-mentioned things. "Community approved" extensions would make it a breeze to help others find problems in their code

Posted 1 year ago #
cjl
Member

@slipster216:

Are you referring to Cocos2d-X? Is near as I can determine there is an abandoned project named Cocos2d++, but Cocos2d-X is actively supported.

Anyway, I agree a move to C++ , while unlikely, would be great for portability to Android, now that NDK R5 seems to have added a lot of the missing pieces.

Posted 1 year ago #
SDKTutor
Member

I don't think we should move to c++. Yeah, it might be nice to port stuff over, but I'm sure a lot of developers here don't know c++ or want to port over their game to other platforms.

Posted 1 year ago #
riq
Key Master

Quick Thought: I would not integrate c++ in cocos2d-iphone to be more cross-platform friendly. That is the raison d'être of cocos2d-x.
So another possibility is to develop cocos2d 2.x using cocos2d-x. I would focus on iOS stuff, and it would be cross-platform since everything will be c++

Posted 1 year ago #
liquidfire
Member

One thing that would also be a nice addition would be a much more extensive documentation reference, similar to Apple's with examples, a description of th method, related methods, related example code, description of parameters, retval, etc.

What we have now is good, I just think it could be a bit better, and would hopefully also reduce the number of "Hi can I have an example codes showing how to do this feature" posts on the forum.

I understand that this would be a lengthy task, and I would be willing to work on it if other people think it would be helpful as well.

Posted 1 year ago #
zombie
Member

Cocos2D as a wrapper for Cocos-x sound good. But the question is why there must be a wrapper. I think the time for this could be used better for user stuff. Objective C or C++ or Java is not so much of a difference. When you know one, you know all :)

Posted 1 year ago #
riq
Key Master

@zombie: I'm not thinking of building a wrapper over cocos2d-x, but directly developing cocos2d 2.x using cocos2d-x... everything in c++. The more I think about it, the more I like it.

option a) develop cocos2d 2.x as a natural extension of cocos2d 1.x (mentioned in the 1st post)
+ It will take full advantage of iOS resources: blocks, Accelerate.framework
- it won't be cross-platform (basically no Android).

option b) develop cocos2d 2.x in cocos2d-x.
+ it will be cross platform (iOS, Android, Wind32, Mac, bada? )
+ / -: it is still possible to take full advantage of iOS resources, including Blocks (since blocks is not an extension of objective-c, but of c), but the blocks API won't be cross-platform since not all compilers supports it. But we could still use the Accelerate.framework, and other iOS only frameworks, but some #ifdef are going to be required.

Posted 1 year ago #
toadkick
Member

+1 for cross-platform for me if possible. I know that makes things more complex, but boy would it be nice to be able to port to other platforms without having to rewrite everything. I would happily sacrifice supporting older iOS devices if I could port to Android et al with minimal fuss.

of course, there are some things about objective-c that I would really miss (*ahem* reflection) if everything was switched over to a c++ framework. (full disclosure: I am not a fan of c++, but it's unfortunately a necessary evil :P)

Posted 1 year ago #
lws
Member

Wasn't programming for Android done in Java?

Posted 1 year ago #

RSS feed for this topic

12…6 Next »

Reply »

You must log in to post.