you right! I was blind or something... Thx a loot!!!But error reather strange...

I'm using the version of the Gaussian blur topic in my 1.0 project without any compile problems.

I see what causes the problem, Lam uses _ as affix, while CCTexture2D uses it as suffix, _size or size_.

Yes, I looked at this tread. But for me problem is (right now;) not related to image data, but for variables with image parameters inherited from CCTexture2D:

GLuint name_;
CGSize size_;
NSUInteger width_,
height_;
CCTexture2DPixelFormat format_;
GLfloat maxS_,
maxT_;
BOOL hasPremultipliedAlpha_;

All those are "invisible" in CCMutableTexture2D - so I'm unable to even compile example.

I see I remembered incorrectly, the changes made to CCTexture2D were to keep the pixelData around.

@JanuszNSG, Have you looked at the Gaussian blur thread as well?

Any Ideas? Please!
I found some description with same problem on net. But solutions simply don't work or are some kind of workaround (eg. redeclaration CCTexture2D variables in CCMutableTexture2D). Right now my mutable object can't "see" variables form Texture2D (tested on cocos2d 0.99.5, 1.0.0 rc and 1.0.1), on new project etc. Maybe my environment is a problem, I'll still use Xcode 3.2.6 and iOS 4.3...

I'm starting thinking about some curse over my head, as far as I can see, in CCTexure2D between versions 0.99.5, 1.0.0rc and 1.0.1 is no any differences. Making those variables public manually don't changes a thing:(
Additional as far as i know, to variables in base class can be even private to access them form form inheriting class.

In version 1.0 CCTexture2D was changed to make a few variables public that CCMutable2DTexture needed to access. If you don't know what to change, try to replace your CCTexture2D with the one of 1.0 or a higher version of cocos.

Any idea why CCMutable2DTexture can't "see" CCTexxture2D inherited variables?

All "undeclared" variables are from CCTexture2D, but class CCMutableTexture inherits form CCTesxture2D, all looks ok, but don't working:(
sorry about "post after post":( but I'm little confussed:(

ok, problem with Texture2DPixelFormat solved, sholud be CCTexture2DPixelFormat, but variables still causing errors:(

@geertjan88 - check coordinates simply Loging them, see where is a 0,0 in both systems, you will quiclky see where is a problem.

Still not working, after creating brand new project on cocos 1.0.1, only adding CCMutableTexture as an #import to HelloWorldLayer I recieve 33 errors. Still missiong definition of "Texture2DPixelFormat" and a loot of variables (_foramt, _siez, _width etc). As far as I can see, those veriables have no declarations in code. What I'm doing wrong?

I am having trouble with the location when using ccmutabletexture2d. If i use

CGPoint location = [touch locationInView:[touch view]];

or

touchStart = [[CCDirector sharedDirector] convertToGL:location];

the pixel doesn't change were i press. How come? I am programming on ipad in landscape and the texture is exactly 1024x768 and in the center of the screen.

Yes, but I use those version, due to limitation of my mac. And as far as I know this is a stable version (only older), additionaly CCMutableTexture2D which I use is dedicated to this version (or slighty older 0.99)
But will try anyway:D

Nope. The latest stable is 1.0.1. 0.99.5 is nearly a year old now.

As I wrote, done this. Brand new project with cocos2d 0.99.5 (all ok), adding only CCMutableTexture2D and AsyncObject and only import CCMutableTexture2D causes those errors.

Why start an empty project with anything other than the latest stable version? I would try that first to see if it was just written against some new feature.

Hello to all:)
I have strange problem with compiling CCMutableTexture, even in empty cocos2d project, is I add both files recieve 41 errors.
Eg.
- Not known Texture2DPixelFormat
- a lot of undeclared variables (_size, _width ...)

I'm using cocos 0.99.5 and XCode 3.2.6 - meybe there is a problem?

@Lam will know for sure, but, as far as I know, the mutable texture is a rather untested class. Even though lots of people make use of it one way or another, it is not guaranteed to work through automated tests of the framework, so it might break during an upgrade.

Since 2.0 is really in its early stages it is not unexpected that it does not work.

@Lam: I have already tried everything on importing you class and I forgot to tell you that I'm using the alpha release of cocos2d with versioin 2.0 but I got a lot of errors one of those is the undeclared identifier for the variables below:

case kTexture2DPixelFormat_RGBA8888:	bytesPerPixel_ = 4; break;
			case kTexture2DPixelFormat_A8:			bytesPerPixel_ = 1; break;
			case kTexture2DPixelFormat_RGBA4444:
			case kTexture2DPixelFormat_RGB565:
			case kTexture2DPixelFormat_RGB5A1:

Please advice.

Edited: Never mind I got it already, I've just realized that they changed these variables to eg. kTexture2DPixelFormat_A8 => kCCTexture2DPixelFormat_A8.

@seecah.khing
Yeah this should be doable with mutable texture. Just make sure to search the forum and try out the examples to see if you figure out the basics of using the class first.

@Lam: I wonder if I can use this one for coloring a sprite. I need to like painting a sprite through the fingers just like Color Me. I'm still so very new in cocos2d and hopefully you can guide me through. Thanks

I do extensive manipulation on full screen images ( iPhone ), and by far the fastest approach I have come up with, is copying the entire screen buffer ( in my case live video ) to a memory buffer, doing the manipulations on this buffer, and then render it, using glTexSubImage2D.

Copying the entire screenbuffer, is much less costly than you would think. It uses DMA and does not halt the render pipeline. Just a few glReadPixels will be just as time consuming. I have read people saying, that glTexSubImage2D is slow. I dont think that is the case, it should be just as fast as any other image rendered by OpenGL. Probably what confuses people, is, that when they use subimages, it is easy ( just like with glReadPixels ) to mess up the render pipeline, and kill performance.

My 2 cents anyways.

EDIT:
Maybe I should add, that depending on needs, it might be an option to copy the entire content to an offscrren OpenGL surface. That would be quicker if you had a lot of stuff to render. I do a lot of reading data, but no offscreen rendering, so in my case I have no use of an off screen OpenGL surface.

@Lam: Thank you so much for the guidance.. I'll check this out.

@seecah.khing
Just do a forum search for "CCMutableTexture". There's quite a lot of posts of people with example code for it.

Here's one example of gaussian blur from manucorporat. Maybe that'll be easy to see how the class is used.
http://www.cocos2d-iphone.org/forum/topic/6315

@Lam: Any progress on this? This stuff is very useful but I can't let it work. Would you mine sharing a sample code using your API. My apology since I'm still new to Cocos2d.

Thanks a lot!

oh haha whoops sorry guys. Didn't notice the questions.

I wonder if mutable texture should take care of premultiplied alpha or should the decision to change blend func be on the programmers end.

If Apple's improved the glTexSubImage that might be an improvement over a direct call to all pixels. I have to take a look at it when I have the time (sorry not much time these days on my end) but I'd have to do some extensive testing just to make sure that the alternative is actually efficient.

Any new solution about this?

@Lam Btw, Have you gotten around to optimizing the code with glTexSubImage? I tried a similar thing by maintaining a dirty rect and applying it on draw. Never worked. :-(

Shouldn't setPixelAt:rgba: premultiply the rgb with a? Or does the method expect premultipled colors? Similarly shouldn't pixelAt: undo the premultiplication (which is unfortunately lossy, of course)?.