Searching for documents...

#1 What you are describing is usually referred to as "compilation" : Taking programmer-written source code and making it an executable program.

A computer just crunches a bunch of numbers. Here is a simplification: if #21 means "set the drawing color to blue" and #56 means "draw a pixel on the screen", then 21;56 would draw a blue pixel. Of course, it is much more complicated than that, but it gets the point across. Its just a string of numbers with meaning.

Now, of course, programmers don't want to write 44;52;78;32;etc... for their programs, because that would be too difficult and nothing would ever get done. So this is why we use programming languages, such as C++, C#, Java, Basic, etc... these add in keywords that allow us to properly organize and develop our programs without worrying what the numbers mean.

Once the source is written, it is run through a program called a "compiler" (usually) which turns this code into the string of numbers (called Byte Codes) needed to actually execute the program. The CPU then reads these numbers one at a time, and performs the proper task associated with each number.

There is much more to it than this, of course, but it should give you a basic idea. For more info, most books on Assembly Language go through this information step by step at the beginning (because assembly is as close to actually entering the numbers as you can get).

Hopefully this helps, and hopefully I answered the right question :)

#2 Hi Joe,

thank you for you explanation and taking the time to respond. I am bit familiar what happens inside a computer, what the CPU does, what a compiler does etc. Actally I was trying to find out something else. Let me explain again.

OK, assume I play Tetris. There is the game screen and a single block falls down.

What files would the computer access in order to make the block move one unit downwards?

Let me guess:
-One file with the code that instructs an object (the block) to advance downwards for one unit. (a .??? file)
-One file that contains the drawing of the block (a .bmp file)
-One file that contains the game screen in which the block moves (a .??? file)
-One file with code that tells the computer to keep the game screen there until all blocks fell down?

If I'd move the block right with my arrow, it would use
-a file that handles how input has to be processed (a .??? file)
-a file that handles how the according output has to be displayed

So what I basicly want to know is how much different types of files would be accessed and in which order to get the block down to the bottom based on my directional input? Would there be also some files that tell other files how to behave?

As a programmer, how would you structure these files? Would you put same content into one file? For example all bitmaps in one? All game screens in one? All code in one?

What does an .exe file do, while all this happens?

If I had audio-files, would I put all audio into one file?
Would I need another file with code that handles how sound is displayed?

So my question is more about how do programmers organize the stuff. And in which order does the computer access that stuff to create the illusion that I "play a game".

And how does a program decide what it has to do first? Does this require another file? Can I (or do I have to) define the access order by myself?

#3 Well first there no *SET way to label files and how many files you have to use in a program. You could in essence have all your source code done in one file. But most people generaly breakup it up into different files that pretain to certain areas. Like all the terrain rendering code you might toss into terrainrender.cc

However it is not a requirement to do so. In essence there is not set or right or wrong way to setup your source code. There is however a easy way and a harder way when it comes to editing the source code. As having everything in one big giant file would both take longer to open that file and alot longer to search through 100k+ lines of source code.

I would suggest you pickup a basic programming book and read through that. It will explain most of your answers you are looking for.

#4 Ok, I think I see what you were asking about, though I may still be wrong... I'll try again :)

Note: Much of the stuff I say up here you may already know, but I don't want to leave anything out in case you don't.

-One file with the code that instructs an object (the block) to advance downwards for one unit. (a .??? file)
-One file with code that tells the computer to keep the game screen there until all blocks fell down?
-a file that handles how input has to be processed (a .??? file)
-a file that handles how the according output has to be displayed

