sprite trajectory (10deg, 20deg,30deg)
Blitz3D Forums/Blitz3D Beginners Area/sprite trajectory (10deg, 20deg,30deg)
| ||
| Is there any code kicking around showing how to draw a sprite along a given angle ? eg. say I want a sprite to move along a path, 1 pixel at a time, and that path is at 10 degrees - I could use an array full of precalculated values and add these to the x & y or... ...I'm hoping I could use some kind of equation to work it out "on the fly" Any ideas ? |
| ||
| you don't need any kind of array, use Sin() and Cos() to precalculate the step values for the changes in x,y (in 2d) example in the x,y plane for an angle of 10 degrees :- dx# = sin(10) dy# = cos(10) now you just modify the sprite's x,y by adding on dx,dy each frame. |
| ||
| Thanks Brendane, but isn't using sin and cos quite costly in terms of cpu performance ? I thought there may be a less intensive approach instead |
| ||
| Hi Dax, In your instance it's a single pre-calculation - you call sin/cos to get the delta values for your angle just once - no need to calculate the deltas again unless the angle changes. There is no real problem using sin/cos in these days of modern processors - go for it. |
| ||
| by the way, isn't your working the wrong way around ? dx# = cos (10) dy# = sin (10) |
| ||
| Yeah :) could be. |
| ||
| Hi Brendane, so just to confirm, you think its a good idea to perform COS & SIN every frame ? (I have 4 sprites, and that means 4xCOS and 4xSIN calcs every frame which would be costly on cpu wouldn't it ?) Or are you saying pre-calc the values and put them in an array ? That way the only hit on the cpu is retrieving the values from the array |
| ||
| Ultimately a precalculated array would be the faster alternative, but with modern CPUs you'd need to be hitting COS and SIN pretty hard before you'd notice the speed difference. Still, every little bit of speed counts :-) |
| ||
| 8 calls to sin and cos is blisteringly fast. There's very little point in precalculating them unless you're at least doing a few hundred per frame. I've done thousands of calls per frame and although it was faster to use lookup tables, it still wasn't slow with sin and cos, even on a moderate ( around 1Ghz ) CPU. |
| ||
| The main point to be made here is that planning for optimisation is good - but don't worry too much about speed issues until you have a working piece of software. Then you can apply some profiling technique and figure out what parts of code you should try and optimise. I've worked on commercial 3d engines for big games companies and it's pretty much always the last thing I'd do. For a new programmer (if indeed you are) the main skill for you to develop is to structure and modularise your code well. |
| ||
| @Dax Trajero Brendane has a good point above |
| ||
| People keep mentioning 1GHz processors - I'm doing a retro remake and I wanted it to be available on Pentium II class processors at least. Thats why I'm looking at cpu optimisation techniques for SIN & COS. I do take Brendane's advice on board and will perhaps leave optimisation til the end. Things are going quite nicely by the way - writing my first game is proving to be a very rewarding experience. I've just written my first timer code yesterday and am starting on types today (tonight) -Dax |
| ||
| Dax, PIIs have substantial maths on board so sin and cos are not a big worry. Optimisations come looking at your code once you've finshed, where you can shave cycles off loops, or indeed remove loops altogther. For example. You might not need to run AI code for every enemy every loop. You might be able to get away with running 1 ai code per game loop and running through your enemies therefore removing an entire loop from you main loop. |
| ||
I use a simple method of spreading function calls out in the main loop e.g.gFrame=0 ;main loop While Not KeyHit(1) gFrame=(gFrame+1) Mod 100 If gFrame Mod 2=0 Then Update_AI() ;call every 2 frames If gFrame Mod 4=0 Then Update_Physics() ;call every 4 frames If gFrame Mod 10=0 Then Update_Rooms() ;call every 10 frames Wend |
   |