Quick question regarding game programming

When making a game purely from scratch, could something in 2D (with about the graphical equivalent of, for example the 2D Zelda games for Gameboy) be made entirely with C++, or do all games like that require something else, because I really don't understand Direct X and I'd really prefer not to mess with something like that when it comes to just making games for pure amusement and not for serious business. Sorry about this probably being a really stupid and easy question, but I'm just confused by all of the talk about Direct X and such...I'm thinking that's mainly for 3D though, which I don't need or care about really.

Going back to the 2D game though, would it run relatively quickly, and be fairly playable and at least nice looking for 2D using only the C++?

You need some interface to the graphics, which is what DirectX and OpenGL (and at a higher level, Ogre3D and Irrlicht) are. "Pure C++" has no support for graphics.

You can use something like Allegro or SDL, they both provide wrappers for directx and opengl. Allegro is what I started with but they both provide simple ways to get pictures on the screen as well as drawing functions that are straight forward. They are well documented, as are directx and opengl. You can grab the book "Game Programming All in One". It teaches using Allegro.

Nono, you misread him. He wants to use "only C++", which implies no external libraries whatsoever.

It's certainly possible, but would of course require he write all those libraries himself from scratch.
I know it's possible because a lot of those libraries were written using C++ :)

OpenGL and similar are for those who don't want to do the graphics calculations "by hand". If you are willing to do everything yourself then all you *really* need is some way to dump pixels to the screen, which is fairly trivial on most platforms.

Quote:

---

Originally Posted by Sebastiani

OpenGL and similar are for those who don't want to do the graphics calculations "by hand". If you are willing to do everything yourself then all you *really* need is some way to dump pixels to the screen, which is fairly trivial on most platforms.

---

Yes, but then you cannot take advantage of hardware, which is why even the people who wrote SDL recommend using openGL or directX for 2D graphics inside SDL, and not the SDL pixel functions themselves (which are way, way slower).

In other words, the point of using openGL or directX is not just that they are graphics libraries with functions for such, but that they relate to the hardware layer. That's what those two libraries are (and only those two).

In other words, doing it all yourself may seem like a good idea, but you are doomed to poor performance, since you cannot access the video card, or use any hardware acceleration, without openGL or directX. That means once you get good enough that performance, etc, is an issue, you will have to switch over. All the work you put into your own custom library/techniques/whatever will be wasted, and you will have to learn again from scratch. On the other hand, if you start with openGL or directX now, you won't have that problem later.

Also, if you have a hard time understanding the directX API, you will be hopelessly lost trying to make up your own graphics lib. Just buckle down, buy a book, and do a few tutorials. It will get easier. Another advantage of using a major API is that there is a large online community of support available.

Quote:

---

Originally Posted by MK27

Yes, but then you cannot take advantage of hardware, which is why even the people who wrote SDL recommend using openGL or directX for 2D graphics inside SDL, and not the SDL pixel functions themselves (which are way, way slower).

In other words, the point of using openGL or directX is not just that they are graphics libraries with functions for such, but that they relate to the hardware layer. That's what those two libraries are (and only those two).

In other words, doing it all yourself may seem like a good idea, but you are doomed to poor performance, since you cannot access the video card, or use any hardware acceleration, without openGL or directX. That means once you get good enough that performance, etc, is an issue, you will have to switch over. All the work you put into your own custom library/techniques/whatever will be wasted, and you will have to learn again from scratch. On the other hand, if you start with openGL or directX now, you won't have that problem later.

Also, if you have a hard time understanding the directX API, you will be hopelessly lost trying to make up your own graphics lib. Just buckle down, buy a book, and do a few tutorials. It will get easier. Another advantage of using a major API is that there is a large online community of support available.

---

Nope, you're wrong. On Windows, for example, one only need to use the Choose/SetPixelFormat API functions to get access to the pixels (via Get/SetDibBits).

Quote:

---

Originally Posted by Sebastiani

Nope, you're wrong. On Windows, for example, one only need to use the Choose/SetPixelFormat API functions to get access to the pixels (via Get/SetDibBits).

---

Yeah, you can do that on linux via Xlib with "graphics contexts". That's how the SDL pixel functions would work. But this is not hardware accelerated.

By "hardware acceleration" I mean if you have a directX/openGL capable video card (get it?), you can use the API to (for example) send data directly to video memory, and call operations built into the video processor (GPU). That's the purpose of those two API's. The advantage here is pretty obvious, since it means you can store objects on the video card and manipulate them with the GPU. Otherwise, you must store them in normal RAM, manipulate with the CPU, and deal with the FSB as a bottleneck sending all the data for every frame to the card, every frame. Additionally, the GPU is faster at inline math/vector processing than the CPU.