All of this is in the .exe file, the executable program which is created by compiling all of the source code. The source itself is organized differently depending on the language used (in C++, you create .h and .cpp files, then compile them into an .exe, but you don't then have to distribute the .h and .cpp, only the .exe)

-One file that contains the drawing of the block (a .bmp file)

.bmp, .jpg, .png, or any other file format will be used for this. .wav, .ogg, .mp3 for sound files, etc. There just has to be code compiled into the .exe that allows you to load the file formats that you are using.

-One file that contains the game screen in which the block moves (a .??? file)

This game screen could be anything from a static bitmap (one .bmp file) to a tilemap (a set of .bmp files) that is built through code in the .exe, to a fully 3D rendered sequence (also built through code in the .exe).

- As a programmer, how would you structure these files? Would you put same content into one file? For example all bitmaps in one? All game screens in one? All code in one?

That is the choice of the programmer. Most new developers just hold all the bitmaps in one directory, all sounds in another. As I said before, the code does not have to be distributed, as it is just a single .exe file (most of the time), but there are ways of compiling code into distributable .dll files and such.



So, as an example, for a basic tetris you could have:

- A background bitmap (.bmp)
- The bitmap for one block (.bmp)
- Music (.mp3)
- Block drop/block rotate/line destroyed sounds (.wav)
- The game logic, drawing code, input code, sound code, all compiled into a single executable (.exe, created from .h/.cpp source code files, assuming C++)

And the source code (not distributed with the final product) could look like:
main.cpp and main.h - Creates the window and initializes data
board.cpp and board.h - Contains game logic and board drawing code
input.cpp and input.h - Takes input
sound.cpp and sound.h - Loads and plays sound
Of course, it can also get much more complex than this (and most commercial products do). Your source file tree can be hundreds or thousands of files containing a million lines of code, but in the end it is still compiled into one executable.


"So my question is more about how do programmers organize the stuff. And in which order does the computer access that stuff to create the illusion that I "play a game"."

This depends on the programmer and the language. In C++, the program starts at the function main() in your program. When you learn a language, its entry point is the first thing you learn. Keep in mind, this function, like any other code, is still compiled into the .exe, so the starting point of your program from the end users point of view is double-clicking the .exe file.


I hope this answers your question better, but you should look into some programming books to learn more about how this works. Even using a pre-existing engine such as Torque will require you to understand these fundamentals.

#5 Hi all,

@Tom: Thanks for your reply. I have already a book on C and many tutorials from the internet. Just wait to upgrade my computer and get a good compiler. Then I will try to learn more by myself.

I spent already some time with the material and practiced some variations of the "Hello World" and simple loops. I just wrote them in notepad. (Sounds "green", hm? :-) As I feel now like standing at the entrance to a new world, I am quite curious and might ask questions that seem unnecessary or even stupid. I am sorry for that.

However I have this macro-view thing and before I get into detail I simply want to have an idea how files etc work together. That's why I was asking the questions.

The example you gave with exe and debugging makes sense. I was checking into file libraries of games to figure out what different files they contain. It's true that almost all games have a different structure, however it seems that there are some rules and conventions followed by companies. I am just curious now if a company like EA has a convention on how to label files. Is it worth to take a look into the folder structure of games?

You are right in advising me to read books on programming and I hope to do so soon: I plan to learn C first (as it seems an important language to me, many OS are created with it as far as I could found out); then I want to get into OOP and learn C++ since it seemes to be a standart in the industry. I started to all this with a simple interest in game design but after a while I just seized that without technical knowledge you don't really know what you are doing. Even if I can't be a good programmer, I would at least better understand what they talk about when discussing design issues. Does it make sense?

@Joe: Your second post is definately about what I wanted to find out. Thanks a lot for the your help and patience. By the way: Just surfing around after your former post, I found some nice tutorials about Arcade game programming with SDL. The first example was Tetris :-) It makes a lot sense now, combined with the knowledge you provided.

>This game screen could be anything from a static bitmap (one .bmp file) to a tilemap (a set >of .bmp files) that is built through code in the .exe, to a fully 3D rendered sequence (also built >through code in the .exe).

Could you please tell me what difference there is between a static map and one that is built by code? Do you mean the code takes a single tile and generates a big map with them? I think this happens in games like "Civilization". You could write code that randomly generates a map map or you could pre-define a set of tiles that the code generates based on the stored map data?... But why wouldn't you save a pre-defined set of tiles as a static map? Because the engine already does it for you and a static map is unnecessary or because a static map is simply too big in size? Or would it affect gameplay? If you code movement based on tiles, the engine would not be able to move a character on a static map as it cannot measure the movement??

Then I wonder how the terrain in a game like Rise of Nations is generated. Seems like a set of layers of static maps to me.

I could code a grid and apply it invisibly on a static map. The feel of "tiles" would be gone, but still I would have a measure for avatar moves?

This is all interesting stuff :-))

#6 And all my reflections must sound pretty silly :-O

#7 By a static map, I mean a single bitmap that is "the background", such as you may use for tetris. However, in a game such as Civilization the map is way too big. Consider that 1024x768 pixels at 32-bit color is 1024x768x4 bytes, or 3 MB. So a map that takes up four screens at 1024x768 can be 12 MB, and if your map takes 20 screens, we're talking 60 MB, which is more than many video cards have and a huge waste.

