Archive for July, 2012

31
Jul
12

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.

Advertisements
29
Jul
12

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.

Image

28
Jul
12

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?

Image

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?

24
Jul
12

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.

Image

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…

23
Jul
12

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.

Image

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.

19
Jul
12

Well hello there

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

Image

15
Jul
12

Finally some tiles

Image

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.