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 😉

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.

Some things are different

I have realized that I sooner or later would run into something in RummyFight-Android that isn’t possible to recreate on RummyFight-iOS in the same way. I have so far been surprised at the 1:1 ratio of most functions but now I’ve stumbled upon a thing I need to rethink.

Well, it’s actually more than one thing.

It’s the listboxes in the Lobby… and also in the NewFight. They are pretty neatlty built codewise with several objects inheriting each other, sprites attached on top of sprites, dynamically created bitmaps etc. Now the problem I’m facing is such a trivial task as to strech a bitmap in X and Y. On AndEngine this was really simple. It was just a matter of setting myBitmap.setSize(100,50); which meant that regardless of the original size of myBitmap it was then stretched to be 100×50 without changing it’s scale factor.

The problem is that there is no existing function in Cocos2D doing the exact same thing. Sure you can use scaleX and scaleY to make something similar but it’s a zoom function which means that if there is some other object (like a text) attached to myBitmap it is scaled too and I don’t want that.

So maybe I will have to create a solution based on a totally different approach. I do need something similar though since a stretched bitmap is essential for the listboxes. It is the surface that all the listitems are attached to making them all scroll together when swiped.

There is however something in Cocos2D called contentsize. I will take a look at this later tonight. It might provide something I can use.

But besides this, the app now manages to login, fetch match list, update buttons, display ticker text in the top, create list boxes, populate them with match info and display them on the screen. Too bad however that because of the stretching problem the lists are displayed in 20 times zoom meaning that one single item uses up the whole screen 😉

But hey, you can’t have everything.
Cause where would you find the place to store it?

Things are slowly coming alive

Step by step, it’s starting to look like something familiar

.

I’m in my blind spot

Sometimes as a developer you encounter periods where you code a lot without having the possibility to test your code until it’s completely done.

I’m in that period now.

Since two days, I’ve been coding and coding and coding and there’s no way for me to test a single line of code until the whole puzzle is complete. That’s a bit scary and if something doesn’t work, it will be quite a challenge to find out where the fault is (faults are).

So what I’m doing is that I’m building all the base functions of the Lobby. This includes fetching the list of fights, parsing them into an array of match-objects which in turn creates arrays of player-objects, sorting the matches, setting the flags, handle timers, doing logic, etc. It’s not until all objects and functions are included that I can even try to fetch any data to see what happens.

But it’s fun. Objective C still sucks like hell but at least I know how to suck it now. Also, Cocos2D is a great help. That’s a library constructed the way someone sane would do it.

One more thing I created yesterday is my very useful Fetch-class. It’s really quite clever. You create a new Fetch-object, give ut an URL and parameters, tell it to Execute which means it will start a background process doing a http post (which is blocking so you don’t want to do that on the main thread). When done, it makes a callback to a named function in a specific class that takes care of the result. Viola! Done.

But then again… I haven’t been able to test it yet.
Cause I’m in my blind spot.