First Project: SDL_Pong

Member
Posts: 24
Joined: 2011.06
Post: #1
[Image: title.jpg]

Info:
6.28.11
Well I've come a ways since joining. With the help of some patient members, sealfin and Thems, I've been able to nearly complete my simple goal of SDL_Pong. This is because of their help! Thank you! I still need some help here and there, but I'm starting to get it!

SDL is easy, but you have about 100 ways you can make your system work. Choosing the most efficient path can make it complex, so SDL makes it easy to scale back to your level. What fun! I can't wait to start another project, but this has to be done first.

6.21.11
Hello! I just recently joined and I thought I would start working on the first game I've had in mind: Pong!

I've always loved Pong for it's simplicity and now this is a great chance to learn simple concepts such as collision detection, user input and minor AI components. I've made a crappy AI. I'm more concerned with getting the ball moving and proper collision detection.

Updates:
-Added audio.
-Trying to put all the bits of code into separate header files so I can work on individual parts of the program easier.
-Thinking about computer AI...WEIRD! I was thinking if the ball is over half the screen then move at compSpeed until the ball is level with half the sprite's height. I need to bring the game to real time though before I can do this.

Images:
[Image: mockup.png]
[Image: ss1.png]

Status:
Research:80%
Audio:90%
Graphics:75%
Coding:60%

Download:
http://www.plaidapple.ithaca-ny.com/SDL/

Thanks for the help!
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #2
I'll have like 100^100 questions I'm sure. Thank you everyone! Grin
Quote this message in a reply
Moderator
Posts: 691
Joined: 2002.04
Post: #3
If you've followed the instructions for installing SDL and the SDL development extras for Mac OS X (they're a different download), you should be able to select User Templates->SDL Application after selecting New Project... in Xcode.

Mark Bishop
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #4
EDIT: I messed up and put the templates in the wrong directory. Fixed!

Now I have the barebones window setup. I think the next step is figuring out the putting the graphics on screen in the window. On the SDL site the intro says you can draw pixels or load an image. Do you need the draw pixel code in place to use the load image library, or can I just use the draw image code and load up an image in the project directory?

edit: also, these templates are in c. am I going to have a hard time figuring it out? I'm more familiar with C++
Quote this message in a reply
Moderator
Posts: 691
Joined: 2002.04
Post: #5
I'm not sure if I understand you correctly, but: SDL lets you plot pixels yourself, letting you draw primitives (although there's already a library – SDL_gfx – for that), letting you create raycasters (think DOOM or Marathon), etc.; SDL also lets you blit images, and using SDL's image-blitting capabilities may be faster than plotting the individual pixels of the image by yourself – the following is an example of using SDL's capabilities to load and blit an image:

Code:
int main( int argc, char *argv[] )
{
    SDL_Init( SDL_INIT_VIDEO );
    SDL_Surface *windowSurface = SDL_SetVideoMode( 640, 480, 32, SDL_SWSURFACE );
    SDL_Surface *imageSurface = SDL_LoadBMP( "image.bmp" );
    SDL_Rect whereToRender;
    whereToRender.x = 320;
    whereToRender.y = 240;
    whereToRender.w = imageSurface->w;
    whereToRender.h = imageSurface->h;
    SDL_BlitSurface( imageSurface, NULL, windowSurface, &whereToRender );
    SDL_UpdateRects( windowSurface, 1, &whereToRender );
    SDL_Event event;
    LABEL_LOOP:
        while( SDL_PollEvent( &event ))
        {
            switch( event.type )
            {
                case SDL_QUIT:
                    SDL_Quit();
                    return 0;
                default:
                    break;
            }
        }
        goto LABEL_LOOP;
}

As C++ is (mostly) a superset of C, I wouldn't have thought you'd have any trouble understanding C...

Mark Bishop
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #6
Thank you very much! Its a great place to start!
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #7
OK, I put up some pseudo-code, not very good mind you, so I'd appreciate anyone's input if I have this right. I need to be able to understand the order in which things get initialized before I even bother with input and drawing graphics.

After I get the graphics right, then I probably will need some help with drawing graphics. Is it easier to draw pixels using SDL's SDL_Rect (or w/e it is) and create players that way? How will collision detection work on something that is drawn?

Thanks for all the help! This project is moving forward! Smile
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #8
I'll tackle a small part of this:

(Jun 22, 2011 01:11 PM)Injury Wrote:  How will collision detection work on something that is drawn?

I find it useful to think of these two things as completely separate, unrelated systems. Somewhere in your game code is the logical representation of an object; for something rectangular, it could be as simple as two number variables for the X and Y position of its center, and two number constants for its width and height. Your collision system would take these four numbers as its inputs, and perform the necessary logic to (potentially) alter the position of the object(s). Your drawing system would take the same inputs, and use them to create a visual representation of the object. Neither system needs to affect or even be aware of the other one.

There can be some overlap between the two systems if you're implementing pixel-perfect collisions based on the displayed representation of the objects, but I've always found it cleaner to keep them logically separated even in a case like this. For example, you could have one full-color image used for display, and a separate black-and-white image used for collision for the same object.
Quote this message in a reply
Moderator
Posts: 691
Joined: 2002.04
Post: #9
There are a few problems with your pseudo-code, namely:
  • I'm not sure what you mean by the "put graphics into framebuffer" step;
  • You have the "draw graphics" step outside of the loop, which would mean that the graphics would never be updated – whilst I did that in the code I posted, the code I posted didn't have any moving/animated objects;
  • You shouldn't have a "wait for input" step; as you might have multiple input events per frame, SDL puts all input events into a queue – you should instead check if there are any input events in that queue.

