Starting To Make Games

[Octavious]

OK, now first thing first, I don't have a shiny new GP2X, and I sold my GP32
Second thing, I won't even begin coding for it until the end of this year, maybe
Third, I still don't know that much but bear with me please...

I am in a video game design course in college now, programming option
I am learning more from myself than the proffe usually because he has to help all the stupid people who can't get the simple topics, and have compile errors out the ass
I am working on a simple windows game in 640x480 and its all in C++
I use VisualStudio.NET for all my programming (I believe its 2003, not sure)
I am just doing some simple stuff, (the game is designed to simulate something our robotics team is doing) and learing along the way (I am trying to implement physics into my game right now)

Anyways, the point of the game is there are 6 robots on the court, 3 red, 3 blue, and there are now 18 balls randomly placed into the middle of the court. Each team rolls the balls into their goal or the shooter robots shoot the balls through a hole 3 feet up.

Its a top down, 2d game. Right now I have collision detection for the walls (my bot is stuck in the court) controls for up down left right (real sloppy, but ill be learning some sprite rotation later) splash screen and credits screen, and 18 randomly paced balls on the court (you just drive under them, no rolling or pushing yet)

What I want to know is, If I make a windows game (Ill be doing little ones for a few years now), what do I need to do to make it work on the GP2X? I plan on buying one around August... I miss my '32 and from what I hear, the GP2X solved all the problems I had with the '32 (except the damn batteries..)

Thx

also, can anyone point me to some C++ code examples of say, integrating friction in a game (what governs how much the balls slow down?)

Thx again

~Octavious

 

[yaustar]

Depending on what you use to render your window, it could as simple as a 1 day job to a complex 'several week' job.

