Glad its appreciated, if you have any more trouble with physics stuff though, I reccomend you look at a couple of a-level/as-level physics revision guides, as everything I said was based of a-level and GCSE physics.

hmm, I've dug out the code that I used for the example I showed you, its more or less what you have:

Code:

if(LeftDown ==true){
if(XPlus>-MaxSpeed){
XPlus -= Speed;
}
}
if(RightDown == true){
if(XPlus<MaxSpeed){
XPlus += Speed;
}
}
if(UpDown == true){
if(YPlus<MaxSpeed){
YPlus += Speed;
}
}
if(DownDown == true){
if(YPlus>-MaxSpeed){
YPlus -= Speed;
}
}
//left hittest;
if(XCentre == LeftLimit+HWidth){
XPlus*=-1;
}
if(XCentre < LeftLimit+HWidth){
XPlus = XPlus/InertiaLoss;
XCentre = LeftLimit+HWidth-XPlus;
}
//right hittest
if(XCentre == RightLimit-HWidth){
XPlus*=-1;
}
if(XCentre > RightLimit-HWidth){
XPlus = XPlus/InertiaLoss;
XCentre = RightLimit-HWidth-XPlus;
}
//top hittest
if(YCentre == TopLimit-HWidth){
YPlus*=-1;
}
if(YCentre > TopLimit-HWidth){
YPlus = YPlus/-InertiaLoss;
YCentre = TopLimit-HWidth-YPlus;
}
//bottom hittest
if(YCentre == BottomLimit+HWidth){
YPlus*=-1;
}
if(YCentre < BottomLimit+HWidth){
YPlus = YPlus/-InertiaLoss;
YCentre = BottomLimit+HWidth-YPlus;
}
//
XCentre+=XPlus;
YCentre+=YPlus;

I think you mean

speed = maxspeed

instead of:

 speed *=maxspeed

apart from that, it looks pretty good.

[EDIT]

sorry, I think you're right actually, normalising makes it equal to one right?

True, but its easier to approximate with speed, forces and acceleration. Believe me, you only need momentum for collisions.

Well, thinking in vectors is probably best, unless your rendering system is using polar coordinates, which i seriously doubt it is.

basically, what it boils down to is:

figure out all the stuff in a line, with an angle at which it is acting.

then use trigonometry to convert this line/angle to an x-component and a y-component

also, its important to stop trying to think about momentum. Its more or less irrelevant except for when you're doing collisions and need to maintain the same energy across the collision.

I'll try to work out some code for you, give me 5 mins and I'll have somthing done...

That would be really nice for a kinda cartoony game with light, or something like gish, with a tar or liquid enemy...

This is somthing I made a while ago, only with accelleration, not force or thrust, utilising the techniques I've got here.

http://www.mediafire.com/file/3jzjamdwy5n/ShockAndAwe version 0.02.zip

However, I'm guessing you want to go for more asteroids style movement, but this can be done using exactly the same techniques, but with a bit of trig for the force and stuff...

ok, coupla things:

1) speed IS NOT mass * accelleration, FORCE = Mass * accelleration.

2) momentum = Mass*Velocity

3) thrust = force = mass*accelleration

Update Loop
{
     momentum = speed;
     thrust = (vector based on left thumbstick position)
     speed = (thrust + momentum)* acceleration;
     if(speed.Length() > maxSpeed)
     {
          speed = speed.Normalize() * maxSpeed;
     }
}

if you want to have it realistic like, try having it more like this:

Code:

Update loop
{
  Force = 1.25
  Mass = mass of the ship
  acceleration = Force/Mass
  speed = speed+ acceleration
  if(speed+acceleration<=maxSpeed)
  {
    speed = speed+acceleration
  }
}

this SHOULD help with about 90% of your problems, for doing edge collisions (assumming vertical and horizontal lines), when colliding the top or bottom, simply times the y component of the speed by -1, when colliding the left or right, times the x component by -1

[Code::Blocks, no contest.]

Code::Blocks, no contest.

Don't get me wrong, I was a VERY heavy Dev-C++ user back in the day, completing a many game projects with it; so it sort of has a soft spot on me.

