Hi all.

I finally wrangled up a PC and am now back on the set. Seems like YEARS since I've been here. I've been lurking with my Mac, trying to score a PC. And I finally got one.

Let the games begin!

Again.

Err... to my question: I'm building a shooter of sorts (just to get back into the swing of things), and have an issue where I need to move an object by a very small amount around the screen. For example, space shooter... you want to move a ... err... say a planet ... across the background. It would move very slowly, right? 'Cause it's a long ways away, and it huge.

Anyway, my problem is, if I just use a timer to make it move slowly (skipping draws) it obviously moves slowly, but with very stuttered movement.

I'm using vectors to move the planet, and I can't get vector lengths to be small enough to move it in very small increments, only large chunks.

I'd like to be able to simply manipulate my vector lengths... that would be easiest, but alas, no floats to divide them by.

I suspect someone will tell me to scale the whole thing up by a couple of places, I haven't wrapped my brain around exactly how that would work. Also, I understand the concept behind %, I'm just not sure how I could get it to apply to my problem. I can 'simulate' a float, but I still can't make incremental changes.

I'm wandering all over the place here, aren't I? The nice thing is that it's all coming back to me pretty quickly.

Lovin the new engine. I'll start working on some server apps as soon as I can get that danged planet to glide rather than stumble across space. ;)

Thanks.

-lok

Heh. Thanks.

It's an interesting idea. The vectors are because I'm moving my ship around 360 degrees (like the old Star Control). It has to be able to move around freely, or not at all, given the player's movement.

Hmm... For some reason, this is making my mind spark. I shall ponder your words some more.

-l

edit: My sig is huge.

1) You can learn the magical voodoo of fixed-point math
2) You can instead of making an integer 'pixelmoves per ticks' counter you can make your integer instead 'ticks per pixel move'
3) You can wait till the next major build which will have floats.

Couldn't really say for sure at this point how far away #3 is tho.

Makes a lot of sense, and that's precisely the kind of logical response I'd expect here. :)

Thanks.

-l

EDIT: AHHH... but wait. I'm using vectors here so that I can move the planet relative to the ship's direction (360 degree freedom).

How can I apply this method to a vector length?

Omni, You're now my personal god for introducing me to that naming convention.

Woot!

It worked.

Thanks, Omni.

Now I'm going to try to switch it over to Fixed-Point. Learning is gud.

-l

Er, what's up with the pre tags? And...er...what exact naming convention are we talking about? I tacked _100 onto the variables, and if anybody's interested I first saw that in Zara's 4Four source, so, his credit, not mine.



Also, you could do the same thing with angles and vectors, yes.

int angle_100, velocity_x100, velocity_y100, vector_length100 = 50     //vector length can be anything.


                          //Here, 50 units = 0.5 pixel.





for each tick...


     if they turn


          angle_100 + 100     //100 units = 1 degree


     if they move


          //The '>> 16' brings the result from 16.16 fixed point back to our 1/100 conversion.


          velocity_x100 = vector_length100 * Cos(angle_100 / 100) >> 16


          velocity_y100 = vector_length100 * Sin(angle_100 / 100) >> 16





circlex_100 += velocity_x100     //Increments the circle x, y position by the


                                 //vector x, y magnitude [ie, the velocity x, y]


circley_100 += velocity_y100





CircleDraw( circlex_100 / 100, circley_100 / 100)

This is significantly more complicated, because you're not just multiplying by the conversion, you're also multiplying by the Sin and Cos. Does this make sense as well?

Edit: Also, if you don't know a ton of trig or aren't comfortable with it, check
Sin and Cos: The Programmer's Pals!

Aww, everybody forgot my little fixed-point primer! Take a look at this, locke:

http://www.verge-rpg.com/~aen/code/fixed-point/fixed-point-r3.txt

Hopefully that'll help get your brain more warmed up to the concept.

Oh yeah! Documentation. Imagine that. <-- hasn't RTFM

Yeah, organizing search results by thread would be great. I don't -think- I missed the information I was looking for last time I used it (map file format), but I had to go over the results three times to make sure because most of them were from a six-month-old thread saying that the map file format is secret.