to plot graphics the pixel data should be in ints
if we use double for calculating. then we should perform casting. casting is very expansive.
so can we use int ? what to use double or int.
Printable View
to plot graphics the pixel data should be in ints
if we use double for calculating. then we should perform casting. casting is very expansive.
so can we use int ? what to use double or int.
I'm not clear about the problem you are having there.
Code:double positin=0;
double velocity=0;
double accleartin.=0;
//do some thing
draw_object_at((int)positin);//argument should be int
which is better first or secondCode:
int positin=0;
int velocity=0;
int accleartin.=0;
//do some thing
draw_object_at(positin);//no need of casting
Casting probably isn't taking up a significant amount of time compared to the time it takes to actually put the object on-screen.
If you can represent your acceleration, velocity, and position as integers without losing precision, go ahead; I for one appreciate the precision of floating point numbers when it comes to physics-y motion like this.
I would use floats and then cast to int when needed. Integers are not good when it comes to graphics b/c there is no allowance for fractional values and graphics code is full of fractional values in matrices, vectors, etc. Why do you need integers for rendering?
If you need to draw pixel by pixel using only integers, I would suggest just rounding in whatever function you have actually setting those pixels. It will help keep your code clean and readable. The rest of your calculations should probably be done in floats because it suits most of the graphics code you'll have to write.
However, if you're using almost any graphics API you shouldn't have to worry about this.
Also, in relation to the speed of most computers around today, casting to a float isn't a very expensive operation.
If you for some reason need to use ints (and only ints), you can do most 2d graphics with an extension of the Bresenham line algorithm called the Midpoint Line Algorithm. There's some info on that algorithm here. This kind of stuff is pretty heavy on math though, so if you want to avoid that, use a graphics API.
I'm using Allegro.Quote:
However, if you're using almost any graphics API you shouldn't have to worry about this.
FWIW Allegro 5's graphics routines take floats as arguments, and version 5 is a *huge* improvement over previous versions anyway.Quote:
Originally Posted by sagar474