| View previous topic :: View next topic |
| Author |
Message |
clayasaurus
Joined: 21 May 2004
Posts: 857
|
 Posted: Wed May 03, 2006 11:31 am Post subject: |
 |
|
| Quote: |
A question: In my space game, I make alot of 'space rocks' that just float around. In your debugging messages, it says it texturizes about 200 times (1 for each new rock). Is this taking up alot of video memory for no real use? For example, is there 200 allocations of video memory for the same rock image..? I'm not even sure if this is a big deal... because the fix might not be worth the trouble... guess I'm just curious.
|
Oh yes, this is a big deal. What you should do is only load the rock image once with the texture function, and then use the texture data to create the next 200 sprite's.
Which reminds me of a feature I need to add... creating a sprite based on texture info.
[edit]: just added the feature to create frames based off of textures, but barely tested it *doh!*
You can now do...
| Code: |
Sprite s = new Sprite(COLLISION_TYPE.PIXEL, 15);
Texture tex = texture("pongbin/g.png", 1.0);
s.addFrame(tex, "anim1", 1000);
|
|
|
| Back to top |
|
 |
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Thu May 04, 2006 10:29 am Post subject: |
|
|
OK, looks good. What is that 1000 there? I should just use -1 instead?  |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Thu May 04, 2006 11:19 am Post subject: |
|
|
| if you only add one frame it really doesn't matter what time value you use, feel free to use -1 I was playing with the sprite class before and set time between animations to 1 second, which is 1000 milliseconds, and i just copied/pasted it. |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Sun May 07, 2006 12:17 pm Post subject: |
|
|
I've gotten just a little time to work on FreeUniverse / Arc..
I think you should have only two SVN repositories: one development branch, and one release branch. The current "testing" branch should be merged with development -- the changes made in 'testing' will have to be merged with development at some point anyway. When a solid section of testing / development is done, then that code should be placed in release... but having 3 branches means you have to do some juggling between testing and development... everybody else just does development / release anyway 
I also realized you need to call process() every frame, even if you are doing no animation -- just so things like collision detection work (e.g. nx and ny are updated) |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Tue May 09, 2006 11:30 am Post subject: |
|
|
nx and ny allow the sprite to pivot at arbitrary points.
I'll think about the merging of branches, I like having an explicit 'testing' phase where I can just kick back, use the library, and fix bugs and stuff.
I think I will eliminate the 'stable' svn repository, as I'll release the stable form as a .zip file anyway. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Wed May 10, 2006 2:55 pm Post subject: |
|
|
| Quote: | | i'm working on a tutorial here |
I'm very glad you got something up on that site -- I saw it the other day, and I thought Arc would fit perfectly.
Asteroids! yay! |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sun May 14, 2006 10:10 pm Post subject: |
|
|
There is no need to call process() every frame anymore for sprite now, I moved it to be called internally by the draw() function.
I added a new feature for sprite that will move the sprite in the direction its facing, you use s.moveDir(speed); speed of less than 0 will move backwards, greater than 0 will move forwards. I use it right now to control my ships movement based on its angle.
I also simplified the 'getCurrAnim' to just, 'getAnim', likewise with 'setCurrAnim.'
I updated the docs to reflect these changes as well.
Also, I won't be suprised if the development of Arc is kind of slow during the summer, as I'm not exactly lazing around as I first expected to be  |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Tue May 16, 2006 3:18 pm Post subject: |
|
|
| Quote: | | There is no need to call process() every frame anymore for sprite now, I moved it to be called internally by the draw() function. |
Problem with this: I don't want to draw() graphics that are not on the screen, because it's a waste of processing -- so I do (and you should update Arc to do this anyway) a simple onScreen() check before calling draw(). However, if now process() is included in draw, then off-screen collision detection will not work.
I had to do this, because I noticed that draw() was taking up practically all the time in my program, because so many ships / stations were in space, but not currently on the screen. However, I want collision detection to still work off-screen.
| Quote: | | I added a new feature for sprite that will move the sprite in the direction its facing, you use s.moveDir(speed); speed of less than 0 will move backwards, greater than 0 will move forwards. I use it right now to control my ships movement based on its angle. |
OK, I've already made up angle functions, but those are going to be helpful. You should also, if you do not have that function already, have a pointTo(Sprite S) and pointTo(X, Y) function, that makes the sprite 'point at' the target coordinates.
It also seems like calcPivot() might potentially be a time-waster for my application, because it is doing calculations for collision detection pivotting, but none of my sprites' pivots differ from (0,0) -- I wonder if there is an elegant way to get around this? |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Tue May 16, 2006 6:30 pm Post subject: |
|
|
| Phr00t wrote: |
Problem with this: I don't want to draw() graphics that are not on the screen, because it's a waste of processing -- so I do (and you should update Arc to do this anyway) a simple onScreen() check before calling draw(). However, if now process() is included in draw, then off-screen collision detection will not work.
I had to do this, because I noticed that draw() was taking up practically all the time in my program, because so many ships / stations were in space, but not currently on the screen. However, I want collision detection to still work off-screen.
|
True. I'll revert back to the process() being called manually, then.
| Quote: | | pointTo(Sprite S) and pointTo(X, Y) function, that makes the sprite 'point at' the target coordinates. |
Sure, I've done this before and it would be easy to reimplement it for Sprite.
I'll give an option as to how many degrees to rotate each time (0 will just make it face that direction right away), and how fast it will rotate as well.
| Quote: |
It also seems like calcPivot() might potentially be a time-waster for my application, because it is doing calculations for collision detection pivotting, but none of my sprites' pivots differ from (0,0) -- I wonder if there is an elegant way to get around this? |
Solved. It checks to see if pivots are 0,0 and then if it is then it won't do calculations. Changes will be in shortly with all these features. |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Tue May 16, 2006 7:02 pm Post subject: |
|
|
| Quote: | | Changes will be in shortly with all these features. |
Wonderful |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed May 17, 2006 3:05 am Post subject: |
|
|
| changes are in the sprite, i have to get going now but tell me how they work for you. k bye. |
|
| Back to top |
|
|
Phr00t
Joined: 03 Mar 2006
Posts: 203
|
| Posted: Wed May 17, 2006 8:42 am Post subject: |
|
|
That is some crazy code for pointTo you currently have, this is all you need:
| Code: | // angle maths
float pointAtAngle(double X, double Y, double targetX, double targetY) {
return 180 - (atan2( targetX-X, targetY-Y ) * 57.295785);;
}
double moveToValueX(float ang) { return (sin(((180-ang) * 0.0174520069808))); }
double moveToValueY(float ang) { return (cos(((180-ang) * 0.0174520069808))); }
float angleDistance(float ang1, float ang2) {
if( ang1 > 360 ) ang1 -= 360;
if( ang1 < 0 ) ang1 += 360;
if( ang2 > 360 ) ang2 -= 360;
if( ang2 < 0 ) ang2 += 360;
float retval = fabs( ang1 - ang2 );
if( retval > 180 ) retval = 360 - retval;
return retval;
} |
pointAtAngle doesn't need to be anything more than a single atan2 call, with a little radian -> degree conversion. This is what I am currently using in my FreeUniverse game, and it works good.
Another thing... I believe I want to pull out calcPivot as a public function, because I am not using your animation, rotation speeds, or that rotateLeft() stuff. All I need is just nx and ny set. Maybe you should split up the process() function into process_collision_info(), process_animation() and process_rotation(). You can still have a process() that does it all, but it should be called process_all(). That way, a user can pick and choose what processing they actually need to do per sprite -- because that can be a big difference in terms of performance with many sprites. I could just call process_collision_info().
I will update this in the SVN, you can slap me and revert back if you don't like it
[ edit ] I am not updating the angle maths / pointTo code, because I'm not sure if it will work for your projects, so I want you to try inserting it and testing it -- I believe it will work much faster than what you currently do with all that triangulation. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed May 17, 2006 1:49 pm Post subject: |
|
|
Ok. I'm going to rename the process functions however, they are now...
process()
processCollision()
processAnimation()
processRotation()
I'll look into using your pointTo code. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed May 17, 2006 4:28 pm Post subject: |
|
|
| your pointto code is in, it works well thx. btw, what are all those other angle maths for? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
