Deprecations about cocos2d-objc HOT 22 CLOSED

I think it may be better to leave functionality we intend to replace in 3.1 out completely or make their APIs private. This way there will be no question about backwards compatibility and it to me feels more like a cleaner approach. I think many (most?) games are probably not using custom shaders anyway.

from cocos2d-objc.

Okay, seems like we kill old deprecations, and make the shaders private.
Are there any other needed classes which will be replaced in 3.1?

from cocos2d-objc.

I think my post timed out earlier, but I was going to say this:

While I know I'm sort of an edge case as far as Cocos2D users go, I can't think of a single project where I didn't use custom GL or shaders at least once. A lot of people who don't write their own GL code still use community made custom drawing code.

I guess I don't really have a problem if we keep the methods in a separate header for deprecated rendering methods. Then for anybody that wants to continue using v2 style rendering can do so simply by including that header, and we can put a disclaimer on it that there will be significant changes to all of the APIs in the header in 3.1. Making it difficult to enable v2 compatibility until then would make a lot of people very frustrated I think.

from cocos2d-objc.

This is agreed, making custom shaders and/or custom drawing methods effectively banned overnight, from an user point of view, would be quite a nasty surprise IMHO.

[web [iPhone msg]]

On 02/dic/2013, at 22:26, slembcke [email protected] wrote:

I think my post timed out earlier, but I was going to say this:

While I know I'm sort of an edge case as far as Cocos2D users go, I can't think of a single project where I didn't use custom GL or shaders at least once. A lot of people who don't write their own GL code still use community made custom drawing code.

I guess I don't really have a problem if we keep the methods in a separate header for deprecated rendering methods. Then for anybody that wants to continue using v2 style rendering can do so simply by including that header, and we can put a disclaimer on it that there will be significant changes to all of the APIs in the header in 3.1. Making it difficult to enable v2 compatibility until then would make a lot of people very frustrated I think.

—
Reply to this email directly or view it on GitHub.

from cocos2d-objc.

@slembcke I think you are a bit of an edge case. None of the projects I've been involved in (these are a number of commercial high budget projects) have been using custom shaders. By putting these interfaces in a private header, we are not shutting anyone out from using them, but at least people will know that they are working with things that are not officially supported and may be subject to change.

from cocos2d-objc.

How about .ccz files? It seems the reason why they exist is twofold. First, Riq put his own header on the front that allowed for future additions of compression algorithms. It's never supported anything other than gzip however. Unless we plan on adding more compression algorithms, this seems wasted. Secondly, the .pvr.gz loading code decompresses into a 512k buffer that is resized as the entire file is decompressed into it in ccInflateGZipFile(). This can be easily fixed by decompressing the PVR file header first to figure out exactly how big the texture buffer needs to be, then decompressing the rest of the file. Then .pvr.gz files would load just as fast as .ccz ones.

Existing tools like Texture Packer already support .pvr.gz output, and any homegrown scripts or tools could be trivially modified since gzip is so universal. It would allow us to simplify the PVR loader significantly if we decide to keep it.

from cocos2d-objc.

