Zael

This has been posted many times before. In short though:

C# and XNA are good for a beginner. You should probably be prepared to make your first several programs (games) text based stuff to get a feel for program flow and the art of programming. Visual Studio Express edition is free from Microsoft's website. I don't actually do much C# myself, so I can't really help as far as tutorials go.

Good luck!

Typically in a text based game a menu will be simple output with different input option.


Example "Menu":

int choice = 0;
while(choice != 2)
{
	 std::cout << "What would you like to do?\n";
	 std::cout << "1) Start a new game\n";
	 std::cout << "2) Quit\n";
	 cin >> choice;
	 switch (choice)
	 {
		  case 1:
		  startGame();
		  break;
		  case 2:
		  return;
		  break:
     }
}

Does that make sense or are you asking something else?

Check out Project Euler. It is basically exactly what you have described.

Looks to me like the problem is that you are simply repainting the time without repainting the background first. Think of the surface as an actual canvas for a second. You have a picture on the there. Then you create a picture of the time. Next you paint that time picture onto your canvas surface. Before restarting the loop, you free the time picture (this doesn't affect the canvas image which still has the time already painted onto it). Then you get the new time, and paint the new time onto the surface (over the old time, but without removing the old time). If you want to erase the previous surface, what you really need to do is at the beginning of each loop re-apply the background (thus painting over the old time).

SDL_FreeSurface frees the image from memory, but it doesn't erase the image from other surfaces on which it has already been "painted".

Does that make sense?

Everyone learns at their own pace. It also depends a lot on how much time you are dedicating. If you are spending an hour or two every night you are going to move a lot slower than a college or high school student who has more time in the afternoons/evenings and summer vacation. It sounds to me like you are doing pretty well and are probably ready to jump to 2d.

I would not jump into OpenGL. I would test the waters with SDL or SFML.

List of things I would tell somebody to know before starting 2D games are:
- Declaring and using variables
- Arithmetic operators +,-,*,/,%
- Implementing Functions
- Using if-else statements and familiarity with !, &&, and ||. Knowing the difference between = and ==
- Understanding loops
- Familiarity with at least part of the C++ standard library (std::string, std::vector, std::list, std::map come to mind first. Know how to delete and add to vectors and lists while iterating through them)
- Understanding Pointers and comfortable using them
- Comfortable writing your own classes complete with methods and member variables
- Preferably comfortable with polymorphism

Some things I am assuming you know if you know this list (like using parentheses), and I may be missing some things. If you know everything on this list (with the exception of polymorphism) I would say you are ready to try starting on 2D games. You can probably make small games without knowing any of the last 3 items (depending on the library you used for graphics). You will run into new challenges like draw order and path finding, but knowing the language won't help you with algorithms. For those you will have to be a problem solver and/or ask around.

y is undefined. What you probably meant is 'y', which is the character y instead of the variable y.

Line: 20

Problem looks like it is here:

int myNumber,;

Should not have a comma unless you are declaring multiple ints on that line.

You are also missing a semi-colon on this line:

cout <<"\nYou chose "<<myNumber <<"as your number."

Also you should use an up-to-date IDE like MS Visual Studio Express or CodeBlocks.

@way2lazy2care: Adults are scary authority figures. Non-adults are peers. I would think this obvious.

Makuto, you may want to search the forums. I want to say somebody proposed the same exact thing just a few weeks back.

While learning from your C++ book try making some simple text based games. Start with something like a you choose adventure book, then move onto a text based rpg, and then once you have a grasp of all the basics take a look at SDL or SFML.

HTML and javascript would be the best bet for a simple browser game. You can use onclick to trigger a function and set data on the page. Javascript is actually pretty simply, and all you need to program it is notepad and a browser, both of which you already have. You may want to look into a java applet for something more complex or flash. If you don't care too much about whether or not it is a browser game, python is a great language for beginners (but not very suitable for a browser game).

It looks like you are approaching this like moving a point on a graph. At the moment, if a user clicks left of the dot, the dot would still move right, and the y would now go the opposite direction you intend because of change of sign in deltaX. It also seems to me that your gravity is substantially smaller than your shooting. If your yVel starts out at -50 (that would be when the user clicks a 45 degree angle with the dot), It won't halt it's journey upward until it is at 1275 pixels higher than where it started. If you did just over a 60 degree angle from the horizontal then it would be 5050 pixels (just over 12 and a half screens at 640x400 resolution). I would try increasing your gravity affects by a bit, and/or bumping down your launch velocity.

Your current initial velocity depends a lot on angle because you have a constant x velocity which the y velocity is based. If you want to better model projectile motion, you should have an initial velocity that does not depend on angle, and use that to calculate both x velocity and y velocity. By that I mean something similar to:

float initialVelocity = 50.0f;
float deltaX = tempX - x;
float deltaY = tempY - y;
float distance = sqrt(detaX*deltaX + deltaY*deltaY);
xVel = initialVelocity * deltaX/distance //deltaX/distance gets us the x component of a unit vector
yVel = initialVelocity*deltaY/distance //deltaY/distance gets us the y component of a unit vector

As for really fast... right now your movement is totally dependent on how fast your frames per second. I would recommend:

unsigned int currentTime = SDL_GetTicks();
float elapsedTime = ((float)oldTime-currentTime)/1000.0f; // in seconds
x += xVel * elapsedTime; //xvel is in pixels per second.
y+= yVel * elapsedTime;
oldTime = currentTime;

MinGW does not fully support C++11 features yet. This may be one of those items that isn't quite there.

I would ask why you are trying to free/copy the rotated image at this point?

Might I recommend the following instead:

SDL_FreeSurface(image);
image = rotation;

What this code does is frees the original image and sets the image SDL_Surface pointer to the address of the rotated image. My only worry with this code is the loss of image quality over multiple rotations (I am not positive that image quality would be lost, but it seems reasonable to me). It might instead be better to have something more like this:

if(oldRotation != newRotation)
{
	 if(displayImage != NULL && displayImage != original_Image) SDL_FreeSurface(displayImage);
	 displayImage = rotozoomSurface(original_Image, newRotation, 1, 1);
	 oldRotation = newRotation;
}

This code makes new rotation images based off the originally loaded image, and only does so when the rotation has changed.

It sounds to me, like what you are asking how to display graphics on the screen instead of just text?

If so this is normally done via a library or system API. I don't know the libraries to do this with pure Java, but on Android there is an example program that may get you started in the right direction: http://developer.and...nder/index.html

Another example app on Android specifically is: http://developer.and...nake/index.html

If you need a faster frame rate than those will allow I recommend looking into AndEngine. I have used it, and found it to be a pretty good 2d library for Android backed by OpenGL ES.

Hopefully that helps.

P.S. I strongly recommend reading up on the Android Application life cycle before starting an Android game.

No... The number of objects you are currently drawing should easily go at >60fps on modern processors at that resolution. I am not sure what lag you refer to by just looking at the code; however, if I recall correctly (been a while since I have done anything with SDL) the SDL_KEYDOWN event is only triggered when the key is first pressed, so none of that code occurs when the key is held down until Windows (or other OS) enables key repeat. In other words right now, you are looking at the key up/down events, but not the key up/down state. An event only happens during state change.