Thread: Quick question regarding game programming

  1. #1
    Registered User
    Join Date
    Apr 2010
    Posts
    2

    Wink 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++?

  2. #2
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    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.

  3. #3
    Or working on it anyways mramazing's Avatar
    Join Date
    Dec 2005
    Location
    Lehi, UT
    Posts
    121
    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.
    -- Will you show me how to c++?

  4. #4
    chococoder
    Join Date
    Nov 2004
    Posts
    515
    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++

  5. #5
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    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.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  6. #6
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Sebastiani View Post
    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.
    Last edited by MK27; 04-21-2010 at 10:08 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #7
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by MK27 View Post
    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).
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  8. #8
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Sebastiani View Post
    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.
    Last edited by MK27; 04-21-2010 at 01:28 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  9. #9
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by MK27 View Post
    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.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  10. #10
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Sebastiani View Post
    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.
    Last edited by MK27; 04-21-2010 at 02:11 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  11. #11
    Registered User
    Join Date
    Apr 2010
    Posts
    2
    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

  12. #12
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  13. #13
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    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.
    Last edited by VirtualAce; 04-22-2010 at 01:52 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Quick Pointer Question
    By Toonzaka in forum C Programming
    Replies: 3
    Last Post: 02-19-2010, 11:58 AM
  2. quick noob question
    By thanatos1 in forum C# Programming
    Replies: 2
    Last Post: 06-17-2009, 08:28 PM
  3. Quick Game Programming Question
    By Gallaton in forum Game Programming
    Replies: 10
    Last Post: 05-15-2009, 04:08 PM
  4. newbie question on game programming
    By Leeman_s in forum Game Programming
    Replies: 1
    Last Post: 10-30-2001, 04:57 PM
  5. Quick question: exit();
    By Cheeze-It in forum C Programming
    Replies: 6
    Last Post: 08-15-2001, 05:46 PM

Tags for this Thread