cocos2d v0.99.0rc released « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

cocos2d v0.99.0rc released

(17 posts) (7 voices)

Started 2 years ago by riq
Latest reply from vargonian

Tags:

riq
Key Master

Hi,

I'm happy to announce that v0.99.0-rc is available for download:
http://cocos2d-iphone.googlecode.com/files/cocos2d-iphone-0.99.0-rc.tar.gz

Release Notes:
http://www.cocos2d-iphone.org/wiki/doku.php/release_notes:0_99_0_rc

New from v0.9-beta:
- iPad compatible: cocos2d and the cocos2d tests work in any screen size (480x320, 1024x768,...) (please read the iPad SDK to learn how to create 1024x768 projects)
- Uses Chipmunk v5.1 and Box2d r39
- New Camera: easier to use, more feature but also with new limitations
- Improved speed in different components: Actions, Scheduler, BitmapFontAtlas, Camera, Node, Sprite, Touch Handler

Full Changelog
http://cocos2d-iphone.googlecode.com/svn/tags/release-0.99.0-rc/CHANGELOG

Migrating from v0.9-beta2:
Please read: http://www.cocos2d-iphone.org/forum/topic/4145

What's next:
- v0.99.0 (final). No new features will be added, only important bug fixes, or opportunistic fixes.
- Scheduler improvements, Blocks and other features will be added during the v0.99 series

Many thanks to all the developers / contributors / beta testers!
http://cocos2d-iphone.googlecode.com/svn/tags/release-0.99.0-rc/AUTHORS

This is a Release Candidate version. It means it is not yet the "final" v0.99.0 version.
Unless something is totally wrong, there won't be any changes in the API.
No new features will be added (unless "opportunistic" ones)

I would appreciate if you could test this release with your game and report any bug that you might find.

Thanks,

Posted 2 years ago #
kalx
Member

As usual, looks like a great release Riq. Just wanted to say thanks to you and all the other contributors. Cocos2d has improved a lot since I first started paying attention to it 6-7 months ago :)

- kalx

Posted 2 years ago #
crmagicxxx
Member

Thank Riq. I already tested r1755 and I can only tell it works beautifully

Btw, why there is this name discontinuity from v0.9.0-alpha, v0.9.0-beta, v0.9.0-beta2 and now it's v0.99.0-rc... I mean why number 99? :)

Posted 2 years ago #
riq
Key Master

@crmagicxxx:
v0.99 means that we are very close to v1.0 :-)
v1.0 will be API compatible with the v0.99 series.
v1.0 will be a maintenance release of the v0.99 serie.

eg:
v0.99.0 -> v0.99.1 -> v0.99.2 -> v1.0

Posted 2 years ago #
crmagicxxx
Member

@Riq

OK, so there will be not something like 0.99.9.1? :)

Posted 2 years ago #
gogokodo
Member

Nice work riq going to test it out right now.

Posted 2 years ago #
riq
Key Master

IMPORTANT UPDATE:

If you see some borders on your images, please update to SVN r1761 or just replace the CCSprite.m file with this one:
http://cocos2d-iphone.googlecode.com/svn-history/r1761/trunk/cocos2d/CCSprite.m

Posted 2 years ago #
Steve Oldmeadow
Administrator

I had one issue with accessing CCFileUtils::fullPathFromRelativePath. It is using the shared instance of CCConfiguration which assumes an OpenGL context is in existence but this is only true if the Director has been attached to a window.

In my case I was loading my audio files which uses CCFileUtils, I just moved the code so that it executes after the Director is attached.

Posted 2 years ago #
andyburke
Member

I hit the same problem with the CCConfiguration and OpenGL. I was also preloading audio. I, too, had to reorder my code. :(

Posted 2 years ago #
riq
Key Master

@steve, @andy: Thanks for mentioning that. Yes, the sound should be loaded after initializing the opengl context.

Posted 2 years ago #
andyburke
Member

I am also seeing a strange problem between Debug and Release builds in 0.99-rc:

I am using the setTextureRect function on CCSprite to draw a progress bar. I have two sprites, one laid over the other. My foreground sprite is my filled-in progress bar. I was setting the texture rect based on the percentage it was full. This was working in 0.9.0-beta2.

Now, disturbingly, it works as it did in 0.9.0-beta2 when I build in Debug, however it does NOT work properly when I build in Release. The foreground texture is offset up and to the left as it is revealed by the calls to setTextureRect. I've looked at the code for something that might be getting optimized out, but I don't see anything obvious. Any help would be appreciated.

Posted 2 years ago #
riq
Key Master

@andyburke: Could you post the code to reproduce it ? thanks.

Posted 2 years ago #
andyburke
Member
```
float percent = 0.5f;

  CGRect r;
  r.size.width = m_SlowDownMeterBackground.contentSize.width * percent;
  r.size.height = m_SlowDownMeterBackground.contentSize.height;
  [ m_SlowDownMeter setTextureRect: r ];
```
I am setting the width and height off the 'background' meter because it's the same size. It would be nice if there were an untransformed contentSize that I could query. For instance, an 'originalSize' would be nice.

Essentially, I'm trying to set a rect that is smaller than the image to keep from drawing the whole thing. Hopefully this should be pretty easy to reproduce.
Posted 2 years ago #
andyburke
Member
Man, am I dumb. I should have known this was an initialization problem. Making sure I did:
```
CGRect r = CGRectZero;
```
.. in my code solved the problem. Weird that I wasn't seeing this before.

On a now unrelated note: I am not very familiar with Objective C's performance wrt passing pointers, returning structures, etc. In C++, it would be faster if CCSprite::getTransformValues took a transformValues_ struct by reference than to return one on the stack and incur the copy to assign it.

I changed getTransformValues to be as follows:
```
-(void) getTransformValues: (struct transformValues_*) tv;
{
	tv->pos = position_;
	tv->scale.x = scaleX_;
	tv->scale.y = scaleY_;
	tv->rotation = rotation_;
	tv->ap = anchorPointInPixels_;
}
```
And the usage looks like:
```
struct transformValues_ tv;
  [(CCSprite*)p getTransformValues: &tv];
```
This should be faster in C++, I'm not sure if it would be in Objective C, but I have to assume it would be since there's no copy happening.
Posted 2 years ago #
vargonian
Member

"Scheduler: removed support of repeats. Postponed for v0.99.1 (rolling back issue #630)"

Ouch, this caught me off-guard. No big deal though; for an action that I want to schedule in the future, but only once, would a CallFunc action be appropriate instead?

Thanks!

Posted 2 years ago #
riq
Key Master
@andyburke: yes, passing pointer is faster than returning a whole struct. I'm returning an struct just be "compliant" with objective-c, but I might modify that private method if it is needed.

@vargonian:
To schedule a method only once you can do:
```
[self schedule:@selector(myMethod:)];

-(void) myMethod:(ccTime)dt
{
   [self unschedule:_cmd];
   //  what ever you watn
}
```
Posted 2 years ago #
vargonian
Member

@riq: Fascinating, I didn't know Obj-C in-depth enough to know that use of "_cmd". I learn something new every day. Thank you for that.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.