But what if, instead, you encoded the map as

3 3 3 3 3
3 4 4 3 3
3 4 3 2 3
3 3 3 2 2

Where 3 is grass, 4 is rock, and 2 is water. Now, we store one grass image, one rock image, and one water image, and draw them at the appropriate places. We now don't have to store the whole map in pixels because we can build it from a set of data, which is many times smaller than the 60+ MB of storing the whole map.

#8 Ok, I see.. I guessed that actually. You would use static maps only for menu screens and save memory to increase computer performance.

I heard a word: clipping. Is it about how the code changes/updates all the 334234s when you scroll the map? And what does mapping actually mean then?

I also heard skin and texture. They are not the same as tiles?

#9 Clipping is when you take the image that is going to be drawn on the screen and cut off all of the parts that are off-screen. So if I have a character that is half on-screen, the other half is considered "clipped". In 3D, it also means the part that is clipped because it is too far away to bother with rendering.

Skin and texture are used to add detail to 3D models, whereas tiles (as I am using the word) are 2D objects. The '?' block in mario is a tile. The picture of a rock on a mountainside in Morrowind is a texture. The painted-on clothing of Link in Zelda is a skin (which is, most of the time, just a texture on an animated model).

#10 Joe, thanks really for taking the time and answer all this. It's very helpful.

Thanks again.

#11 "Could you please tell me what difference there is between a static map and one that is built by code? Do you mean the code takes a single tile and generates a big map with them? I think this happens in games like "Civilization". You could write code that randomly generates a map map or you could pre-define a set of tiles that the code generates based on the stored map data?... But why wouldn't you save a pre-defined set of tiles as a static map? Because the engine already does it for you and a static map is unnecessary or because a static map is simply too big in size? Or would it affect gameplay? If you code movement based on tiles, the engine would not be able to move a character on a static map as it cannot measure the movement??"

just to add to what joe said, another thing to consider is RAM. the random access memory is what gets filled up when you start a game. you want to keep this as low as possible. in theory, you could write code to literally handle terrain and textures any way you please. you could even write code which dynamically generates it's own textures and sound and not have to use wavs or jpgs at all. in the end its all just data. the program uses a set of instructions to retrieve data from these file formats. if you want, you could instead just pass procedurally generated data for these purposes. however, theres always standards the programmer should adhere to. it would be extremely inefficient to store an entire terrain texture as one continuous body of memory. it has to be broken up into recyclable(is that a word?) chunks. also, being able to easily interface with other 3rd party tools makes standardized file types(memory organization schemes) pretty much essential.

you may have wondered how does the programmer decide how to organize data retrieved from sound and picture files. here we're referring to data loaded into ram, not data stored in files. the truth is, the programmer is abstracted from these kinds of low level processes. to a large extent, the computer has sort of a "black box" functionality where the programmer doesnt know how everything is being organized. all computer memory and ram is simply a long list of numbers. sound file data loaded into ram may be a tiny continuous chunk of memory at some address in ram. the computer is hardwired to store this data somewhere and *remember* where it is and retrieve it when necessary. the programmer doesnt know and doesnt really need to know where it is in relation to everything else. the fact is that it would be extremely difficult to track data being processed, not to mention extremely pointless. these kinds of low-level processes are hidden from high-level programming and dip down into the areas of computer engineering.

#12 Thanks a lot Sean, I think I getter a better picture the more you guys post. But also new questions pop up. It's quite interesting for me...

So, here I go:

OK, actually any program we run uses RAM locations to store the data that is used by it, since this is how the CPU works more efficient and faster. It speeds up access time. Hence data is not taken from the files themselves, but from RAM, where it had been ordered to go when I ran the .exe file. I assume that I understood this right.

Now my first (bunch of) question(s) is: What is the RAM in a graphic card good for then. I mean what is stored there? It can't be the data of all graphic files that the program uses, can it? (Same I could ask for RAM in sound cards.) Oh wait, it stores the data of the frame that has to be displayed next? That means it still takes orders from the CPU? Or does it have something like its own CPU?