So I wasn't trying to say it is impossible to do without them, but it is a dead end wrt most contemporary graphics programming, because that is all about taking advantage of hardware acceleration. GPU's are processors with a command set like the CPU, directX and openGL are the API's developed and maintained to operate them. Because they are so good at crunching numbers, they are now being used to do non-graphics related math. However, you still need a form of either the directX or openGL library in order to do that.

Quote:

---

Originally Posted by MK27

Yeah, you can do that on linux via Xlib with "graphics contexts". That's how the SDL pixel functions would work. But this is not hardware accelerated.

By "hardware acceleration" I mean if you have a directX/openGL capable video card (get it?), you can use the API to (for example) send data directly to video memory, and call operations built into the video processor (GPU). That's the purpose of those two API's. The advantage here is pretty obvious, since it means you can store objects on the video card and manipulate them with the GPU. Otherwise, you must store them in normal RAM, manipulate with the CPU, and deal with the FSB as a bottleneck setting all the data for every frame to the card, every frame. Additionally, the GPU is faster at inline math/vector processing than the CPU.

So I wasn't trying to say it is impossible to do without them, but it is a dead end wrt most contemporary graphics programming, because that is all about taking advantage of hardware acceleration. GPU's are processors with a command set like the CPU, directX and openGL are the API's developed and maintained to operate them. Because they are so good at crunching numbers, they are now being used to do non-graphics related math. However, you still need a form of either the directX or openGL library in order to do that.

---

The point is, you can simply set up OG/DX as a rendering point, connect to the WIN32 API, and then access the pixels directly. The graphics subsystem queues it up via whatever buffering mechanism is used, and the end result is identical. I have seen some fairly rapid animations using that very method, in fact.

Quote:

---

Originally Posted by Sebastiani

The point is, you can simply set up OG/DX as a rendering point, connect to the WIN32 API, and then access the pixels directly. The graphics subsystem queues it up via whatever buffering mechanism is used, and the end result is identical. I have seen some fairly rapid animations using that very method, in fact.

---

Okay, so it uses OG/DX underneath? I think there are a few gaming libs around like this.

Which kind of elucidates the point: no matter how you slice it, you need some kind of API to work with. You can't do any graphics in "just C++", as the OP seemed to be asking. I'm not really trying to push a particular method, just put some info forward. Also: working per pixel with the Win32 API will only seem like an easier idea at first, because you only have to deal with a few simple commands initially. Versus tangling with apparently daunting graphics library docs, and all the initially bewildering aspects. However, once you are over that hump in a day or two, you'll probably get alot further faster. IMO. Grit your teeth, you're a programmer.

So what ADI would I want to use for graphics at least comparable to these in 2D (slightly better, and definitely in color).

http://www.zeldainformer.com/images/...Awakening1.png
http://images.nintendolife.com/scree...9687/large.jpg

By the way, thank you all so much for taking the time to help me here so far! I just hit a wall trying to figure this stuff out on my own. :P

The only one I know is openGL, and it was a little frustrating at first. On the other hand, there are tons of resources (forums, books, tutorials, etc) around to help.

2D is quite a bit simpler than 3D, you definitely want to do 2D first. OGL, and I presume DX, has a sort of 2D mode.

You expressed interest in directX, you might as well go with that, unless you see something else around you like (as someone else pointed out, Allegro is very popular and uses DX, same for SDL). I dunno anything about DX resources, they appear not to have an official forum, but there is one at gamedev.net. which is a pretty busy place:

DirectX and XNA - GameDev.Net Discussion Forums

Just ask there for some good tutorials, etc. Looks like there might be some "Sticky:" threads at the top for that.

Quote:

---

Nope, you're wrong. On Windows, for example, one only need to use the Choose/SetPixelFormat API functions to get access to the pixels (via Get/SetDibBits).

---

Um...nope you are wrong. The only way to use the HAL is to either use D3D or OGL. Anything else you do outside of the DDK via the API is not hardware accelerated. The only way to get access to the HAL is either write your own driver or use D3D or OGL.

Anything else, while it may be fast, is still not being done on the GPU and therefore is a complete waste of time and video hardware. You want everything you can to be executed and stored on the GPU. If you need to access raw pixels then you do it inside of a shader b/c the vertices are sent to the shader and the interpolated u,v's and data per pixel are sent to the pixel shader. However if you are locking a buffer or somehow only modifying it in system memory then this will cause possible pipeline stalls since the data must be streamed from system memory to video memory. Just grabbing pixels off of a DC or a raw surface in the Win32 API is not the equivalent of correctly using D3D or OGL to do the same thing.

Nothing in the Win32 API will ever come close to matching the performance of the GPU. That is what D3D and OGL were designed to do. They are not just mere graphical wrappers around Win32 calls.