Giygas learns the art of C++

Excellent job figuring out things on your own! I'd really like to try out your game.

Also, maybe you could try MMF2-Styled Fastloop Collisions? If you don't know what those are, check this out. It's a tutorial for MMF2, but you can translate it to C++ pretty easily if you think about it.

This post has been edited by OniLink10 on Oct 18 2009, 10:41 PM

Thanks, I just need to memorize the functions to load the sprites and move them before I go on.

Honestly, what I realise is that using windows in a game makes the coding almost no different- you still use the basic and advanced functions you did with the non-SFML games, only now it looks better :3

So i've been messing around with a platformer ( trying to see what I can do all by myself by expirmenting ) and after a long time, I have a couple of features that I hadn't put into the previous version.

Animations ( Oh god this part really sucked )
Jumping ( Working on gravity )
Acceleration ( Working on Deceleration... )

And uh, next i'm going to work out the Gravity and Deceleration, then see if I can get very basic block collisions.

:3

Animations are one of the worst parts. At the NCFC, I might release my game's source code so you can see how I did it. My technique is terrible and can be improved 10-fold, but it works.

Animations: simple. Make a function for sleep (similar to that in GM):

clock() returns the "clock ticks" since the beginning of the program. The ticks is usually some weird number, so we multiply the milliseconds we want by the clock ticks we want, and divide by 1000 so the time is in milliseconds instead of seconds. Pretty simple.

Now, in the loop for SFML:

clock() returns the "clock ticks" since the beginning of the program. The ticks is usually some weird number, so we multiply the milliseconds we want by the clock ticks we want, and divide by 1000 so the time is in milliseconds instead of seconds. Pretty simple.

Now, in the loop for SFML:

That's a terrible way to sleep. The while loop eats up CPU cycles. Unfortunately, there's no standard way to sleep, so you'll have to use MinGW's POSIX libraries, or use sf::Sleep(which is already used by RenderWindow.Display() to limit framerate).

Well, as I said, I already programmed the animations in, using a very simple but pathetic excuse of a code.

I can't post the code I used atm, but all I did was something like

On the press left/right command:

AS Stands for Animation Speed. When you hold left or right, it goes up by one.

On the load image command:

And then the code to switch frames:

And then some other **** to make him stand when not moving, and jumping sprite when jumping. :U

What do you plan on doing to sleep, then? And, either way, I completely forgot about sf::Sleep(). :/

usleep() in the POSIX libraries is included with MinGW, and turns off the program temporarily.

Gravity was much easier than I thought it was going to be... Go figure :U
When in the "Left Jump" sprite and in the air, you can still move to the right but it no longer goes to the "Right Jump" sprite ( And Vice Versa ) in Mario Brothers honor.
As i've stated, gravity...
When hitting the floor, Mario also automatically changes to his "Left" or "Right" standing pose, depending on his last direction...
Animation now speeds up/slows down depending on how fast Mario is moving...
Hmm... Now I need to add Running, and make you jump higher when running. Then I can move onto some more complicated stuff :U

I didn't know that. :/

Anyways, you learn something new every day, I suppose.

Anyways, for gravity, simply do it the same way you did it in Game Maker/whatever you used before C++.

um
I don't think that Gravity_Direction and Gravity_Force would work :U

So? Make them yourself.

#define pi 3.1415926535898

// etc

x+=cos(gravity_direction*pi/180)*gravity;
y-=sin(gravity_direction*pi/180)*gravity;

Or, if it's just affecting one axis, just use y-=gravity or something of the like.

This post has been edited by RetroXYZ on Oct 22 2009, 06:41 PM

I already have a decent system, but i'll mess around with defines and functions later... Would really make this easier. But for now, just a crude version of ******s First Game.

Running done, moving onto a Goomba that moves left and right. :UU:

Well, done for the night.
Working on all this seems pretty easy so far, and I have not even moved on past "Displaying a Sprite".

I peeked a bit at Audio, though... Just because I can, I added a sound effect for jumping and stomping a goomba.
Speaking of Goomba's, it now moves left and right ( Reverses when it hits the adge of screen ) and has an animation. Jumping on it results in it being squished, mario doing a little hop, and a nice sound effect.

:3

Excellent job! Are you using Object Lists, Object Vectors, or individual Objects for your game?

Ondividual objects, but i'm going to have to change that soon once I can get Object Lists in.

Definitely use lists, and probably use a separate list for each kind of object. It makes searching for collisions with a certain type much easier, and hogs less time than Vectors, especially when adding new objects.
EDIT: Thanks for correction, Lightning.

This post has been edited by OniLink10 on Oct 23 2009, 03:24 PM

iirc (and it's been a while)


list:
struct list_node {
TYPE object; // sizeof(TYPE) bytes
struct list_node *next; // sizeof(void*) bytes
};

to store n objects in a list, you use (n * (sizeof(TYPE) + sizeof(void*))) bytes


vector:
m = next_highest_power_of_two(n) * sizeof(TYPE);
TYPE *array = malloc(m);

to store n objects in a vector, you use (n * sizeof(TYPE)) bytes in the best case, and ((2(n-1)) * sizeof(TYPE)) bytes in the worst case.


so there's not a clear-cut winner of who hogs more memory. I'd focus on the time-related efficiency more than anything.

Let's say an Object has a 4-Byte Pointer to a Sprite(SFML includes Positions), a 4-Byte Pointer to an Image, and a 1-Byte Animation number. This totals 9 Bytes.

100 of these Objects in a list would take (100*(9+4))=1300 Bytes.
100 of these Objects in a vector would take ((2(100-1))*9)=1782 Bytes.
Not really a big difference, but if you have 100s of objects, it adds up.

Also, vectors are fastest when you aren't adding objects on the fly and you aren't iterating through them(going through them 1-by-1). Lists are fastest when you need to add to them on the fly(most Mario-based games) and you are iterating through them(you probably will iterate for drawing them and collisions).

This post has been edited by OniLink10 on Oct 23 2009, 03:32 PM