- Forum
- General C++ Programming
- graphics from scratch
graphics from scratch
I have looked, to no avail, for information about a starting pointing for developing graphics from scratch. I don't mean explanations of how to use existing graphics libraries like SDL of openGL. I am interested in building a graphics library of my own, but not sure how to start. I know this is reinventing the wheel, but, i didn't fully understand maps, vectors, or BST's until i had to make my own versions of those data structures. So, if someone can recommend a book or tutorial that teaches graphics fundamentals i would appreciate it. Or just tell me if this is too advances for my level (senior computer science student).
closed account (zb0S216C)
Be prepared for a whole world of headaches and sleepless nights.
To achieve such as thing, you'll need unrestricted access to the graphics memory. Of course, the OS will not allow you to do that without imposing some restrictions because writing to the video memory can be problematic if done incorrectly.
There's so little information, and zero tutorials for a good reason: It's far beyond the scope of any C/C++ tutorial; even ASM (I think). The only possible way of knowing how a OS handles graphics is by looking into the source code of an OS. For this, I recommend Linux - make sure you get the manual counterpart to help.
Good luck - you're going to need it.
Wazzak
To achieve such as thing, you'll need unrestricted access to the graphics memory. Of course, the OS will not allow you to do that without imposing some restrictions because writing to the video memory can be problematic if done incorrectly.
There's so little information, and zero tutorials for a good reason: It's far beyond the scope of any C/C++ tutorial; even ASM (I think). The only possible way of knowing how a OS handles graphics is by looking into the source code of an OS. For this, I recommend Linux - make sure you get the manual counterpart to help.
Good luck - you're going to need it.
Wazzak
Headaches and sleepless nights are what make you a great programmer. Shoot for the stars man! Heck, maybe you will not ONLY reinvent the wheel, but maybe you will make it twice as good as the existing wheel. It is often first tries on something that bring genius ideas. I would recommend coming up with everything from scratch. Don't rely on books, tutorials, or other people's source code. See what you could do by yourself. That is the way to learn a lot.
Sure, but then you'll end up with a whole lot of extremely shallow genius ideas.
I wholeheartedly disagree. Yes, it is important to know how things like data structures, or graphics libraries, or game libraries work, but you shouldn't go about re-writing every library you ever use.
I was actually in this exact same mindset about a year ago (my first attempt at graphics), when I realized I would need to learn to rely on other people's groundwork for many things, especially something as low level and driver/OS dependent as graphics. You don't need to write your own graphics driver to understand how rendering works.
| I would recommend coming up with everything from scratch. Don't rely on books, tutorials, or other people's source code |
I wholeheartedly disagree. Yes, it is important to know how things like data structures, or graphics libraries, or game libraries work, but you shouldn't go about re-writing every library you ever use.
I was actually in this exact same mindset about a year ago (my first attempt at graphics), when I realized I would need to learn to rely on other people's groundwork for many things, especially something as low level and driver/OS dependent as graphics. You don't need to write your own graphics driver to understand how rendering works.
Remember that he is going to aim to learn how graphics rendering works, but I could almost guarantee that he will learn a ton of new things that he wouldn't even think about learning before. Obviously you shouldn't rewrite every single library, but if you want a challenge... why not, right?
@OP:
Framework's response was kind of smartass, but there's truth in what he's saying.
To put it more plainly, there are different "levels" of graphics programming. The higher level ones tend to be easier to use and work on more platforms, and the lower ones tend to be much much harder to use, only work on one platform, but are more flexible.
So the real question you should ask yourself is... how flexible do you need your graphics lib to be? Do existing libs really not provide the flexibility you need?
The general pecking order is something like this:
Typically people either go with a wrapper like SFML, or a more "direct" approach like OpenGL. The only real difference is how much flexibility they need. But either way you are using layer upon layer of someone else's code. You can never truely do everything 100% by yourself. At least not on modern machines... not if you want your program to work anywhere.
Using a lower level lib like OpenGL gives you about all the flexibility anyone could want. But it only does graphics and requires you to do additional setup. Things that logically are a simple single-step operation (like loading textures -- a single function call in SFML) turn into multiple-step operations (load image file, decompress image, convert to OpenGL compatible format, create a texture, bind it, write image data to it).
Additionally, wrapper libs take care of things that lower level libs simply don't. For example, OpenGL only does graphics output. You have to supply your own window and do your own window management. And if you want audio, you have to employ an entirely separate lib. On the other hand, higher level libs like SFML have all that bundled in one. What's more, they do it on multiple platforms... whereas anything you write yourself will likely only work on your OS.
Here's the other thing. Libs like SFML even let you use OpenGL directly. You can just use them to make window management/texture loading/etc easier, but do all the actual drawing yourself direclty with OpenGL. So really, they offer virtually the same amount of flexibility.... so there is very little reason not to use them.
So weigh your options carefully and figure out whether this is really worth your time. I'm personally not above reinventing the wheel -- it can be a lot of fun sometimes. But if you're looking to be productive, it's not the right way to go.
Framework's response was kind of smartass, but there's truth in what he's saying.
To put it more plainly, there are different "levels" of graphics programming. The higher level ones tend to be easier to use and work on more platforms, and the lower ones tend to be much much harder to use, only work on one platform, but are more flexible.
So the real question you should ask yourself is... how flexible do you need your graphics lib to be? Do existing libs really not provide the flexibility you need?
The general pecking order is something like this:
<highest level> Lib wrappers (ex: SFML, SDL, Allegro) Graphics libs (DirectX, OpenGL) Communication with video drivers (few programmers go this low level) Communication with video hardware (virtually nobody but driver authors go this low) <lowest level> |
Typically people either go with a wrapper like SFML, or a more "direct" approach like OpenGL. The only real difference is how much flexibility they need. But either way you are using layer upon layer of someone else's code. You can never truely do everything 100% by yourself. At least not on modern machines... not if you want your program to work anywhere.
Using a lower level lib like OpenGL gives you about all the flexibility anyone could want. But it only does graphics and requires you to do additional setup. Things that logically are a simple single-step operation (like loading textures -- a single function call in SFML) turn into multiple-step operations (load image file, decompress image, convert to OpenGL compatible format, create a texture, bind it, write image data to it).
Additionally, wrapper libs take care of things that lower level libs simply don't. For example, OpenGL only does graphics output. You have to supply your own window and do your own window management. And if you want audio, you have to employ an entirely separate lib. On the other hand, higher level libs like SFML have all that bundled in one. What's more, they do it on multiple platforms... whereas anything you write yourself will likely only work on your OS.
Here's the other thing. Libs like SFML even let you use OpenGL directly. You can just use them to make window management/texture loading/etc easier, but do all the actual drawing yourself direclty with OpenGL. So really, they offer virtually the same amount of flexibility.... so there is very little reason not to use them.
So weigh your options carefully and figure out whether this is really worth your time. I'm personally not above reinventing the wheel -- it can be a lot of fun sometimes. But if you're looking to be productive, it's not the right way to go.
You could, if you are really brave, build your own OS.
http://wiki.osdev.org/James_T._Klik
And don't forget, that your dream is yours, don't let anyone put you down.
http://wiki.osdev.org/James_T._Klik
And don't forget, that your dream is yours, don't let anyone put you down.
ok, i didn't realize how OS-dependant graphics are. all the info was great, i appreciate it, OSdev looks interesting, but i need more experience before trying that. I'm interested in low level programming, but not that low, yet.
Topic archived. No new replies allowed.