The progress continues

Today I have implemented the menu with buttons that is used at several places in the app. In the fights you have the Sort functions, access chat etc so it’s a must have. The interesting thing is that Android devices have a physical Menu-button and a built in menu handler but since iPhones don’t we need to have both a visual button in the interface whenever there’s a menu to use and a custom made menu object to take care of the buttons.

Anyway, it’s in place now and it works. This means that I have finally been able to test the sort functions and the replay functions and besides some memory failures I fixed, they now work as they should.

Memory… yes. 
That’s a real pain in the ass when it comes to Objective C. However I do think I begin to understand it finally. The bad thing is that everything I have coded so far is wrong so I need to go through all code now to make it work right. I don’t want leaking memory or an app that crashes every 10th time it’s used.

But to sum up, I can tell you what I’ve learned so far.

1. Whenever you alloc something, make sure to release it too but NEVER dealloc it directly. This is something Objective-C will do for you as soon as the retain count is zero. Trust Objective-C on this.

2. If you have an object which you send another object to (like a NSString or an array), make sure to either retain it or copy it. I have found that I prefer to copy strings since I then know that they are solely owned by the object and that noone else fiddles with then anywhere else.

3. There’s a HUGE difference between using Name = @”Kalle”; and self.Name=@”Kalle”; in a class. In the first case Name will pointing to the string “Kalle” which is an autorelease object (that’s what the @ is for). In the latter case Name will use the method defined in the @property definition of the class. This means that if you have written  @property (copy) NSString *Name; in the class definition and then use self.Name = @”Kalle”; your variable Name will point to a COPY of the string “Kalle” instead of the autorelease string containing “Kalle”. I hope you see the difference.

4. When adding objects to arrays, you can (and should) release them afterwards since the array owns them now. Example:

Tile *pTile = [Tile alloc];
[MyArrayOfTiles addObject:pTile];
[pTile release];

Line 1 allocates one instance of a Tile and gives it retain count 1
Line 2 adds pTile to MyArrayOfTiles, increasing it’s retain count to 2 (object is owned both by the array and my main function)
Line 3 releases pTile in my main function, which leaves it owned by the array with a retain count of 1.

This is good since if we do [MyArrayOfTiles removeAllObjects], all tiles added to the array receives a retain count of 0 and is then deallocated by the system.

Are you confused yet?
I know I am. Thank god all this shit does not apply to simple numbers and similar.

More to come but now it’s time for bed.

First meld done!

Today has been a good day. Besides identifying and correcting several generic errors I have made in regards to memory management, I have also been able to add much of the basic functionality in the fights so now it is possible to meld, get a new tile, pass, reset and undo. This means that it is now possible to actually play using the iPhone app.

I have also managed to add support for the Themes and it seems to work even though I haven’t yet implemented all controls to check if the bitmaps are valid etc. One nice feature of the themes is that they are now resized at the server before being sent to the app. This is useful since the iPhone 3GS only have about 60% of the screen size of the themes so why send something almost twice the size to the app?

This new feature I will implement as soon as possible in the existing Android version too since there are devices out there with a low resolution too and they probably have a small internal memory too which will make RummyFight for Android a little less resource hungry.

Now I will take the rest of the night off. Tomorrow I will focus on implementing the menu of the app. Otherwise it will be difficult to sort tiles, access chat etc.

But this is what the app looks like now. I kind of like it.

Thread issues

Today I encountered something that *might* become a problem unless I find some neat workaround. It seems one can’t create texts in Cocos2d from another thread than the main one. This is really not so good since the RePlay must run on a background thread due to the fact that it can take several minutes to finish. You don’t want to block the main thread for that long.

So either I must rewrite the whole RePlay routine to work on callbacks and timers instead (yuck) or there might be some kind of workaround by forcing the text specific calls to be run on the main thread.

Because it really can’t look like this, right?

Edit: Yes, found a solution. There’s a way in Objective-C to tell something to run on a certain thread other than the one you’re at so i encapsulated the calls where there are texts involved inside that strange dispatch-call. I have no idea how it works but I don’t care either as long as I can use it 😉

Looks a lot better now, right?

Slowly, things are coming alive

Today has been a good day. Lots of logic implemented and also some visuals.
Now the buttons are in place and also the logic that tells them when to be grayed, visible or active. Same goes for the players at the top where also the logic is in place to show whose turn it is, etc.