Second: What do you mean with "procedurally" generated data? You mean I could basically hard-code (this is what they call it I guess) "terrain" in machine language? But why would this make the storage inefficient? I just wonder since I read that code that is written in machine language is much more efficient than any other code as it "speaks the native language" of the computer and doesn't need "translation" (compilation etc.)

From here I come to the third question: The recycable chunks. Let me see if I have understood this: When I write an entire terrain in machine code (the procedurally thing) it is difficult for 3rd party tools to read it since they can't perceive the image I describe. It's like if i leave no space between words, and you don't know the language I speak, you can't estimate what the particular words are. Example: Assume that "akicirafinesofratuzu" represents a piece of procedurally generated data... actually it is "akici rafine sofra tuzu" (this is in turkish by the way), but the 3rd party tool can't "understand" it, because it can't decide what the chunks (words) are, as it doesn't know the "memory organization scheme". So it wouldn't know how the display the image. But do all image formats at the end not describe what attributes a particular pixel has? What makes them different?

Maybe I just didn't get this part clearly.

Forth and last: What about Cache memory? For what is it used? More specifically, what would be stored in cache in a game like, say, Tetris?


Thanks again for all the responses.

#13 Video RAM is used to store any graphics-related data that needs to accessed quickly. You are right about it storing the next frame (this is called the Frame Buffer). It also stores the images used to make characters and backgrounds, textures for 3D models, and vertex data for 3D meshes which make up the polygons that render the object). Recently, video cards have also gained Pixel/Vertex Shaders, which uses a processor on the card to execute special programs for rendering (these are also now stored in video memory). There is talk about pushing physics off onto the video card as well, and when this happens all of the physics data will be stored in the video RAM as well.

Procedurally generated data is anything that is generated by code instead of created by a designer. I believe what he was saying above was that you could use data that was procedurally generated offline and stored instead of creating it on the fly (though I had trouble following it exactly), and that this would be very inefficient.

As far as interfacing with standard tools go, if you generated the data procedurally offline, you could write converters that would let you use these standard tools. But of course, this is getting a bit more advanced then necessary if you are just starting out...

Cache memory is the temporary memory for the processor. This stores the data that the processor is currently chewing on. It will also often cache variables that it has recently used in case that variable is needed again very soon.

#14 Hi Joe,

Video RAM is sort of a cache reserved for graphics then I think. That makes sense. It's actually interesting to see how everything is organized around the "quick access" concept. I couldn't realize this that much.

What exactly is a pixel/vertex shader? I guess it cares about the colors to be displayed. So it cares about the 4 bytes required for the CMYK? What exactly is the advantage that is gained if a pixel shader is stored in Video RAM. When you say Pixel Shader, it sounds like a tool. Is it a tool, or rather a process?

What does physics stand here for, btw?

Thanks a lot!

#15 Cache is where the data and operation for immediate use is stored. Like the next word I am going to say when I build a sentence?

#16 Sometimes.
It's more like speed-dial numbers on your phone,
it's stuff you use constantly, so you want it to be extra fast.

Physics means simulating the actual physics of a game.
Tetris has a very simple physics simulation for example:
the blocks fall at a constant rate, and stop falling when they land on something.
A more complicated physics system would account for an accelerating rate of falling,
blocks bouncing off the pile, blocks sliding back and forth, etc.

Simulating physics for a complex scene can take a lot of computation,
so there's some interest in designing special chips who's purpose is just to do physics simulation,
and so freeing up the main processor for other stuff. - Just like what happened with basic graphics.

A pixel shader is basically a small program which is run for every pixel that belongs to a polygon being drawn on the screen.
It's job is to decide the final color of the pixel, based on inputs such as what color the object is, how the object is being illuminated, whether the object is shiny or bumpy, etc.
Graphics processing is almost always done using the Red-Green-Blue color model rather than the CMYK model, by the way.

#17 To add to Orion's post: a pixel shader is exactly what he described above. A vertex shader is the same, but only for each vertex on the object instead of each pixel being rendered. This allows color and texture special effects, but it also lets you change the position of the vertex to do real-time morphing and animation blending on the hardware.

For some examples of what can be done using shaders, look up the terms (in google):
Normal Mapping
Cel Shading
High Dynamic Range Lighting
Particle Systems (they can also be done without shaders, but on shaders they are MUCH faster)
Relief Mapping
Environment Mapping
Gooch Shading
Shadow Volumes

And of course, many other high end graphics techniques.


