13h mode while/ for... :S

Go ahead start laughing 13h, but i like to work with it (becoz i just got the hang of it).

Anyway if i let a ball fly over the screen using a for loop it will go rather slow, but if i let it fly over the screen using a while(my borders defined) loop it goes so much faster that i cant even keep track of the ball.

Therefore i added delay() call in the while loop to slow things down. The first 10 seconds everything is fine and goes at a sortof constant speed, but after that it speeds up and wooosh i can only see the ball back once in a while because its so fast.

Could it be, i say COULD, that the delay is malfunctioning after a while. Because i use the same functions ( and in the same order) in the for loop as in the while loop.

I would provide some code but i dont have it with me right now.
I'll try to add some code later on to clarify myself.

Oh and i think i saw it somewhere around here that you control speed using some kind of thing... because not every comp is as fast as the other thus comp 1 would plot things slower then comp
2.

It sounds like maybe you are incrementing your speed somewhere in your loop - hard to tell without code. It seems to me that there shouldn't be any difference in speed between a for loop and a while loop... both involve a test, a jump, and (better) change a variable somewhere...

In my for loop i only use a x++ and y-- for instance to let the thing move, with the while loop i dos something like this;

Code:

---

while{
 move++;
 x=x+move*COS[direction];
 y=y+move*SIN[direction];
 draw_ball(x,y,15) /*15 is white color*/
 vretrace();
 draw_ball(x,y,0);
 }

---

Hope this is what you ment, although here im also using a ++ in the while loop, but i always multiply it with the direction.
Oh btw direction is a random number from 0 till 360, SIN and COS are already calculated when i say COS[direction].

woot gtg last day of school (btw i graduated :D:D).

The speed of your ball will also depend on how much you are incrementing direction. Since you are not converting radians to degrees (radians*PI/180) if you increment direction by 1 you will get some very wacky results. There are approximately 6.2831 radians in any given circle or 2PI. So you see if you increment direction by 1.0 you are incrementing by far more than 1 degree.

There are two ways to approach this:

You can either figure out what 1 degree would be in radians (.0174 radians) and increment by that or you can convert all radians to degrees.

Don't apologize for using mode 13h - if we were willing to admit it, most of us here started in that mode. Learn as much as you can about graphics/3D in DOS and when you move to DirectX you will have a much better handle on what's taking place. I don't know how people can just jump into DirectX with no graphics experience in DOS. But since DOS is dead now with XP I realize that some newcomers to C don't really have much of a choice.

:)

Well, Bubba, it's possible to learn the concepts for 3D stuff and apply them with a very basic graphics library like SDL that doesn't require much to learn, before moving on to OpenGL or DirectX. That's what I did - sorta...I need to do that "moving on" bit.

Code:

---

while{
 move++;
 x=x+move*COS[direction];
 y=y+move*SIN[direction];
 draw_ball(x,y,15) /*15 is white color*/
 vretrace();
 draw_ball(x,y,0);
 }

---

That is not what you want to do. I'm not sure what your "move" variable is supposed to be tracking, but what it's actually doing is increasing the speed of the ball (it's acting as the hypotenuse in the triangle you're using for the trig). Until a collision, your X and Y will both change at a constant rate (it's linear movement, afterall... unless you're trying to do something incredibly strange). Outside your while loop, do this:

Code:

---

deltax=ballspeed*COS[direction];
deltay=ballspeed*SIN[direction];

---

(I would also suggest *not* using lookup tables, and just using the trig functions. Lookup tables for trig functions have become obsolete because the time it takes to access the memory and load it into the cache and registers is quite comparable to the time it takes for the function call to the trig function itself.)

Anyway, inside your while loop, you'll want this:

Code:

---

while{
 x+=deltax;
 y+=deltay;
 draw_ball(x,y,15) /*15 is white color*/
 vretrace();
 draw_ball(x,y,0);
 }

---

I hope I made that clear. I've written about it in more detail here, which hopefully will be of some use to you. I also cover how to do the ball movement without any trig at all (except when initalizing the program). Good luck, and I hope to see the finished results posted soon.

He that will help alot ill check it out as soon as possible,
also as i was trying to find my error i came up with another solution, but wich is giving me some problems.

To change movement in a random direction i would do something like this

Code:

---

float dx,dy;
float x,y;
float slope;
int count=0;

/*fixed position to start from*/
x=160;
y=180;

/*since i move from the bottom of the screen to the ceiling, dx has to be between 0 and 320, and dy is always 0*/
dx=rand()%320;
dy=0;

slope=( (dx-x)/(dy-y) );

while(count<5){
    /*just move it for 40 pixels ( 160+40=200)*/
    while(x<200){
      x++;
      y=slope*x;
     
      draw_ball(x,y,15);
      vretrace();
      draw_ball(x,y,0);
      }
    count++;
}

---

Something like this would also work right?
+ Then i dont have to worry about radians and degrees.