However this was back in 2005/2006 and the latest version of Code::Blocks (be sure to get a nightly build) will better serve you for the following reasons and more:

• Much less buggier in comparison, Dev-C++ will crash occasionally. Code::Blocks is actively developed (Dev-C++ is a long dead project).
• Visual debugger that works well. Dev-C++'s visual debugger doesn't always work. And you'll want a debugger if you intend on doing anything big (over 10k lines i'd say personally).
• Can use the latest versions of MinGW, with GCC 4.x
• For those who like devpaks, it has a devpack importer and can connect to Dev-C++'s devpak servers.

In reality, there's almost no reason to use Dev-C++ over Code::Blocks these days.

[edit]
Also, Microsoft's C++ Express Edition Compiler has no debugger as far as I know.

I've uses the express edition more than c::b although I prefer the latter. However I'm pretty sure that vc++ does have a debugger, I *think* I've used it...

I've recently discovered that listening to Remember the name by fort minor is very motivational whilst working on some code.

Also, I've recently got into the pc gamer podcast, especially as they have slightly more coverage of indie games than other games media, albeit in a "I had 20 mins and I played this really amazing indie flash game/spelunky" kind of way.

Code blocks does have code completion. IMO its better than the code completion in visual studio, but I may have just had it set up incorrectly.

[controllable]

A joystick-controllable sprite on the 5200?

(So edgy and topical!)

That'll be $500 please then.

Try looking at some sourcecode to see how others do it. If I recall correctly there is a wiki like thing devoted to all things rougelike so they should have at least one good example. Derek yu also released the spelunky source code recently, so if you want somthing along them lines and you have gm check it out.

Ah, sense is made, excellent.

WebGL is pretty similar to ordinary OpenGL, for most of the functions, just replace gl.foo with glFoo and things will work fine. The original NeHe tutorials are quite old and use a lot of features which are deprecated in the current specification. Apparently the NeHe people are making a new set of tutorials that are compatible with OpenGl 3.x though so those will be good whenever they are released.

ummm, shouldn't you be using glFoo anyway? Or are you using it in java?

Thanks all of you for your super-prompt responses, and for all your example code. I think I'm going to end up using msqrt's code, as its easier for me to understand, and seems to work pretty well. Again, thanks for all you're responses.

Thanks!

I need help initialising opengl in SDL, thusfar I have some code from a nehe tutorial which will create a window within which is fine for rendering, assuming you want to render bettween the z values -1 and 1.

I'm using this code to initialise opengl and create the SDL window:

Code:

if( SDL_Init( SDL_INIT_VIDEO ) != 0 )
{
  return false;
}
//all values are "at least"!
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 5); SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
// Set the title.
SDL_WM_SetCaption(title, title);
// Flags tell SDL about the type of window we are creating.
int flags = SDL_OPENGL;
if(fullscreen == true)
{
flags |= SDL_FULLSCREEN;
}
// Create the window
SDL_Surface * screen = SDL_SetVideoMode( width, height, bpp, flags);

if(screen == 0)
{
return false;
}
//SDL doesn't trigger off a ResizeEvent at startup, but as we need this for OpenGL, we do this ourself[img][/img]
SDL_Event resizeEvent;
resizeEvent.type = SDL_VIDEORESIZE;
resizeEvent.resize.w = width;
resizeEvent.resize.h = height;

SDL_PushEvent(&resizeEvent);

this creates a window which looks like this (I've got a square being with centre (0,0,0)) (ignore this bit at the bottom right):


Does anyone have any tried and tested code which will create a opengl rendering context with full 3d,and scaled so that a square will be a square in a rectangular window, as opposed to a rectangle as it is in my example...

Thanks in advance...

Hmm, it shouldn't be TOO heavy on memory unless you had a lot of them...
At least, you would probably have about 2^n nodes (where branches split) or branches, although that might be too much, I don't know...

If you take a look on openprocessing there are usually quite a few l-system sketches, and a couple (if I remember rightly) that move around, as if they were in the wind.

I either listen to podcasts or music, or I watch programmes on IPlayer