Anyway, hopefully this gives you an idea of the expansiveness of the topic. I find it to be one of the most interesting branches of graphics (too bad I'm not much of a graphics guy) and I can't wait to see what kind of techniques are developed in the future.

#18 Hi,

first, thanks again for the answers!

@Orion: The speed-dial numbers example and the explanation on physics are very helpful.

Could you please tell me more about how the little programs for each pixel work together? There would be also a "macro" code that defines how the little programs cooperate? A bigger program that tells the smaller ones how to decide on the color?

You know, it seems like I am taking an excellent course here :-)

@Joe: I will cheque the terms.

However it is very nice to have people that explain more if you have questions. I searched and downloaded many files, but all of them assume that you know already something or that you are not interested in the things that happen in the "black box" (as Sean defined it). I always ask how (which can be annoying for you guys, I am sorry for that). Maybe this slows down learning, but I have the feel that when I turn back to the tutorials after I got more info about the hows, I really get better along. And the interesting part is: if I don't know how these things function, it is actually impossible for me to understand what makes you so excited about possible hardware developments.

Why do we need to shade a vertex seperately? Isn't it a single point after all, which is already subject to pixel shading?

#19 Don't worry about it, its not getting annoying (its not like somebody is forcing me to answer these :)

Most explanations are written by engineers, for engineers, so they don't get into the "how" because they assume you like to sit and grind and figure it out yourself. I find this a bit irritating, but then again I'm more of a designer type anyway.

Anyway, every time a triangle is rendered by the hardware, it goes through a few steps:
Transform - Apply's 3D transformations (such as the camera and object orientation) to the triangle
Vertex Shading - Described above
Pixel Shading - Described above also

Now sure, you could go ahead and (theoretically) do everything on a per-pixel basis, but this assumes a few things: first, that you have the processing power to do everything per-pixel. Secondly, that you have access to all necessary data on the pixel-level.

First thing you need to understand is that Vertices are in World Space, which is a three-dimensional space, while Pixels are in Screen Space, which is a two-dimensional space (the Z coordinate is stored in a Z-Buffer, but the X,Y coordinates are the ones that store the most information about the object in this space)

There are alot of effects (such as animation blending) that would be much harder to do at the pixel level (instead of transforming each of a few thousand vertices, you are transforming millions of pixels?) and alot of effects that are "good enough" at the vertex level (many texture morphing techniques) and much faster to perform.

Then there is the question of particle systems. A vertex is a location in world space, while a pixel is a location in screen space. So how would you handle the motion of a particle in world space using pixel shaders (which are, by definition, in screen space). This may or may not make sense, based on your level of knowledge of 3D math.

Finally, how big is a pixel in 3D space? That is an ambiguity that makes physics and collision impossible to write efficiently at the pixel level.

So, basically, vertex shaders are a way to get good effects MUCH cheaper than pixel shaders, and pixel shaders are there to allow us to write the techniques that can't be done at the vertex level.






We are getting a bit advanced here now, and that's fine. But I would suggest that before you start getting really into these advanced graphics topics that you familiarize yourself with basic programming and 3D math (if you haven't already).

Anyway, I'm glad I can be of some help. I just recently graduated (so I no longer have students to talk to) and since then haven't been able to talk much about these techniques that I don't regularly use at work :)

#20 To refer back to an earlier topic, the .exe.

Actually the .exe is not something that I write, but it is what the compiler makes out of the source code, right?

When the program runs (that means the .exe has "taken over"), the "executables" are all located somewhere in RAM. So are the data that are normally in the graphic and sound files (all other stuff that will be used during execution.) So actually during execution noone of the files is used. Their content is now in RAM and waits to be moved along the bus.

Things that are more often used during execution are in cache.

The graphic and sound cards can be seen as some types of cache, that handle the data that is related to their functions. But they all obey to the CPU which behaves according the .exe. This is how all these different hardware components know when and what to do.

You find find this funny, but the true lesson I learned here is that the files themselves are not really used during execution. It's all about what has been loaded to RAM.

So if I want to know how the illusion of me playing a game is created, I have to look what happens during execution, not what is in the files or how they are organized.

File format and structure however can improve how efficient .exe works and how much memory in RAM is occupied during execution. But during execution none of the files is accessed directly. When the programs starts, it uses the files for a single time, loading their content in to RAM and then the files live in peace.

Wow. So is this the big picture I was searching an explanatory document for?