iOS Looking for Two-Dimensional Array Suggestions

[dejo]

I am looking for suggestions from my fellow developers for a simple way to implement a two-dimensional array that would hold int values, used to store playing pieces in a grid. Currently, I have something of a solution with a custom class that uses NSMutableArray of NSMutableArrays, but I thought there might be an easier way using a "int gameField[9][7];" in my appDelegate (for now, could always throw into a singleton). I had problems constructing a working @property declaration for this kind of array.

So, any suggestions for possible approaches, things to watch out for, etc?

 

[PhoneyDeveloper]

I always thought 2d arrays in C were complicated.

Simplest is to use a standard [x][y] C style 2d array. I'm pretty sure that @property just doesn't work with C-style arrays.

It's possible to put ints into CFArray, as apposed to NSArray, which will only hold objects. CFArray is by nature a 1d array but you could easily do the calculation to use it like a C-style 2d array.

You could also use a mutable data as the backing store for a C style 2d array.

 

[firewood]

If you don't need performance, just use an NSMutableArray of NSMutableArrays, or a single 1d NSMutableArray with your own 2d-to-1d coordinate-converting accessor methods to make it look 2d.

If the array is being used in inner loops of CPU bound game computation, then have the class variable be a pointer to a C array, and handle array access using inline C macros for better performance.

Or both: write a set of matching macros and methods so you can choose depending on your performance, debugging or scalability requirements.

 

[North Bronson]

What about declaring a pointer to an array of integers?

@property(nonatomic, readonly) NSInteger *pointerInteger;

- (NSInteger *)pointerInteger
{
    if (pointerInteger == 0)
    {
        static NSInteger array[9][7] =
        {
            //  Declare Array Here
        };
        
        pointerInteger = &array[0][0];
    }
    
    return pointerInteger;
}

Would that work?

 

[kainjow]

I don't think it matters how you store the data, but I think your class should make it transparent with methods, similar to how NSMatrix (an OS X class) does this with its cellAtRow:column: method.

Internally I think just a normal int array would be fine. You can do your own bounds checking and define macros for the number of rows and columns.

Edit: the one nice thing about using NSArrays inside NSArrays is the for() loop, which is nice and purty

 

[firewood]

I don't think it matters how you store the data...

Tell that to Google. In a large database or supercomputer app, how one stores that data can make a huge difference (many millions of dollars) in server costs and kilowatts required. Even in a handheld game engine, bad decisions in data layout can eat a users battery faster than needed.

Transparency also costs.

 

[PhoneyDeveloper]

firewood, and if you write it as a class then you can change the implementation whenever you want based on profiling or other real data.

 

[dejo]

So, create a custom class, with usable APIs, and hide the implementation details in the code? How very OOP!

Thanks for all your thoughts and ideas! Now to put this little project aside for a while and throw together a quick prototype for an app idea I came up with last night...

 

[kainjow]

Tell that to Google. In a large database or supercomputer app, how one stores that data can make a huge difference (many millions of dollars) in server costs and kilowatts required. Even in a handheld game engine, bad decisions in data layout can eat a users battery faster than needed.

Way to take my sentence out of context and apply it to a completely different topic

dejo - is your game being written with Core Animation/Views or OpenGL directly?

 

[dejo]

dejo - is your game being written with Core Animation/Views or OpenGL directly?

Core Animation/Views, for now. It think it's simple enough for that. And I don't even know if this will ever become a full-fledged game (I'd need to license the rights from the original IP owners or change it enough that they don't get mad at me). Right now, this is just a little "distraction" for me to try and expand my skills in areas I'm less familiar with. And in case you're wondering what the game is, it's this: http://scott.blazing.de/fun/game.swf

 

[firewood]

firewood, and if you write it as a class then you can change the implementation whenever you want based on profiling or other real data.

Implementing things inside a class in a dynamic dispatch OOP language is not free. There is an overhead that can kill an apps performance is certain circumstances (the inner loops of a board games AI engine can easily be one of those places). Useful profile data may come too late in a design cycle for certain data layout decisions. Writing readable portable high level code, (versus small fast code), rarely provides as much benefit towards extending the battery life of a user's device.

 

[PhoneyDeveloper]

How do you measure this battery life usage of which you speak?

My app can make the battery hot. No complaints from users though.

 

[firewood]

For a developer, Shark and Instruments will measure CPU utilization percentage. There are a lot of apps that appear to max out the CPU that might not need to (similar to Flash video making the fan run full tilt on my MacBook, while better codecs of the same quality don't). The hotter your iPhone gets running some app, the faster the battery is draining.

Note that I am not saying Obj-C is bad for generic UI code. But trying to use Obj-C message passing to calculate the individual RGB colors of every pixel while trying to generate full screen bitmaps at 60 fps for a game animation engine just isn't going to work on current hardware. Some types of game physics simulation code works best all the way down at the the armv7 assembly language level. Both high-level and low-level coding practices have their places in creating the best apps.

So one question for the OP is whether the needed 2d array is for some rarely executed UI display code, or for the guts of a compute intensive game AI engine.

 

[dejo]

So one question for the OP is whether the needed 2d array is for some rarely executed UI display code, or for the guts of a compute intensive game AI engine.

Probably somewhere in the middle?

 

[ChOas]

Core Animation/Views, for now. It think it's simple enough for that. And I don't even know if this will ever become a full-fledged game (I'd need to license the rights from the original IP owners or change it enough that they don't get mad at me). Right now, this is just a little "distraction" for me to try and expand my skills in areas I'm less familiar with. And in case you're wondering what the game is, it's this: http://scott.blazing.de/fun/game.swf

Thanks for getting me addicted to that game again!

I'm making a game somewhat like that, also for skill expanding.

Something like this: http://www.gameroo.com/games/light-bot but then in 2D like the cowgame...

 

[moral-hazard]

could you not use:

int** myarray;

//then allocate memory as follows

myarray = malloc (9*sizeof(int*));

for (int i = 0; i < 9; i++) {
 *myarray+i = malloc (7*sizeof(int*));

This approach using pointer arithmetic also allows you to do "ragged" 2-d arrays if need be (i.e. one "row" of the array can be shorter or longer than the next.

this could also be very easily turned into an obj-c wrapper as well so that it could be used to hold objects.