Making some progress

After seven sorrows and eight miseries, I finally managed to get the basics of NewFight in place. Despite the fact that I previously got the Lobby working with similar listboxes there were still issues in the NewFight that was tricky to complete.

Even though the listboxes look similar, there are a lot more functionality in the NewFight ones since you can pull an item out of the box and put it on the table. One more problem was the AnyPlayer-item which in fact are three items on top of each other, meaning that the list should not contract until all three are pulled out.

But anyway, to make a long story short I finally did get the bloody thing working as well as having the ticker text running at the top. I even improved it some compared to the current Android version by having it update the pool status every 15 seconds instead of only once. This is something I will add to the Android version in the next release… which I’m thinking about working with tomorrow. It’s due time for an update there.

So what have I learned about iOS-development lately then? Mostly that I’m still not quite friends with the alloc/dealloc issues in it. I don’t get any memory crashes but I suspect that the app is leaking some memory here and there. Nothing serious since it’s just small strings and little data but I believe I must find some way to monitor memory soon before I make the same mistake everywhere.

I end with a little screen, showing that there indeed are progress in the makings.

As is evident, there are still no profile pictures in the list. That is because I haven’t created the http file fetch functions yet. I don’t even know where to store downloaded pictures yet on an iOS-device but what the hell. There should be somewhere where they can be saved.

What is also evident is that our new designs are not in place yet.
New designs, you ask?
Sure. Of course we will work on the visuals too 😉

Advertisements

To alloc, dealloc, retain or copy

Phew, I think I’m finally beginning to understand the memory allocation and deallocation issues in Objective-C. In Java this is something you never have to worry about. If you need a string object, you just create one and put some characters in it. Then you use it until you don’t need it anymore and then the system will dispose it in the garbage bin automatically. Very convenient, albeit a bit lazy.

In Objective-C you will have to take care of all this yourself. When you need a String object, you first allocate it, then you populate it with characters and make sure it sticks around until you don’t need it anymore. Then you manually will have to dealloc it.

Ok, sure. No problem for someone like me with roots in C/C++ then? Or?

Well, Objective C is not quite as simple as C/C++. In there you knew that “if you alloc, you need to dealloc” and “after you have alloced, it will exist until you die”.

Objective C is somewhere in between. It does follow the rule “if you alloc, you need to dealloc” but it also have objects that exists for a while. Take a string as an example. If you need one containing the words “I’m a black cat” you can do it this way:

NSString *MyString  = [NSString alloc];
MyString = “I’m a black cat”;

This will create a pointer and space in memory for the words and it will live until you do a [MyString dealloc] on it. However  there is another method:

NSString *MyString = @”I’m a black cat”;

This creates a temporary string which will automatically be dealloced by the system whenever it feels it’s ok, usually at the end of the scope it was created in.

Now this is both useful and dangerous because if you do something like this:
NSString *oldString;
NSString *newString = @”Hello there”;
oldString = newString;

Then oldString will point to newString and when newString is dealloced, so is oldString.
You must be careful with this. However there is an easy solution for those who need to do something like the above. Use the copy keyword:
oldString = [newString copy];

This simple creates a copy of newString and tells oldString to point to it. 

At least this is my current theory 😉 We’ll see later on if this also works in the long run. I will have the emulator running during the night with the Lobby refreshing itself every 30 seconds to see if it goes out with a bang somewhere.

It would be nice if it didn’t because it’s starting to look quite good (if you ignore the fact that the iPhone 3Gs has less resolution than an Amiga 500 from 1987)

 

Had to rethink

To solve the issue with the inverted coordinate system in Cocos2D and the impact it has on my ListBoxes in the Lobby and in NewFight, I had to rethink and find another solution that still would look the same.

And I think I have done it now. Except for a couple of small problems regarding the swipes of the lists, it all works as it should now. The fights are there, the labels are there, the actions when clicked are there, the alert boxes are there etc.

So as soon as I have managed to fix the remaining issues with the swipes, I’m actually done with the Lobby.

Next stop: NewFight.

I’m so irritated right now

I never could have imagined that my biggest enemy at converting RummyFight to iOS would be the upside down coordinate system in Cocos2D. It might sound trivial that things are drawn from the bottom to the top instead of the top to the bottom but imagine this:

On Android, I created a pretty neat solution for the listboxes in the Lobby and in the NewFight-sections. To be able to swipe several objects up and down at the same time they were all attached to an invisible surface which the swipes moved up and down making all the attached objects to move up and down too.

This was made possible by having the invisible surface grow and shrink according to the number of items that were on the list. If there was 20 fights, then the surface was 20*ItemHeight high with fight #1 attached at the surface’s 0,0*ItemHeight. Fight #2 was attached at 0,1*ItemHeight etc. Since the surface grew at the bottom when a new fight was attached, it was easy to calculate the positions of the fight items.

Now since Cocos2D’s coordinate system grows upwards I must attach fight #1 to 0,SurfaceHeight. Fight #2 to 0,SurfaceHeight-1*ItemHeight etc. Now this sounds easy enough. Just a matter of adding one more variable to the equation.

But what happens when I grow the surface after I have added fights to it? The new space is created ABOVE the first fight instead of at the bottom, meaning that I must reposition the surface and also reposition all items on it… everytime the surface’s height have changed and this happens a lot.

And it looks like shit. Everything is jumping around since all items are pushed down at first, then pulled up again when I reposition them.

It seems I must think in a totally different way now. I need to look at this from another angle.
Maybe if the coordinate system is backwards, I must think backwards too.

Why oh why did the authors of Cocos2D choose an inverted coordinate system compared to how the screen is built? I seriously hope they had a VERY good reason for it because it’s driving me nuts!

Touch events

Touch events are really fundamental in a game where you are supposed to drag and drop tiles all over the place. I am very proud of the code I created in the Android version for the handling of touch events including logic wether an object can be dragged or not etc.

Naturally I wanted to have as much of that logic intact even in the iOS-version, otherwise I will have to start all over again with all testing. Now the problem is that AndEngine and Cocos2D handles touch events differently.

AndEngine is very kind to a developer since you can register touch events to an object meaning that AndEngine itself can figure out what you are touching and alert that specific object. In Cocos2D you can only register a touch listener to a complete layer. It’s then up to you to figure out yourself if / what object that was touched and alert it accordingly.

But I figured it out eventually. I made a few new subclasses, implemented a “isObjectTouched()”-function and am now sending the touch events to the tocuhed object meaning that I can reuse almost all of my existing logic regarding touch, drag and drop.

Now… if only the coordinate system hadn’t been upsidedown.
Sigh!

Looking a little better

Starting to look like something but it takes a lot of time converting between the two coordinate systems that are up side down from each other… and the fact that all sprites in AndEngine uses it’s topleft corner as it’s position but in Cocos2D it’s the center that is the position.

Ah well, why would something be easy?

Looks like shit…

Looks like shit… but at least the data is there now.
Tomorrow I will begin resizing all the bitmaps to fit the lower resolution of the iPhone.

But don’t worry. Of course we will make the game look good on both the standard iPhone resolution and on the retina displays. However we will design it for the standard resolution at first and then add higher resolution bitmaps for the HD-version since Cocos2D har good support for this.

So tonight I will take all our existing bitmaps and shrink them by 60% because that is the resolution of the $499 iPhone compared to the $100 Android.