C++ Game development Question

[Ryan Wilson]

Hey, everyone! I would like to ask if I should be going on to game development yet. Right know i'm using code::blocks IDE coding in c++ and using SDL library for 2D graphics, sound, input and I was wondering if it is the right time to do so. I know my c++ basics until you get to about pointers and maybe some other advanced stuff, it seems that in game development pointers are used a lot. I would just like to know if I should stop using SDL and just start going back to plain c++ using the cmd prompt and learn everything there is to know before stepping into an additional thing to learn like SDL. And if someone can please explain about pointers and why they are used for so many things, it's a little harder to learn by not visualing seeing what it really does. Thank you hopefully I was elaborating to much..!

[tolga gerekci]

You should learn pointers first. They are pointing to an address. And if you learn it, you can understand the programming. I'm using directx11 and i always use pointer classes.

[Ryan Wilson]

Alright thanks for the reply! Also how should I start with my game structure it gives me a headache like Player class, Enemy class, that would probably inherit from a Character class. Then a game class or system class to handle to SDL initialization and screen functions i'm not sure on the whole game structure concept, I feel like i'm doing it incorrectly and when to use private and const and things like that :s

[Ben Bowen]

As you being a beginner using SDL, I'm assuming that you are making a 2D game.

2D games most often use rectangles to represent the things such as images (or sprites) that will interact during gameplay. That's because images are rectangular (width by height).

Often times, you might need to offset an image so that it's centered around a different origin point (maybe the center of the image, rather than the top-left corner?). And, sometimes (well, a lot of times) you will need to check when a rectangle and another rectangle, or maybe just a point, are 'overlapping' eachother.

It would be good to bundle these common functions that are used with rectangular objects (such as game sprites), into a utility class that will serve you as you program your game.

While you spend your time developing this game, you'll probably notice that some code you've written before can be redone in a better way. That's very common with new programmers, and it's perfectly fine (so don't go overboard and pull your hair out!)

When I was very new to game development, I'd often run into things that took a lot of time (or extra effort) to do. Just try reviewing (or outlining) the overall system around your problem. Think about how the original system can be revised and better designed to help you finish your game faster.

Best wishes,
Ben

[Ryan Wilson]

Thank you Ben! I'm currently just going over the c++ language without SDL at the moment and once i'm more comfortable with the language i'll go back and then learn SDL cause when I was working with SDL I was lacking some c++ knowledge with pointers and some other stuff as to when to use private, const, friend and to point with -> and all that confusing stuff I need to get comfortable with. If you have any information about pointers and -> and stuff please share! Thank you once again for helping me with this as I would like to program as a job in the future!

[helios]

You'll definitely need to be very comfortable with pointers before you can take full advantage of SDL.
Here's a random bit of code from an SDL program I wrote a while back. It's the main part of a function that implements software alpha blending:

#define OVER_SETUP_PIXEL(i)            \
	rgba0[i]=pos0[src.offsets[i]]; \
	rgba1[i]=pos1+dst.offsets[i]
#define APPLY_ALPHA(c0,c1,a) ((((a)^0xFF)*(c1)+(a)*(c0))/255)
#define FAST_INTEGER_MULTIPLICATION(a,b) (((a)*(b))>>8)
uchar negate=0;
if (alpha<0){
	alpha=-alpha;
	negate=0xFF;
}
for (unsigned y=h;y;--y){
	const uchar *pos0=src.pixels;
	uchar *pos1=dst.pixels;
	for (unsigned x=w;x;--x){
		long rgba0[4];
		uchar *rgba1[4];
		OVER_SETUP_PIXEL(0);
		OVER_SETUP_PIXEL(1);
		OVER_SETUP_PIXEL(2);
		OVER_SETUP_PIXEL(3);
		pos0+=4;
		pos1+=4;

		rgba0[3]=FAST_INTEGER_MULTIPLICATION(rgba0[3],alpha);
		ulong bottom_alpha=
			*rgba1[3]=~(uchar)FAST_INTEGER_MULTIPLICATION(rgba0[3]^0xFF,*rgba1[3]^0xFF);
		//uchar integer_division_lookup[0x10000];
		ulong composite=integer_division_lookup[rgba0[3]+(bottom_alpha<<8)];
		if (!composite)
			continue;
		*rgba1[0]=((uchar)APPLY_ALPHA(rgba0[0],*rgba1[0],composite))^negate;
		*rgba1[1]=((uchar)APPLY_ALPHA(rgba0[1],*rgba1[1],composite))^negate;
		*rgba1[2]=((uchar)APPLY_ALPHA(rgba0[2],*rgba1[2],composite))^negate;
	}
	src.pixels+=src.pitch;
	dst.pixels+=dst.pitch;
}

It uses pointers and bit twiddling all over the place because it's optimized to hell. Unfortunately, some of this is unavoidable if you want to make quality software with SDL, because many of its facilities suck, so you have to recreate them.

[Duthomhas]

That really is a random piece of code there, helios.

I don't think there is any reason not to jump right into game development. You learn what you need as you go.

Just so long as you don't start off thinking you are going to make the next great million-dollar game.

[helios]

But representative. Particularly if you do pixel-level manipulation.

[Duthomhas]

Representative of what?

The OP wanted to know if it is reasonable to continue using SDL regularly without knowing that much about pointers.

You are doing fancy, low-level stuff that isn't directly addressed by SDL libraries, which officially makes it a side issue. It is entirely possible to write a fully functional SDL game without on-demand color and compositing tricks.

I think it is only representative of fancy stuff that SDL was not really designed to handle directly, not of using SDL the way it was designed.


All said, though, I was really just saying I enjoyed the randomness of your example. :O)