There is however an issue I must take a look at before moving on and it’s the numberguide (the white numbers on the playfield). On a non-retina screen the numbers are very small and when you zoom you can really see the artifacts. I don’t like that so I’m thinking about making the whole bitmap of the playfield twice as big and then show it in 0.5 scale. This means that the zoom will not scale it but instead show it in it’s native resolution.

I’m just a bit worried about memory consumption since the iPhone 3GS has quite little internal memory. We’ll see what happens but now I’m going to make dinner.

Edit: Fixed it. Added an invisible layer on top of the bitmap, scaled it to 0.5x and added the numbers in 2x fontsize. This way it looks better when zoomed. The bad thing is that now other things look bad in comparison. Hmmm…

Hey, we have profile pics

The proportions of the iPhone screen are a bit different than on an Android device so we decided to take advantage of the extra space by including the player profile pics too at the top.

So now you can at least begin to get a grasp of what it will look like when it’s finished. Do please consider that this screen capture is for the non-retina iPhone. We need to make it look usable for that too but of course it will look even better on the retina with it’s double resolution.

Well hello there

Hi there, little iPhone playfield.
Great to finally see you

Finally some tiles

Now this might not look that impressive but there’s a lot more work involved than one can think. What you can’t see here is that the tiles are draggable, they are sorted, they are snapped to a grid, etc etc. All the basic functionality are there so now it’s time to actually start building the game module for real.

It’s nice to finally be back on the iPhone track again after I have focused a while on the Android version. There were a few bugs I really needed to sort out there first before I started porting the code to iPhone. I mean, the more I can trust the logic in the Android version, the more I can focus on recreating it without questioning it all the time. Could this be done better? Does this really work, etc.

Tomorrow I will begin the tedious work of convering all logic to the negative coordinate system. Everywhere there’s a > in the original code regarding to the Y axis, there should now be a <. It’s bound to be a disaster.

Bug finally found

Finally I think I have found out what causes some tiles sometimes not to show on the some boards for some people in some circumstances. I really hate bugs that only show up sometimes since they are a bitch to find.

But the fault is somewhere in the routine that playbacks the melds. I can’t say where since it’s really complicated and hard to understand even for me who has created it. So instead of finding out exactly what’s wrong, I’ve settled on accepting that something is wrong and the remedy is to rewrite it from scratch with another approach of code.

And it seems to work now. At least as good as the old code. Hopefully this means that the bug is gone too even though this will be something for the poor users to test for me. I can’t see any other way to do it since the problem only show up at rare cases, however it happens more often in 5 minute games than others. Hmmm…

Anyway, I’m currently testing out the new code now to see if there’s some unknown issues with it and then I plan a new release for Android. After that I will focus on the iPhone version again since this new code is lots better structured and easier to port.

As a bonus, the new code also has support for Actions. What this is will be a secret until revealed but I can give the hint that it mimics a function in the official web Rummikub at http://www.rummikub.com to some extent.

It will be fun 😉

So what’s happening?

Well, it’s been a busy month at work so I haven’t been able to work as much on iOS-RF as I had planned but there has still been progress, however most of it has been in the RF for Android. You see, there are plenty of things we need to change in the server for it to be able to host both iOS and Android devices at the same time and instead of waiting until the last minute to implement the changes, with the risk of releasing something that won’t work, I gradually implement them in the Android version first, to test them already at this point.

The benefit of this is that the Android people already now can benefit from the changes. Some of them they have already seen in the v1.31 release a few days ago, like blocking functions, fight messages, extended profile dialogs, fight debug information, etc etc…  but what they don’t know is how much that has changed below the surface of the Android version lately too. Things they cannot se but that is important for the future.

The bitch, however, is to retain the backwards compabililty for all those using older versions of RummyFight. (Sigh – please people, update when there’s a new release… please!!!)

But what happens now with RummyFight then?

Well, I do have a release of v1.32 for Android in the making. It’s almost finished but I need to find an annoying bug first that has been a part of RummyFight since v1.0. I really need to figure out why this happens sometimes to some players in some circumstances, otherwise it’s possible that the same bug will be transferred to the iOS version too.

I do think I need this weekend to find out what is going on with it.

Then I have one more week at work followed by 4 weeks vacation.
That is when the magic will happen with the iOS-RF.

Root for me!