Problem with parallax engine

[annikk.exe]

The parallax engine basically boils down to two commands:

Code: [Select]

starX[i] = (GetCameraX() + SetStarX[i]) / zdepth[layer]
starY[i] = (GetCameraY() + SetStarY[i]) / zdepth[layer]
Where starX is the actual drawn-on-the-screen position of star number i,
SetStarX is the given position of the star,
and zdepth is a value greater than 1, which represents how far away the star is.

This is what creates the parallax effect, however there is a problem.  It doesn't look right when you zoom in and out.  If you use page up and page down to only zoom in and out, you can tell that all the stars are on the same 2D plane as the asteroids.  It's only when panning around that it looks 3D.

When you zoom in, asteroids seem to get bigger and they move off the edge of the screen, away from the center of the screen.  That is what zooming in looks like - things get bigger and move away from the center.
When I zoom in, I need the stars to move away from the center of the screen more slowly than everything else.  In fact, the closer to "1" the zdepth, the longer it should take for them to move away from the center of the screen.

I can't work out how to create that effect.  Halp !

[Pilchard123]

You could change the size of the plane relative to CameraZoom()

 I don't know if that would work, but...

[annikk.exe]

Think I tried something quite similar to that.  What happened is that when scaling is performed due to the camera being zoomed in or out, all the stars move towards - or away from - the origin.

If the camera position happens to be sitting on 0,0 whilst you zoom, it actually looks pretty good.

The trick is, how do I get it to treat the camera as the origin, instead of the real origin?  How do I make all stars contract towards the camera position instead of the origin ?


If you're reading this thinking "what the hell is fluffy talking about" then trust me I am only barely able to grasp this myself.  Google has been little help on this matter.

[Sniped50]

Well, you'd need a way of tracking the camera's position relative to the real origin, then making the camera's centre the 'virtual' origin. Then you bash that in somehow, and through the boundless magic of Lua, you should be able to get it working.

Beyond that, I can't see how else to do it.

Do you know if there's a GetCameraPosition() function available? I swear I've seen such a beast before...


PS: YOU?!? UNABLE TO WORK SOMETHING OUT?!? WHAT HAS THE WORLD COME TO IN THESE DARK TIMES?!?!?

[annikk.exe]

I've been working on this problem for a while, and not had any luck. I think maybe the approach I've used doesn't work good for zooming. I did find one article about this stuff on google where the guy basically said he ran into a problem that sounds very similar to mine.

The problem is that zooming in means the camera gets closer to the stars. There isn't really a way (that I can think of) to do that with only parallax factors.

His solution was to make a full-on 3D engine with zdepth as a coordinate system in itself, like x and y. That would be pretty complicated though. I've also no idea what sort of overhead it would involve.

Fortunately the maths for it doesn't look too bad - a little Pythagoras and something else called the intercept theorem, which by the sounds of it is nothing more than calculating the position 2 lines intersect.

It's hardly bump maps and particle systems. The phrase "3D Engine" might sound ominous but I don't think it will be too hard really.

[annikk.exe]

Also the command GetCameraX() for example will return the camera's x. It's actually in the code I posted up top :>

I will need to work out how to make GetCameraScale() output transform into values representative of z. Hmm..

[annikk.exe]

Well, I've thought about it, and now I've produced this diagram:



Things are swimming sharply into focus now.  I know what I have to do.

There's one last problem I have to solve, which is calculating where the 2 lines intersect.  Off to research that now.  :>

[annikk.exe]

So, the equation for a line is:

Y = mX + b

Where m is the slope factor, and b is the axis intercept.

To calculate the slope m,


Where A is the camera and B is the star.


To calculate axis intercept b, it's this:

(x and y are the coordinates of any point on the line)

The intercept is what I need to use for the drawn position of the star, I think.
Oh, also, rather than X and Y, I'd use X and Z, followed by Y and Z.


Therefore, it follows that...

Code: [Select]

StarX[i] = SetStarZ[i] - (((GetCameraX() - SetStarX[i]) / (CameraZ - SetStarZ[i])) * SetStarX[i])
StarY[i] = SetStarZ[i] - (((GetCameraY() - SetStarY[i]) / (CameraZ - SetStarZ[i])) * SetStarY[i])
Still 2 lines, but this should work better, hopefully...

[annikk.exe]

In the diagram above it says CameraZ = 1 / GetCameraScale() * 1000, but I decided to use CameraZ = -1 / GetCameraScale() * 1000 instead because that means the stars will be behind the asteroids rather than in front of them, lulz.  :>

[Avaguard]

DAM! ur smart

[annikk.exe]

Heh, save the praise, it's not working yet!

Well, it's doing something really weird...but it doesn't look the way it's supposed to.  Yet.

[annikk.exe]

Ok figured it out.  I mixed up some of the terms.

This looks way better.  :>  Zooming in and out looks correct now - you can always tell that it's 3D, it never has that flat 2D plane look.

Freaking awesome.  :>



Ok well I guess I've given the game away on what new mechanic is going into my next level...

But!  This isn't the only thing that will be in it.. :>  I have another super-secret project.

[Bonobo]

Just in case nobody else points to it: Avaguard’s statement, dear Annikk-Sensei, is about YOU, not about your output

[annikk.exe]

Cheers guys.

I just made 6 stars chase each other around an asteroid, sort of like you always see diagrams/animations of electrons orbiting a nucleus in an atom.
Pretty neat stuff.  :>


Unfortunately, cool though it looks, there is a problem.  There seems to be some lag in updating "GetCameraScale()".  When you zoom in and out, the stars continue to be drawn at the old coordinates for a fraction of a second, before "jumping" to the new position.  This creates a bizarre pincushion-like effect which becomes more pronounced the further away stars are rendered.  It's particularly bad when zooming in and out with the mouse wheel.

So it looks like I still have some work to do.  Normally this is the point when I would bug Alex to figure out why that latency is being introduced but I fear he may be too caught up in PSN stuff right now...

Onward.. :>

[annikk.exe]

Hmm, managed to find some settings that look good.





Now I'm trying to work out how I can make the stars scale (in size) proportional to their distance from the camera, without making them fill the screen and look silly when you zoom all the way in.
That will have to wait until tomorrow though... sleep time now.  :>


Things still to do:

Star size scaling
Review the role of layers, which are now only used to send the fadeout threshold.
Import into super secret project of doom!