I was using custom shaders in my last commercial game however I tend to
think that it's the more advanced users who are rolling them out so I'm
sure they can adapt to any changes in the future anyway. (We should provide
migration notes if it's not fairly obvious).

I use .ccz for all my sprite sheets, the main reason for this is to take
advantage of the encryption functionality in Texture Packer, with a simple
mod to 'ZipUtils.

On 4 December 2013 21:02, slembcke [email protected] wrote:

How about .ccz files? It seems the reason why they exist is twofold.
First, Riq put his own header on the front that allowed for future
additions of compression algorithms. It's never supported anything other
than gzip however. Unless we plan on adding more compression algorithms,
this seems wasted. Secondly, the .pvr.gz loading code decompresses into a
512k buffer that is resized as the entire file is decompressed into it in
ccInflateGZipFile(). This can be easily fixed by decompressing the PVR file
header first to figure out exactly how big the texture buffer needs to be,
then decompressing the rest of the file.

Existing tools like Texture Packer already support .pvr.gz output, and any
homegrown scripts or tools could be trivially modified since gzip is so
universal. It would allow us to simplify the PVR loader significantly if we
decide to keep it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/403#issuecomment-29845139
.

Martin

from cocos2d-objc.

Hmm. A little off topic, but that's another thing to think about if we rewrite some of the texture loading. GLKit isn't going to support any sort of compressed .pvr files, and we should probably make the loading modular so people can implement this sort of thing without patching the Cocos2D source. I'm sure Andreas would appreciate something less brittle too.

from cocos2d-objc.

Just thought I would mention, our textures are actually either JPG or PNG I
just use the ccz wrapper for encryption.

On 5 December 2013 16:51, slembcke [email protected] wrote:

Hmm. A little off topic, but that's another thing to think about if we
rewrite some of the texture loading. GLKit isn't going to support any sort
of compressed .pvr files, and we should probably make the loading modular
so people can implement this sort of thing without patching the Cocos2D
source. I'm sure Andreas would appreciate something less brittle too.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/403#issuecomment-29914786
.

Martin

from cocos2d-objc.

Huh... I didn't actually know you could do that. Skimming the code I'm not sure how that even works now. The only place where ccInflateCCZFile() is called from the PVR loader. The instructions on the Texture packer site says this: "It is important that you change the file format to pvr.ccz - which is currently the only file format that supports encryption." Did you make any other modifications to make that work?

Out of curiosity, what is your personal reason for protecting the assets? I don't have much of an opinion on it myself. I do wonder how many people would think of it as a selling point of Cocos2D if it was built in though.

from cocos2d-objc.

I think that a lot of artists and also the people owning the commercial
rights to those assets would LOVE Cocos2D with that ability built in.

On Thu, Dec 5, 2013 at 5:12 PM, slembcke [email protected] wrote:

Huh... I didn't actually know you could do that. Skimming the code I'm not
sure how that even works now. The only place where ccInflateCCZFile() is
called from the PVR loader. The instructions on the Texture packer site
says this: "It is important that you change the file format to pvr.ccz -
which is currently the only file format that supports encryption." Did you
make any other modifications to make that work?

Out of curiosity, what is your personal reason for protecting the assets?
As a programmer I don't have much of an opinion on it. I do wonder how many
people would think of it as a selling point of Cocos2D if it was built in.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/403#issuecomment-29916790
.

from cocos2d-objc.

I personally have all graphic assets in the encrypted .pvr.ccz format with PVRTC4 image format. It provides smaller and faster graphical assets as well as content encryption. And I definitely plan to use it that way in the future, so it would be nice to have it in cocos2d.

from cocos2d-objc.

@slembcke I just checked my TP export settings, I'm using .pvr.ccz however I'm using Image Format RGBA8888 (for png) and RGB565 (for jpg). PVRTC4 just wasn't crisp enough for rich artwork.
For anyone else for reference: http://www.codeandweb.com/texturepacker/contentprotection

I agree with @Panajev that protection (or at least the feeling of semi-protection) of assets is important commercially and of course to the artists themselves. Although it doesn't really matter for developer art ;-)

Should probably move this feature talk to another issue.

from cocos2d-objc.

Hello people!

Personally, I use TexturePacker to protect graphic content, but built in asset protection will be very appreciated. The reason is that graphics are what differences your game from other games that share similar gameplay or concepts. To me, graphics in videogames are very valuable (I'm a graphic artist too). When you're protecting graphics, you're protecting your identity, your essence, your unique hard work. You're even protecting people from watching game spoilers. Just my two cents.

from cocos2d-objc.

Sounds like we should definitely consider TP compatible content protection when thinking about texture loading changes. We are getting off topic here though and should move further discussion to the texture loading enhancement issue:
#409

from cocos2d-objc.

https://github.com/cocos2d/cocos2d-iphone/blob/develop-v3/cocos2d/ccMacros.h

Anyone have objections to removing the CC_DIRECTOR_INIT and CC_DIRECTOR_END macros since we have a better app delegate class to inherit from now? I think we should deprecate CC_CONTENT_SCALE_FACTOR() now and remove it in 3.1, since the director and textures can have separate content scales. This turned out to be the cause of almost all of the new bugs with the content scale changes, so I think it's good to start discouraging using it directly. Internally I've already removed all of the references to it.

CC_NODE_DRAW_SETUP will almost certainly be removed or replaced in 3.1, so I'll leave that alone.

from cocos2d-objc.

I vote in favour of getting rid of as many macros as possible. I really don't like them.

from cocos2d-objc.

Always remove when possible, there are quite a few in CCSprite...

On 10 December 2013 17:53, Birkemose [email protected] wrote:

I vote in favour of getting rid of as many macros as possible. I really
don't like them.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/403#issuecomment-30251095
.

Martin

from cocos2d-objc.

Does anybody have any issues with making CCDirector.viewSizeInPixels private? It's not generally useful, and it can be derived from CCDirector.viewSize and CCDirector.contentScale.

from cocos2d-objc.

I'm good with making viewSizeInPixels private.

One thing about the deprecations. Now there is a mix of having the deprecations scattered in the code, compared to having them in one single file (CCDeprecated). I think we should decide on one of those and don't mix them.

from cocos2d-objc.

I personally would prefer having deprecated methods in the original headers. That makes is a little easier finding the methods that should be used instead (in case that isn't pointed out in the documentation, which happened in the past).

from cocos2d-objc.

I prefer in original headers as per Apple.

On 18 December 2013 08:24, Ben-G [email protected] wrote:

I personally would prefer having deprecated methods in the original
headers. That makes is a little easier finding the methods that should be
used instead (in case that isn't pointed out in the documentation, which
happened in the past).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/403#issuecomment-30824204
.

Martin

from cocos2d-objc.