[helios]

Representative of code you'd have to write if you want to make something nice-looking. Using the SDL only the way it was designed leaves you with bit blitting and 16-bit colors.
Well, okay, it's an overly complex example. How about this?

for (unsigned y=0;y<h;y++){
    uchar *pixel_pointer=screen_pointer+y*pitch;
    for (unsigned x=0;x<w;x++){
        uchar *red=pixel_pointer+red_offset,
            *green=pixel_pointer+green_offset,
            *blue=pixel_pointer+blue_offset,
            *alpha=pixel_pointer+alpha_offset;
        *alpha=255;
        *red=*green=*blue=(x&y)?0:255;
        pixel+=bytes_per_pixel;
    }
}

There. That's more reasonable, isn't it?

PS: If you don't know what that does, try it out. The result is surprising.

[Ben Bowen]

How annoying.

So, back on topic: Pointers! To demonstrate the power of pointers, I'm going to talk about using them to make arrays and handle memory.

A plain "array" is a structured collection of entities. For example: a list is an array intended for an objective, usually used in a sequence (e.g. a check list or shopping list).

A dynamic array is much more complicated however; because, they are designed to be resized and changed often.

Now, imagine a game with a slow & steady flow of enemies coming into the level, while you're fending off these enemies and eliminating them one by one. As a programmer, how would you manage this? Well, you may have heard of the Standard Template Library's class called "vector". It's just a dynamic array.

C++ has some nice features which are very helpful for implementing a dynamic array yourself. It has built-in operators designed for allocating new memory, as well as freeing it. Look at this:

// Create an array of 5 integers:
int* integerArray = new int[5];

The "new" operator will allocate (find available/reservable) memory for int[5]; which is five integers.

Logically, I start with "int" for the type. Then there's an asterisk (*) which makes it a pointer to one or more integers. Now it is possible to point to the memory location which was just allocated for five integers.

So, I can start putting integers into the array:

integerArray[0] = -1;
integerArray[1] = 6;
integerArray[2] = 13;
integerArray[3] = 5;
integerArray[4] = -7;

There, that's five integers! Notice: I start at zero and end with four, rather than starting at one and ending with five. That's because, the number (index) which I put between the '[' and ']' merely means an offset in memory.

That kind of translates to:
integerArray+index*sizeof(int)

Do you get the idea a little better now?

Well I'm going to bed. Checkout:
http://www.cprogramming.com/tutorial/c/lesson6.html
http://cplusplus.com/doc/tutorial/pointers/

[Duthomhas]

@helios
Both your examples are nice, though your assessment of SDL's native capabilities is, methinks, a little pessimistic, that's all.

[helios]

I'm only talking from experience. I had to reimplement many of its features for one project because they were, for one reason or another, so completely inadequate. And it's not like it was a really complex engine. It only used 32-bit surfaces with alpha blending.

Just to be fair, though, SDL does work really well as a windowing library for OpenGL, and with FFmpeg. I used the latter in that same project and it was fairly straightforward.

[mik2718]

For sure the OP needs to be comfortable with pointers.

But surely he should skip the whole bit manipulation stuff and move on to openGL asap. Even for a simple 2D game?

openGL is going to be easier?

[Moschops]

openGL is going to be easier?

It wasn't when I did it :) openGl was a lot harder than how to flip bits.

Seriously, learn pointers. Here's a really simple, easy guide to the basics: http://cplusplus.com/articles/EN3hAqkS/
and here's another one: http://cplusplus.com/articles/z186b7Xj/

Pointers are not difficult, they're just often very badly taught.

[Computergeek01]

I'd say the OP should jump into a tutorial for using SDL if that's the library they want to end up using. I remember when I first read about objects I thought they were odd and I couldn't think of any reason to use them. This was because I had not tackled anything as large as even a simple game at that point, but I remember that once everything "clicked" it changed my entire programming style.

As for pointers, then yes the OP should know how to use them before attempting to write their own game. This does not mean they need to understand them 100% in order to read through a tutorial though, if they have a general idea then that is probably good enough. Once you start seeing how pointers are actually used they become easier to understand, this was the case with me at least.

@OP: Just remember that a pointer is an address and because the compiler is so literal you need to be clear about if you mean to use the address that the pointer holds (passing data by reference) or if you meant the data located at that address (passing data by value\dereferencing a pointer). The rest is just semantics.