::edit::
while i was posting Blackrat was also posting so i just edit this thing. I already have the collision thing set up and i understand how the angle is going to change once it bounced, but because the ball always starts in the same direction it will always follow the same path...Therefor i needed the random direction to let the ball start, thus changing the overall route of it.
BTW: when its finished ill let you know (but im leaving very soon to Nigeria for a year and i dont think ill be able to code there alot),
once ive got everybasic thing up i would want to add some cool features like a tipsy mode and a stoned mode...
Tipsy mode would be envoked whenever you are 5 points ahead of your opponent. Then the ball would move in sinusses towards you and once it has bounced of your paddle it wouldnt move in sinusses anylonger untill the opponent touches the ball again...
And stoned mode would be simpler to do as i would just delay the movement of the paddle by a random time between ....and ... millisec.

Well thx all of you i think ive got it , i think..

Your code has become a bit confusing. dx and dy are the symbols used for "change in x" and "change in y" So this doesn't really make sense:
slope=( (dx-x)/(dy-y) );
Slope is rise/run, but I think you switched you switched your axises, so that is dx/dy. You don't want to have that subtraction in there (work it out on paper for a second...that's going to give you some strange numbers) You would just do
slope=dx/dy; //or dy/dx if you didn't switch the axises
As your code is now, that's going to give you a division by 0 error. But...actually... you don't need the slope at all. Just dy and dx.

A code snippet:

Code:

---

float dx,dy;
float x,y;
int count=0;

/*fixed position to start from*/
x=160;
y=180;

/*since i move from the bottom of the screen to the ceiling, dx has to be between 0 and 320, and dy is always 0*/
dx=rand()*320; //this was a bit wrong
//rand returns a value between 0 and 1.  You mean rand()*320
//which will return results in the desired domain...make sure you
//seed the generator so that every game isn't the same though
dy=0;  //this is going to give you NO movement on one axis

while(count<5){
    /*just move it for 40 pixels ( 160+40=200)*/
    while(x<200){
      x+=dx;  //just add the change in each variable to the variable
      y+=dy;  //ditto
     
      draw_ball(x,y,15);
      vretrace();
      draw_ball(x,y,0);
      }
    count++;
}

---

To make the ball move back the other way, you'll have to switch the sign of dx or dy (depends on how your axises are oriented) (just dx*=-1; works)

I'm not sure if I covered everything or not... just post a question about anything I missed.

The lookup table vs. cache speed sounds suspect to me. Trig functions take an awfully long time to execute as opposed to cache misses. I'll check my IA-32 manuals to analyze the cost of each situation. But as far as putting the trig function outside of the loop, that's definitely correct.

You might think, what's all the fuss with a simple ball program. The fuss is if you get into good habits you will produce faster code when you dive into more complex games and apps.

At first glance I did not notice that you were incrementing move which really is speeding the ball up each frame. Kudos to blackrat364 for noticing.

:)

Haha, you edited as I posted again. This is a new post just so the first one doesn't get too unwieldy and long. To get the random direction, just do this:

Code:

---

dx=BALLSPEED*cos(rand()*2*PI);
dy=BALLSPEED*sin(rand()*2*PI);

---

Where BALLSPEED is a constant representing the overall speed of the ball...

Quote:

---

Originally posted by Bubba
The lookup table vs. cache speed sounds suspect to me. Trig functions take an awfully long time to execute as opposed to cache misses. I'll check my IA-32 manuals to analyze the cost of each situation. But as far as putting the trig function outside of the loop, that's definitely correct.

You might think, what's all the fuss with a simple ball program. The fuss is if you get into good habits you will produce faster code when you dive into more complex games and apps.

At first glance I did not notice that you were incrementing move which really is speeding the ball up each frame. Kudos to blackrat364 for noticing.

:)

---

Hehe, I got kudos. Anyway, I asked the question about lookup tables here when I was working on programming a 3D engine with SDL :D :D :D I can't find it with a board search though. I believe it's around 40 clock cycles for a trig function (that could be completely wrong, it's from memory and I haven't looked at it in almost a year). To access the lookup table though (which will be done infrequently in this case, so it won't be in the cache) it involves accessing the memory (delay of a few milliseconds), reading it into the cache (thereby replacing something in the cache that might have been used again) and then sticking it in a register. It also destroys the chance of any pipelining that the processor would have done. The lookup tables take memory, and are less accurate...and...just don't use 'em :) They're antiquitated.

Hey thx all of you especially Blackrat, the ball now starts to move in a different direction, though when the angle between the ball movement and the bottom of the screen is too small it takes whiiee long before it ever gets to the other side :D.

Actually this is my first try at a game and i
really get confused sometimes... wich causes errors wich i will not notice later on. And this is also actually the first time that i needed a paper to scribble on while i was coding ::surprised::.
Anyway coding a game is much funny-er then other progs... because sometimes errors can create these strange things in output...
Like yesterday: my whole level borders where gone becoz the ball was moving a lil too quickly and at that time collision wasnt there yet.

Huh anyway thx again ;).
And dont you want any kudos from me :p.
gtg, BBQ at school (with o-lots of booze)