★ TouchArcade needs your help. Click here to support us on Patreon.

Structure of a Program?

05-30-2009, 12:36 PM
#1
Joined: May 2009
Location: Ky
Posts: 7
Structure of a Program?

I know you guys get bonbarded by newbie questions daily but any help would be greatly appreciated. My question is what's the structure of a video game program? Is it all one continuous code or is it split up in small bits of code? Take tower D games for example, when I tap an icon is it telling the program to look for a file in a sub-folder, or is that code always running? Again thanks for any help.
05-30-2009, 02:09 PM
#2
some code gets created during run time and placed on the heap (dynamic memory) to save space or because it couldnt be created at compile time and placed on the stack (static memory) for whatever reason. also different asset files like models and textures may get loaded in during run time according to progress if there are a lot of them. other than that its all running.

this is all to do with memory management and having as little code needed to cycle through each frame. so basically all the code is 1 file (after your pages of high level language code is compiled into machine code) that gets read line by line, and its the asset files that get may get loaded. but ive never worked on a massive project, they may do it different.
05-30-2009, 04:55 PM
#3
Joined: May 2009
Location: Austin, TX
Posts: 199
I believe you are asking about the binary executable, and not the source files written by the programmer. Correct?

I can give you an example from one of our programs, That Ain't It!
When you download it, it is around 7MB of code. The majority of that is different background music loops that play at various times during the game. The music will not be loaded all at once into memory. Instead, it will be streamed in similar to when you download music or video off the internet.

The other large piece is graphics. As you navigate around different parts of the program, different background graphics are loaded into memory. These usually stay around until the iPhone needs memory. When it does, it will look for any graphics not currently being shown on the screen and delete them from memory. This will free up more memory to use by the program. If not enough memory is freed up, then the program will be shut down by the iPhone OS.

Another large piece of That Ain't It! is the database of questions. These are stored in an SQLite database. Only one question at a time is loaded into memory.

The smallest part is the actually program that is figuring out what to do. For each screen shown, associated code for managed that screen is loaded into memory. When that screen is not shown, then in low memory situations, the code will be deleted from memory just like the associated graphics.

I have simplified things a bit and there are a few more details I've left out. I hope I answered your original question. If not, I'll try again after getting clarification.

Developer at IMAK Creations, creator of ColorTilt and other lesser known apps, like That Ain't It!
Blog, twitter
05-30-2009, 05:45 PM
#4
Joined: May 2009
Location: Ky
Posts: 7
Thanks for the help guys, also does the iPhone automatically detect when a piece of memory is not needed? Or do you have put void/@end (or something) after the final line of the program? Thanks again for putting up with newbie questions.
05-30-2009, 09:51 PM
#5
Joined: May 2009
Location: Austin, TX
Posts: 199
Quote:
Originally Posted by Raithwall View Post
Thanks for the help guys, also does the iPhone automatically detect when a piece of memory is not needed? Or do you have put void/@end (or something) after the final line of the program? Thanks again for putting up with newbie questions.
In simple terms, when programming iPhone apps and you want to create an instance of a class, you normally write some code that looks like:

Code:
MyClass *myInstance = [[MyClass alloc] init];
This will grab some memory. When you no longer need the object instance, you would have some code:

Code:
[myInstance release];
So, generally speaking, you have to take care of managing memory usage with the iPhone OS. There is no garbage collection, as there is with Mac OS, that will go around and clean up pointers to unused objects. That is why poorly written code will eat up memory and eventually cause the application to crash to the home screen.

Developer at IMAK Creations, creator of ColorTilt and other lesser known apps, like That Ain't It!
Blog, twitter