SharpDX Tutorials » Basic Concepts
This tutorial introduces a variety of fundamental concepts that you'll need to understand to really get into SharpDX development. This tutorial has no actual coding, but don't skip it, because knowing and understanding these basic concepts will be critical to you as you get underway.
SharpDX works very close to the metal—that is, there's not a lot between you and the actual hardware. (Raw DirectX is even closer to the metal, and as you'd expect, is about the only thing between you and raw bits, bytes, and pixels.)
On one hand, this gives you a ton of power at your disposal. That power is probably why you're here to begin with.
On the other hand, it means you don't necessarily have a lot of abstractions in the way to hide the ugly details from you. (And yes, there will be many times that those ugly details will bubble up into what we're trying to do, and we'll need to address them ourselves.)
This means that in order to go anywhere with SharpDX, we get to learn a lot about the inner workings of your computer's hardware, device drivers, the operating system, and how the computer sees graphics. Note my choice of words in that previous sentence: "we get to learn a lot about…". There's no doubt that we've got a lot to learn and understand. But the truth is, it's an exciting journey in front of us. The knowledge you gather here will open your eyes and numerous possibilities, regardless of where you go in your graphics/game development future.
So this is where it all begins. We begin by trying to understand how things work at a conceptual level. Without a conceptual understanding, it will be nearly impossible to actually get things running with SharpDX. (Actually, that principle is far broader than just SharpDX; it holds true in all of software development.) But with an understanding of the fundamentals, we'll be well on our way to building amazing things.
To get things started, let's discuss buffers. Officially, a buffer is simply a chunk of memory that is used as a staging area for data, on its way from one place to another. We're going to get very friendly with buffers. We'll see them around nearly every corner. Some buffers are in your computer's main memory, and some buffers are on your graphics card. Some are elsewhere.
I should probably also point out that while the above definition is the standard definition, it is sometimes used very loosely to basically mean "a pile of bytes". I'll try to steer away from that particular usage. Vague terminology is just one of my pet peeves. Just be aware that that looser definition is out there, and not entirely uncommon.
A frame buffer (perhaps "the frame buffer) is a buffer where pixel data is dumped in preparation for being drawn to the screen. Generally speaking, in a frame buffer, you'll get enough data to provide color information for each and every pixel. There are a lot of different formats for this data, which we'll take a closer look at later. For the time being, the important thing to understand is that frame buffers don't just automatically store data in the exact same way.
For the sake of this discussion, let's treat it in kind of an abstract way. This will probably seem like overkill for now, but go with it for a few seconds, and it will seem more reasonable. (I hope…)
Say there's a giant screen somewhere, with a big grid of lights. Let's say there's 1024 of them across and 768 up and down. It's my job to figure out what colors they should all be, and it's your job to climb up there and change them. We could have the following discussion:
Me: "Go change the pixel at row 435 and column 589 to be red."
You: "What's a pixel?"
Me: "It's what I decided to call each individual light in that giant screen of yours. It's short for 'picture element'."
You: "Why don't you just call it 'picture element' then? I thought you didn't like vague terminology. I thought you liked being more precise with your—"
Me: "Just go change the color of the light."
[You go climb up there and make the change.]
Me: "OK, now go change the pixel at row 435, column 590 to be green. No blue."
[You go climb back up there again, and make this second change.]
Me: "OK, now go change pixel 435, 591 to sort of transparent-y taupish-beige."
You: "You're very odd…"
[You go make the third change.]
Me: "OK, now change 435, 592 to be black."
You: "Look, I was just up there. I'm getting really tired of going up and down and up and down. Can't we find a more efficient way to do this?"
Me: "You have it hard? I have to come up with all of these strange color names! If it weren't for me, who would be able to describe Cornflower Blue to the world?"
You: "It's just that… I'm getting tired, and you just sit there demanding things like the Knights Who Say Ni."
Me: "… Fine. What to you propose?"
You: "Well, how about we set up a table right here, between us. We'll draw out a grid, the same size as my giant screen. You fill in each square with the color you want it to be, and I'll come down, take a look, and make the lights on the giant screen match."
Me: "That sounds reasonable. I shall name this concept that I have invented The Frame Buffer!
You: "But wasn't it my—"
Me: "The FRAME BUFFER!
It turns out, my little frame buffer idea works out pretty well. I can go off and figure out what colors should go on the table, and you can light up the screen far more efficiently than before.
But a few hours go by, and I discover a fatal flaw with your little frame buffer idea. I spend hours coming up with a beautiful picture for you to display. I go to our table and fill out the grid, as we negotiated before, and away you go, drawing the screen. But then, inspiration hits. I have a brilliant new picture to draw!
Off I go, clearing off the table and starting fresh on my new drawing. It's at this point that you come back to figure out what colors the next little block of pixels have, only to discover that I've wiped it out and started over.
You: "So… the table is blank."
Me: "So? I have a new picture that I want drawn."
You: "What about the old one?"
Me: "Well I expected you to finish drawing that one already. Isn't it done?"
You: "No. I was half way done when you wiped everything out. All I can do is make all of the lights black, since that's all that's on the table right now."
Me: "So… you're going to only draw half of my first masterpiece?"
You: "Well… I wasn't finished, and you destroyed the plan."
Me: "Preposterous! This is your fault! Obviously! Somehow…"
You: "Fine. I'll just go make the rest of the pixels empty. That's all I can do at this point."
Me: "But that will make the screen flicker! The world will only see half of my masterpieces."
You: "OK, how about this. Let's grab a second table. We'll make a second grid on the second table. The first table will be mine, the second will be yours. That way we don't step on each other's toes. You can paint your next masterpiece at the same time as I'm putting up your first masterpiece. When you've completed your second masterpiece, you'll check with me. As soon as we're both done, we'll copy the grid from one table to the other. At that point, I'll start changing the lights again, and you can start on a third masterpiece."
Me: "Three masterpieces? Now we're getting somewhere. This sounds like it might work. Two tables, two grids. One for me, one for you. This is genius! I can't believe it took me to fix the problems in your frame buffer! I shall call this DOUBLE BUFFERING!
My double buffering invention works wonders. I can paint my next masterpiece at the same time that you update the screen. We're each working with our own copy of the buffer, and so nothing bad happens.
- Frame Buffer
- Back Buffer
- Double Buffering
- Triple Buffering
- Page Flipping (Ping-Pong Buffering)
- Frame Rate
- Refresh Rate
- Interlaced video
- Progressive scan
Included page "sharpdx-footer" does not exist (create it now)
Included page "troubleshooting-link" does not exist (create it now)
SharpDX Tutorials » Basic Concepts