Things to take in the account for the GP2X:
Window Size (320x240)
No floating point (limit the use of floats or don't use them altogether)
SDL is supported and a nice cross platform API (so you can use it on Windows).
(Much) Slower CPU

Friction: either fake it or use mechanics. One method I used a long time ago was to just multiply the velocity by a number less then one every timestep.

eg
float friction = 0.85;
velocity *= friction;

Good luck

 

[Octavious]

HA!

thats the exact same thing I did, I even used .85

I had something that everytime I called it,

Fball*=Friction;
Velocityx=(Fball/mass)*timepass;
set.Xpos=velocityx;

I had generic numbers for most of those
The processor can still do floating point, its just slower right?
how many floating points can I have in my game?

if I multiply by say, .85, how often should I call it? like, every 200miliseconds or what?

and, cause I am curious, whats the mechanics aspect? can I get a few lines demo?

Thx so much, and last of all, is there a guide or something on going from a windows app to a GP2x app?



~Octavious

 

[yaustar]

The Gp2X doesn't have a Floating Point Unit so it 'emluates' it in software which is REALLY slow. In general, you shouldn't do any flating point maths. Read up on Fixed point maths for that.

Mechanics you have to take in consideration of forces and friction coefficients which mat be a bit much if you are making a fun game rather then a simulation.

Apply friction at a consistent timestep eg every 0.05 secs, no less no more. Or have a factor that is time based so you can use deltatime every game loop instead of working out how many timesteps have passed.

 

[rokdcasbah]

i think by mechanics yaustar means, do a model based on newtonian physics. in which case friction is represented in two ways, the extra force it takes to get something moving (you probably don't need this) and the friction working against something once it is moving. this friction is modeled as a force acting on your object in the opposite direction.

we know that: force = mass * acceleration

so how does the friction lead to acceleration? you create a coefficient of friction. the mass of the ball raises or lowers it...(specifically, the friction depends on the "normal force" created by the ball's weight against the floor.)

then you use your kinematics equations, like
velocity = initial velocity + (acceleration * time)

so the ball "accelerates" -0.85 (or whatever) pixels/second, every 200ms (or whatever). you can see where, after enough time, your velocity reaches zero.

but wait! there's no reason to worry about all the variables, unless you're using different size balls and want there to be a visible difference in their motion. if every ball is the same size, no one's lifting the balls, etc...everything stays the same. so all you would do is keep subtracting along some time interval until you hit zero.

or, you could do what you're doing now, which is multiply by a fraction so that the speed keeps decreasing. but note that this is not what happens in the real world...if you kept multiplying velocity by 0.85 your object would never stop! just slow to a crawl. also, it will look and "feel" different than real friction, which again is best described as a force in the opposite direction...consequently, we're subtracting rather than multiplying.

jeez. sorry that's so long-winded. but hopefully it helps.

 

[woogal]

The Gp2X doesn't have a Floating Point Unit so it 'emluates' it in software which is REALLY slow.

​

It's only really slow if you use a version of gcc below 3.3 (or is it 3.2? I can't remember now). Use a recent gcc and things that use a lot of floating point (eg quake) start to run several times quicker, and for things with only a few floating point calculations you might not even notice the difference. Unless you're writing something like a complex 3d engine you usually don't need to worry too much about using floats anymore.

 

[Octavious]

ok, so ill subtract rather than multiply
I knew if I was going to go multiply, I would have to set a number where it gets to that it is good enough to stop

well, Ill put that in today if I can wrap my head around it and tell yall how it went

Every game I make, I want to add a physics concept to it, I love life like-ness in games (Oblivion will rock and HL2 I still play with new texture mods)

Thx again

~Octavious

 

[yaustar]

It's only really slow if you use a version of gcc below 3.3 (or is it 3.2? I can't remember now). Use a recent gcc and things that use a lot of floating point (eg quake) start to run several times quicker, and for things with only a few floating point calculations you might not even notice the difference. Unless you're writing something like a complex 3d engine you usually don't need to worry too much about using floats anymore.

​

Really? Fantastic, it saves me a little trouble later on

Also, I like to retract another statement, even though the screen size is 320x240, it looks like you can scale it down with the new SDL libs for the GP2x
http://www.gp32x.de/board/index.php?showtopic=25204

 

[Jasper]

I study physics and have programmed these kind of simulations slightly too many times. (cuz i am a bad programmer at least sometimes)
colisions with the wall has forces in two directions

along colision normal (the bounce)
along surface (the surface friction)

I wont explain all the physics (so much algebra, don't know readers' level at it, time cost).
I'll write it out:
The meanings of the variables b_spd,e_spd, resp. begin and end speed, mass particle mass, normal, surf_v direction speed particle along surface, timestep time step of simulation, inpr inproduct, len length of vector

//sliding slide_frict>=0
e_spd=b_spd-slide_frict*mass*inpr(b_spd,normal)* surf_v /(timestep*len(normal)*len(surf_v))

//bouncing and friction 0<=bounce_frict <=1
e_spd=b_spd-(2-bounce_frict )* inpr(b_spd,normal) *normal/len(normal)^2

the order is important! sliding first, then bouncing; normalx*b_spdx+normaly*b_spdy doesnt change while bouncing, while: normaly*b_spdx-normalx*b_spdy does change in bouncing

in two dimensions: inpr( a,b )=ax*bx+ay*by and len(a)=sqrt(inpr( a,a ))=sqrt(ax*ax+ay*ay)
surf_v={normaly,-normalx}

This will work for the walls, a similar method could be given for colisions between two balls, however when three balls are near each other they can interact in weird (and unphysical) ways. (first colision prevents balls going through each other, second can fuck that up)
Oh ye if the wall is infinite a point is inside when inpr(normal,p)<0, and a ball is inside when inpr(normal,p-normal*radius/len(normal)) By the way if you make len(normal)==1 by normalising(dividing by length) you can remove all the len(normal)'s

If you want to check the formulas, some things that need to be true:
for bounce:
-energy doesn't increase: 0.5*mass*len(b_spd)^2>=0.5*mass*len(e_spd)^2
(so len(b_spd)>=len(e_spd) )
-all force along normal: e_spd=b_spd+factor*normal for some factor
-end speed not heading into wall: inpr(e_spd,normal)<=0
for slide:
-energy doesn't increase again
-linear with normal force and in direction of surf_v along surface
in form: e_spd=b_spd+factor*inpr(normal,b_spd)* for some factor

 

[PokeParadox]

It's only really slow if you use a version of gcc below 3.3 (or is it 3.2? I can't remember now). Use a recent gcc and things that use a lot of floating point (eg quake) start to run several times quicker, and for things with only a few floating point calculations you might not even notice the difference. Unless you're writing something like a complex 3d engine you usually don't need to worry too much about using floats anymore.

​

Really? Fantastic, it saves me a little trouble later on

Also, I like to retract another statement, even though the screen size is 320x240, it looks like you can scale it down with the new SDL libs for the GP2x
http://www.gp32x.de/board/index.php?showtopic=25204

To be quite honest, compilers are becoming quite clever nowadays... even so it's probably better to only use floats in initial setup, convert them to fixed point, and use the fixed numbers from then on. But mostly you can get away with a float here and there.