Searching for documents...
by cheese_phantom · in General Discussion · 08/08/2005 (8:20 am) · 25 replies
Hello,
I want to gain a plain idea on how a computer uses program source files in order to put together the illusion that we experience as a game. For example what data transfer, communication or procedures take place inside the computer to make me see my avatar go from point A to B? What happens inside the computer that makes me hear my footsteps while I go from A to B?
I guess the programmers call all that things that organize the source files an architecture and the way it works as a system. Just guessing...
I am not yet looking for details (like how the code must be written or the graphic files must be formatted). I rather need some simple charts that provide a general picture of the interactions between source files and CPU and explain with a few arrows how call procedures happen, how maps and avatar states are updated or how data manipulation in files takes place. A Tetris or a Pac-man example would be great.
Do you know of any document (preferably online) that has some diagrams or flowcharts to give me some clues about the issue?
I want to gain a plain idea on how a computer uses program source files in order to put together the illusion that we experience as a game. For example what data transfer, communication or procedures take place inside the computer to make me see my avatar go from point A to B? What happens inside the computer that makes me hear my footsteps while I go from A to B?
I guess the programmers call all that things that organize the source files an architecture and the way it works as a system. Just guessing...
I am not yet looking for details (like how the code must be written or the graphic files must be formatted). I rather need some simple charts that provide a general picture of the interactions between source files and CPU and explain with a few arrows how call procedures happen, how maps and avatar states are updated or how data manipulation in files takes place. A Tetris or a Pac-man example would be great.
Do you know of any document (preferably online) that has some diagrams or flowcharts to give me some clues about the issue?
About the author
#22
Hmm, here comes the killer part then: Math! You know that I also bought some math books? Just don't feel ready yet to get into them. Iused to hate math in high school and now I try to beat this feeling. ;-)
Ok, it is a bit tough now for me, but I will still try.
>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.
Ok, what I ask now might sound very stupid: Is there a difference beetween a pixel that makes up an image ( actually a byte that contains the CMYK values) and a pixel on a screen created by the internal process in a monitor? Are they the same? I mean like: Is the size of one pixel that makes up an image same with the size of one pixel on the screen?
I have to ask since I still don't understand what makes a vertex easier to handle as pixels. After all, a vertex that we see still consists of pixels. When you say "a few thousand vertices", don't you still use millions of pixels to display them? What makes the vertex easier to handle as the pixel?
I think I don't really understand the difference between the "levels" (pixel lev, vertex lev...). Is it simply the difference between 2-D and 3-D or is there something else I need to know to distinguish between these "levels"?
If you think that I sound really too stupid here, just say "you reached your limit, it's really time to get into a book about it. Read and come back later." :-)
08/09/2005 (3:29 pm)
Nice to hear that I am not that annoying :-) hahaHmm, here comes the killer part then: Math! You know that I also bought some math books? Just don't feel ready yet to get into them. Iused to hate math in high school and now I try to beat this feeling. ;-)
Ok, it is a bit tough now for me, but I will still try.
>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.
Ok, what I ask now might sound very stupid: Is there a difference beetween a pixel that makes up an image ( actually a byte that contains the CMYK values) and a pixel on a screen created by the internal process in a monitor? Are they the same? I mean like: Is the size of one pixel that makes up an image same with the size of one pixel on the screen?
I have to ask since I still don't understand what makes a vertex easier to handle as pixels. After all, a vertex that we see still consists of pixels. When you say "a few thousand vertices", don't you still use millions of pixels to display them? What makes the vertex easier to handle as the pixel?
I think I don't really understand the difference between the "levels" (pixel lev, vertex lev...). Is it simply the difference between 2-D and 3-D or is there something else I need to know to distinguish between these "levels"?
If you think that I sound really too stupid here, just say "you reached your limit, it's really time to get into a book about it. Read and come back later." :-)
#23
08/09/2005 (3:31 pm)
Yes, really zen-like! :-) I have a big smile on my face now...
#24
To answer your question, you have to know the following:
When you draw images to the screen, what you are really doing is writing numbers (usually 32-bit) to a chunk of memory on the video card called the Frame Buffer. As the little electron gun inside the monitor slides around, it streams this Frame Buffer data and uses it to decide what color to make each pixel. So a pixel on the monitor IS the same thing as a single number in the frame buffer.
Each time your game loop executes (where the game logic is updated and the screen is drawn), the Frame Buffer is overwritten with new data based on whatever you decided to draw that frame. When the monitor refreshes, it will read the frame buffer and get this new data, displaying the new image on the screen.
A pixel shader adds a middle step here: When a new value is about to be drawn to the frame buffer (one pixel, a single number) the Pixel Shader first executes a chunk of code on this pixel.
Now lets step over to the vertex shaders. When you want to draw a triangle, you pass three vertices to the video card. The video card then transforms these vertices to figure out what the triangle should look like based on the current camera angle, then goes through a stage called Rasterization, where the triangle is broken up into pixels and drawn to the Frame Buffer one at a time. The vertex shader happens BEFORE rasterization, when the vertex is not yet broken up into pixel data. The changes that the Vertex Shader makes to that vertex will then affect what happens DURING rasterization (by changing colors, positions, etc).
So the trick here is that a Vertex Shader happens BEFORE rasterization, which will then change how the triangle is rasterized, and a Pixel Shader happens DURING rasterization, changing the final pixel values that go into the Frame Buffer.
Therefore, you can change hundreds or thousands of pixels by performing only one vertex operation, by changing the way that triangle will be rasterized in the end.
I should start charging you for this :) ... (just joking)
08/09/2005 (4:00 pm)
First thing to know is that computers don't use CMYK. They use RGB (Red, Green, Blue) where (Red + Green = Yellow... weird, huh? Search RGB Color system in google for more info).To answer your question, you have to know the following:
When you draw images to the screen, what you are really doing is writing numbers (usually 32-bit) to a chunk of memory on the video card called the Frame Buffer. As the little electron gun inside the monitor slides around, it streams this Frame Buffer data and uses it to decide what color to make each pixel. So a pixel on the monitor IS the same thing as a single number in the frame buffer.
Each time your game loop executes (where the game logic is updated and the screen is drawn), the Frame Buffer is overwritten with new data based on whatever you decided to draw that frame. When the monitor refreshes, it will read the frame buffer and get this new data, displaying the new image on the screen.
A pixel shader adds a middle step here: When a new value is about to be drawn to the frame buffer (one pixel, a single number) the Pixel Shader first executes a chunk of code on this pixel.
Now lets step over to the vertex shaders. When you want to draw a triangle, you pass three vertices to the video card. The video card then transforms these vertices to figure out what the triangle should look like based on the current camera angle, then goes through a stage called Rasterization, where the triangle is broken up into pixels and drawn to the Frame Buffer one at a time. The vertex shader happens BEFORE rasterization, when the vertex is not yet broken up into pixel data. The changes that the Vertex Shader makes to that vertex will then affect what happens DURING rasterization (by changing colors, positions, etc).
So the trick here is that a Vertex Shader happens BEFORE rasterization, which will then change how the triangle is rasterized, and a Pixel Shader happens DURING rasterization, changing the final pixel values that go into the Frame Buffer.
Therefore, you can change hundreds or thousands of pixels by performing only one vertex operation, by changing the way that triangle will be rasterized in the end.
I should start charging you for this :) ... (just joking)
#25
That with the vertex/pixel difference was actually very very enlightening too.
I was actually going to write something like this since I understood that the vertex allows us to tell a bunch of pixels simultaneously how the behave rather then telling each pixel one by one what it has to do, but I didn't know this rasterization thing and that it can be manipulated beforehand, (which is actually what vertex shading seems to be about!)
08/09/2005 (4:48 pm)
Hahaha... yes, I mean hell, it's like taking a course already :-)That with the vertex/pixel difference was actually very very enlightening too.
I was actually going to write something like this since I understood that the vertex allows us to tell a bunch of pixels simultaneously how the behave rather then telling each pixel one by one what it has to do, but I didn't know this rasterization thing and that it can be manipulated beforehand, (which is actually what vertex shading seems to be about!)
Torque Owner Joe Bourrie
Enlightened? Almost Zen-Like, isn't it? :)