The pseudo-code for an SDL program might look like:

  1. Initialise SDL (including creating the window surface etc.);
  2. create/load the image surfaces;
  3. the beginning of the loop;
  4. check for any input and take appropriate action (eg. updating the positions of the player-controlled objects, quitting the program, etc.);
  5. update the computer-controlled objects (possibly checking for collisions between the player- and computer-controlled objects);
  6. draw objects;
  7. go to the beginning of the loop.

Mark Bishop
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #10
OK! That makes a lot more sense. I assumed you needed to load the graphics with one function and then draw them with another. This is so much more convenient. Thank you again for your help with this! You are going to be credited for sure, just gotta get it up and running!
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #11
I want to break up the includes, initalization of video and audio and other non-game mechanic functions into a header file "init.h"

How do I go about that on a mac? I made the init.h file with the #includes and initialization functions for video and audio, but when I try to use @include "init.h" it says it doesn't exist. I tried to define a direct path to it but it still wouldn't work.

Hope I'm still on the right path. I want to make different includes for the different parts of the engine. Graphics can be drawn with gfx.h while audio is processed by sfx.h. Will these things run parallel to each other? I know that each line will process a certain function, but will it be seamless in game?

Also, how does interface builder come into play with this? Is it interoperable with SDL's coding? I wanted to make an interface, but I don't even know where to start without using some kind of UI builder with linking capabilities.

Thank you all!
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #12
(Jun 24, 2011 11:49 AM)Injury Wrote:  I made the init.h file with the #includes and initialization functions for video and audio, but when I try to use @include "init.h" it says it doesn't exist. I tried to define a direct path to it but it still wouldn't work.

Where on disk is init.h relative to the file that's #including it? If it's in the same directory, it should work; otherwise, you'll need to specify the path to it as an argument to the compiler, like so: -I /path/to/directory/containing/the/file

(Jun 24, 2011 11:49 AM)Injury Wrote:  Hope I'm still on the right path. I want to make different includes for the different parts of the engine. Graphics can be drawn with gfx.h while audio is processed by sfx.h. Will these things run parallel to each other? I know that each line will process a certain function, but will it be seamless in game?

Not totally sure what you're asking here, but #include has the effect of literally pasting the entire contents of the included file in place of the #include line. Let's say you have two files, file1.h and file2.c. file1.h:

Code:
somestuffhere

file2.c:
Code:
foo
#include "file1.h"
bar

What the compiler will end up seeing is this:

Code:
foo
somestuffhere
bar

(Jun 24, 2011 11:49 AM)Injury Wrote:  Also, how does interface builder come into play with this? Is it interoperable with SDL's coding? I wanted to make an interface, but I don't even know where to start without using some kind of UI builder with linking capabilities.

As far as I know, Interface Builder's nib files (or xib or whatever they're called these days) are only understood by Cocoa. SDL won't have any way to use them. Maybe you could write your own parser, but that's probably more effort than it's worth.
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #13
Thank you! I just uploaded the .c and .h files to my private server. Link is up top and right here!

http://www.plaidapple.ithaca-ny.com/SDL_pong/main.c
http://www.plaidapple.ithaca-ny.com/SDL_pong/init.h

Well, separating them made sense like you had mentioned. its less garish too look imho

Oh and I can't get the window to open now. I think I messed it up somehow so it just exits when I build it.
Quote this message in a reply
Moderator
Posts: 691
Joined: 2002.04
Post: #14
Okay, I'm not trying to discourage you, but I think you're trying to achieve too much on the first attempt – if I were you I'd ignore eg. checking whether the player or the computer has won etc. and just put together a program letting you move an image around the window, and possibly checking for collisions with another image.

With that out of the way, I've glanced at the init.h code you uploaded and pasted a copy with a few changes; most of your errors were minor, but your window surface (SDL_Surface *screen) is declared as a local variable of your function int initialize() – if you ever want to draw to the window that pointer needs to either be a global variable or be passed out as a parameter of-/returned by- that function.

init.h:
Code:
/*
*  init.h
*  SDL_Pong
*
*  Created by John on 6/24/11.
*  Copyright 2011 __MyCompanyName__. All rights reserved.
*
*/

#ifndef init_h

#define init_h

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <cstring.h>
#include "SDL.h"
#include "SDL_audio.h"
SDL_Surface *initialize( void );

#endif

init.c:
Code:
/*
*  init.c
*  SDL_Pong
*
*  Created by John on 6/24/11.
*  Copyright 2011 __MyCompanyName__. All rights reserved.
*
*/

#include "init.h"

SDL_Surface *initialize( void ){
Uint32 initflags = SDL_INIT_VIDEO;  /* See documentation for details */
    SDL_Surface *screen;
    Uint8  video_bpp = 0;
    Uint32 videoflags = SDL_SWSURFACE;

    /* Initialize the SDL library */
    if ( SDL_Init(initflags) < 0 ) {
        fprintf(stderr, "Couldn't initialize SDL: %s\n",
            SDL_GetError());
        exit(1);
    }

    /* Set 640x480 video mode */
    screen=SDL_SetVideoMode(800,600, video_bpp, videoflags);
        if (screen == NULL) {
        fprintf(stderr, "Couldn't set 640x480x%d video mode: %s\n",
                        video_bpp, SDL_GetError());
        SDL_Quit();
        exit(2);
    }
    return surface;
}

Mark Bishop
Quote this message in a reply
Member
Posts: 24
Joined: 2011.06
Post: #15
Ah! That makes sense! Whoops! I'm trying to get my bearings here.

I tried to type up as much code as I possibly could, its just scratch, and your right. Probably could be more simple than this. If I should try something smaller than this, maybe a program that just loads a picture and moves it around in a box in the window?

Anything to get my feet wet with graphics and whatnot!

-Mockups up. Small idea of what I want to do.
Quote this message in a reply
Post Reply